Re: Tone-of-voice used by sponsors
Hi, Marc Haber wrote: > On Sun, Jan 14, 2007 at 04:58:13PM +0100, Thijs Kinkhorst wrote: >> I often find the lists that Daniel posts to resemble commands "remove >> this.", "do not do that", "this is bogus", "that is useless" but lacking >> of background or guidance. > > This might be a language problem. I am also a native speaker of > German, and I observe myself to come over a lot more harsh than > intended when I write english. I mean, German is the language that > makes "I love you" sound like a declaration of war. Misunderstandings > like that happen. I agree to that argument. I'm a german speaker aswell and my mails mostly sound harsh if i try to keep them short and strict. Thats why i regularly tend to write longer mails and pick my words carefully. But IMO that can not be expected, when you do check *a lot* of packages. And that is exactly what Daniel does. One should be realistic: Daniel is doing a good work, when he sponsors packages. I can agree to what others said before. It's not only that you have packages in Debian, but packages that you can be proud of. Technically flawless, stylistic IMO good as well. And additional: It is not so that Daniel is rude at all. If you ask him (and even if you ask him the same things twice) you'll get proper answers. He helped me much with my packages so far. I'm sure he does the same for others. Greetings Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xpn
Michael Krauss wrote: > Are you sure, that the executable bit isn't set? Yes. > Here i get the following: > [EMAIL PROTECTED]:~$ ls -l /usr/share/xpn/xpn.sh > -rwxr-xr-x 1 root root 559 2007-09-03 20:41 /usr/share/xpn/xpn.sh That is why you should use something like pbuilder etc. to test your packaging, cause its bad to test things in an environment where other conditions might be met. Just sidenoted. > Done. I am always afraid of that kind of program, which expects a new > line at the end of a file. I am sorry. Well, i think not everybody finds that bad. I find it ugly. Thats why i told you to better remove it. >> * debian/rules contains some not neccessary empty lines > > Deleted some. Only the empty lines between two make targets remain. Yeah, fine. Those empty lines between the targets are good. I just thought that those empty lines in between commands in a target are silly, or double-empty lines. So well: I have checked your new version -4 and I'm afraid that it builds up a bogus link to the binary. You must not use absolute pathes in the links, as this will fail on systems other then the one were the package is built (and ofcourse it will not work after removing the src directory)- I would recommend you to use dh_link. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xpn
Jan C. Nordholz wrote: > (Besides, I wouldn't call the Debian changelog a user-exposed file - its > contents are often quite cryptic to the casual user ("updated po files"... > "rediffed patch foo and blorb, minor changes to work nicely with libbar"...), > and the more experienced can live with a few more interspersed numbers. ;) ) Hm, i don't remember if it was policy, but somewhere it has been said, that changelog entries should not be to technical. But in fact more and more application do expose the changelog to the user. See aptitude changelog or the update-mananger. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: steam-powered
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
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
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
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
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
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
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
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
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
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
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
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)
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)
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)
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)
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
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
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
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
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
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
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
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
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)
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
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)
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
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
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
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)
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
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
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
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
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
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
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
[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
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
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
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
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
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
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)
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)
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
Hi, On Fri, Jul 04, 2008 at 10:57:34AM -0700, Asheesh Laroia wrote: > Honestly, disks are cheap, and buildds don't spend a lot of time on shell > script packages since they don't need to be built. 5 kilobytes for a > .deb file and its source packaging is not a great burden to ask of the > mirror operators. (And five kilobytes is a generous estimate.) I wouldn't really mind if I would buy the diskspace, but given that mirror operators do it on a volunteer base, do it free and do not only mirror our archives I think we should have some sanity. Its not that I ask to exclude the script from Debian. I ask to not *waste* space at the wrong places. Disk space is cheap, you say. Thats true, if people have a chance to decide weither they want to waste that particular byte or not. Mirror operators don't have the choice (or better said they give space to the project and ask it to use it sane), so we do have to be sane. Users have the choice, they can decide weither they install a great package including thousands of little scripts and binaries, or not. I ask to *just think* a moment weither a single package is adequate for a single 200 line script, or not. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lynis (updated package)
Hi, no time too look into your package further at the moment. Just commenting on your mail for now. On Mon, Jul 07, 2008 at 01:56:48PM +, Francisco M. García Claramonte wrote: > > - 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 > > > > Well, It is a simple change, so I decided not change the timestamp. I wouldn't mind if it is a simple change or not. A change is a change and the timestamp indicates exactly that IMHO. > > - debian/copyright: > > - Important: (C) has no legal meaning, therefore it has to be > > replaced with ©. > > Ok, I have changed it to (c), because, lintian says that the > character © > is obsolete: > > W: lynis: debian-copyright-file-uses-obsolete-national-encoding at line > 20 No, it does not say that the character is obsolete. The message states that your file (debian/copyright) uses a character enocding which isn't appropriate anymore. Its a good idea to invoke lintian with the parameter "-i" if you receive such messages to see what exactly they are talking about. It would have shown this long description: The Debian copyright file should be valid UTF-8, an encoding of the Unicode character set. There are many ways to convert a copyright file from an obsoleted encodinglike ISO-8859-1; you may for example use "iconv" like: $ iconv -f ISO-8859-1 -t UTF-8 copyright > copyright.new $ mv copyright.new copyright Thats exactly what you need to do: Convert your copyright file to the proper encoding, but please do not blindly use the command as stated above, because I don't think you use ISO-8859-1. You can use file to find out which file the copyright file is encoded currently. I probably will have a further look at your package this evening. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about watch-file
Hi, On Tue, Jul 08, 2008 at 12:30:57AM +1000, Ben Finney wrote: > > And i don't know if i should add a lintian-override, > > Rather than an override, you can simply add a 'debian/watch' file that > has (only) comments explaining the current situation. Hu? > > add a watch file with the url [1] anyway > > That wouldn't be any use. An empty watch file (with comments) is > better than this. Whats your rationale for proposing to include useless empty files within of a package? Given that a) a watch file is still optional b) the lintian message is only of type 'info' c) We don't hide problems according to our social contract d) Comments about *why* a watch file is missing is not required, due to a) I'd say the best thing is to not include a watch file, to not add a lintian override (its useless anyway) and fix the problem with upstream first and _then_ fix it in the package. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about watch-file
On Tue, Jul 08, 2008 at 11:23:24PM +1000, Ben Finney wrote: > Right. And the lintian message suggests exactly what I'm suggesting: a > watch file that documents exactly why 'uscan' can't yet do its work > for this particular package. Seems wrong to me. The lintian text states that a package which is "(...) not maintained upstream (...)" may add a commented watch file "(...) containing only comments to document this." In my opinion the wording is very clear and aims at packages who are not maintained upstream. Meaning that a watch file is useless, because it will never report new upstream versions. But a comment is useful, because everyone who wants to do something with the package can read from it that upstream is dead. Despite that I'm not sure if the watch file is the proper place for such a note this has sureley an entitlement, and the watch file can't be fixed anyway, so a warning is inappropriate. But this case is different. This case has a more or less active upstream (or did I get something wrong?) with broken distribution tarball names. It breaks watch file support, because uscan is not *able* to detect upstream versions. > Indeed. Documenting them explicitly is what I'm suggesting, instead of > an override to silence a message. Well, the problem with your solution is that you silence an indicator for a problem anyway. Someone who looks at the lintian status of the package can do this from the outside and can decide to act upon. If you add a comment in a watch file then you have a comment in a hidden place for a lot of people who could potential fix the problem. They would need to look *into* that specific package, which is unlikely. > Creating the watch file with comments on the *current* situation is no > barrier to also working with upstream to fix that situation. In No, not for the current maintainer, thats true. But it *is* a barrier for everybody who wants to track specific problems from the outside, e.g. by looking at lintian.d.o. > addition, it documents the current situation exactly where people can > be expected to look, for as long as that situation persists. Where people can be expected to look if they already decided to fix a certain package, yes. But their is a chance that somebody wants to fix different packages that have similar problems, for example. The problem is hidden from them. I'd be interested to hear other opinions about this. Obvious these are just my 2 cents, above. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about watch-file
Hi, On Wed, Jul 09, 2008 at 07:03:22PM +1000, Ben Finney wrote: > My suggestion is that comments in the watch file are appropriate to > document *any* reason why the package maintainer is currently unable > to provide suitable information for 'uscan'. Nothing against this. I just would like to be able to have an external visible indicator about such problems. > > Despite that I'm not sure if the watch file is the proper place for > > such a note this has sureley an entitlement, and the watch file > > can't be fixed anyway, so a warning is inappropriate. > > I don't understand what you're saying in this sentence. Two things: 1) I'm not sure if a watch file is the proper place for documenting a dead upstream 2) I think that the (by lintian) suggested behaviour in the dead-upstream case has its entitlement. > I don't think lintian should be providing such an indication "from the > outside"; that's more appropriate for the DEHS checker. The DEHS checker is a good point, didn't think about it. But you forget that *both* tools are used within externals frameworks, so lintian is appropriate, too, as long as it has a check for watchfiles. > I think the description of 'debian-watch-file-is-missing' should be > changed to ask the package maintainer to add a watch file regardless: > either with functional settings for 'uscan', or with comments > explaining why this can't currently be done. Sounds reasonable. > My argument is that lintian, which is a tool suitable for running > frequently by the package maintainer, should not nag the developer for > such a common situation. Adding a lintian override is inappropriate if > the situation is not exceptional, and especially not if the problem > can be documented in a better way. I don't think that the current situation qualifies as beeing common. In my opinion adding watch files is something that needs to be encouraged and additional is possible in the majority of cases. I accept that there are cases where it isn't posible or doesn't make sense, but I doubt that this is common. > Those who want to find problems like "is the package healthy?" should > be looking at the DEHS reports, which show this status clearly without > involvement by lintian. They will then know that 'uscan' had some > problem, and can examine the watch file, where they'll see whatever > the package maintainer has written about the situation. No need to get > lintian involved. Anyway you convinced me that DEHS is probably the better place for such things. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to detect an upgrade from an older version of a package
Hi, On Mon, Jul 14, 2008 at 04:05:05PM +0300, Eugene V. Lyubimkin wrote: > > I know many "hacks" to know that I'm upgrading (like doing dpkg -l, > > etc.), but what is the correct/policy way to know from what version my > > package is upgrading, so my postinst can run smoothly? > Policy 6.6.3 says > > "If the package is being upgraded, call: > > new-preinst upgrade old-version > " > Is it what you are seeking? > Additional (might be more to his interest, because he talked about his postinst) it says: " postinst configure most-recently-configured-version " If a package is upgraded the most-recently-configured-version is usually identical to old-version. It isn't if the configuration of the package already took place but the installation hasn't finished (half-installed state). That is as far as I understand it. Anyways using $2 as oldversion worked for me in every case so far. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: RFS: bluemindo
Hey, sorry for beeing late with replying. Had been a bit busy the days when we where on this, and forgotten it over this. Mea culpa, but just as a hint for the future: Its not bad to send a reminder after some days. After all people in the project are just people, so things like this may happen otherwise. On Wed, Jul 09, 2008 at 10:32:19PM +0200, Thibaut GIRKA wrote: > I've moved it to debian/links (and debian/install for the dh_install > call). Good. > I also modified the debian/copyright file, it should be a little > cleaner, and it now includes the PSF license. Good, except that I miss a "It was downloaded from .. " sentence in the human readable part. > I've added how to disable patches in README.source > It seems to be the only way with simple-patchsys. Uarg. Another reason not to like CDBS, but apart from this, this seems to be adequate. > > [...] > > Yeah, alright. > > [...] > > Great. > > [...] > > Perfect. > > [...] > > Okay, good. > > Thanks :) Hehe. No problem. > I replaced the description with yours and I added notes about optional > dependencies. Alright. Now I'm satisfied with your package, except the missing sentence in the copyright file. So I'm recommending to upload the package to my Application Manager Paul. Paul, is this package ready for upload in your opinion, or is there something to add from your side? As a reminder: The package in question is [1]. Thanks and best Regards, Patrick [1] http://mentors.debian.net/debian/pool/main/b/bluemindo/bluemindo_0.2.1-1.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bluemindo
Hi Vincent, On Sun, Aug 03, 2008 at 11:34:25PM +0200, Vincent Bernat wrote: > > Uarg. Another reason not to like CDBS, but apart from this, this seems > > to be adequate. > > cdbs also supports quilt (/usr/share/cdbs/1/rules/patchsys-quilt.mk). > > You cannot ask for a "simple patch system" and ask numerous features > (like series) that you find in more complex patch systems like quilt. Thats a valid objection, indeed. So in this case just ignore what I said. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/control best practices
Hi, On Wed, Sep 17, 2008 at 07:21:03AM -0500, Carlos Eduardo Sotelo Pinto wrote: > http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis > > package-name is a synopsis. > > but all the packages that I have seen was on this way > > Package-name is a synopsis. > two questions: 1) Where did you see this? 2) Why do you think its of interest how Package is written out? You must understand that this sentence is only a help for you how the part _after_ packagename should be. Basically it means that your synopsis must not include "Package-name is a", but if your synopsis would be combined with this sentence it should still make sense. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dbconfig-common
Hi, On Wed, Sep 17, 2008 at 07:29:35AM -0500, Carlos Eduardo Sotelo Pinto wrote: > I had fixed this problem on sitebar building package changing > /usr/sbin/mysql to just mysqld but, how about the bug, itsuggest to > change to dbconfig-common, then what i must do first, just correct or > change the postinst to debconfig-common dbconfig-common is documented fairly well. See [1] or better (because most likely at the newested version): Install the dbconfig-common package and have a look into /usr/share/doc/dbconfig-common. It also includes some example packages for the most cases. Best Regards, Patrick [1] http://people.debian.org/~seanius/policy/examples/dbconfig-common/doc/dbconfig-common-using.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dbconfig-common
On Thu, Sep 18, 2008 at 01:00:00AM +0800, Thomas Goirand wrote: > Patrick Schoenfeld wrote: > > dbconfig-common is documented fairly well. > > I do not agree with this statement. There are dark areas in the doc, > particularly nowhere, it's telling how to get a root user on MySQL, and > some packages might need it. Well, my statement is true for the most usual cases. Obvious it does not document things it doesn't support. However it would be appropriate to open a bug report for such cases, wouldn't it? > Also, it's author never replied to my emails. Thats unfortunate, but this doesn't seem to me a generic experience, because I _got_ answers to questions I mailed him. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITR: elfrc (was: Re: RFS: elfrc)
Hi, On Thu, Sep 18, 2008 at 08:49:06PM +0200, Krzysztof Burghardt wrote: > I am looking for a sponsor for my package "elfrc". I intend to review your package. I will get back to you ASAP. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITR: elfrc
Hi, Krzysztof Burghardt wrote: > I am looking for a sponsor for my package "elfrc". here it comes to my comments about your package. Please note that this might not be 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. - debian/copyright: 1) The copyright of Frerich Raabe does not contain every copyright year. I found at least one different year, which should be listed aswell. 2) The string '(C)' has no legal meaning in some parts of this world. You should replace it with the © character. 3) The reference to the file in /u/s/common-licenses is wrong, because the license in elfrc is *not* a 3-clause BSD license, while the on in /u/s/common-licences is. The license block should therefore include the full license. Apart from this: Its not exactly clear weither the package is your work, or the work of Kumar Appaiah or the work of you both. Probably you want to remove the mark of Kumar Appaiah in the changelog, add your copyright to debian/copyright and note therein that your work is based on the work of Kumar Appaiah (if that is the case). - debian/rules: You could use install -D in your rules file, to also create the directory you are installing to. This way you could get rid of debian/dirs and the dh_installdirs call in it. But thats not neccessarily needed. Apart from this the call to dh_installexamples is not needed, because your package does not include any. The same is true for dh_link. Thats it for now. Once you've got the above issues fixed, I'll have another look at the package and possibly upload it. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITR: quickplay (was: Re: RFS: quickplay)
Hi Charlie, On Fri, Sep 19, 2008 at 02:15:41PM -0500, Charliej wrote: > I am looking for a sponsor for my package "quickplay". I intend to review your package and will come back to you soon. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: quickplay
Hi, before the review process starts, a question: On Fri, Sep 19, 2008 at 02:15:41PM -0500, Charliej wrote: > Version : 0.1 > * URL : http://quickplay.isfound.at/ Do you think this software is yet mature enough for inclusion into Debian? I'm just wondering, because of the low version number and what the homepage concerns... "work in progress" would be a over-optimistic. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: quickplay
Hi, Charliej wrote: > That depends on what your definition of what "mature" is? If you mean > "mature" as in will the software do what it's suppose to do then yes. > If you mean "mature" as in time then probable not. mature means for me that the package is somewhat ready for use by "end users". That means that it works mostly stable, does what its expected to do and does not make a half-baked impression on the user (we have such software in the archive and I dislike it, so I won't help with getting such software in) > Actually upstream was not using versioning until I requested that he do > so. Hence the low version number, I thought 0.1 would be a good place > to start. Ah, I see. Does that mean that the software already has some development history behind it? I'm just asking out of curiousity, I didn't yet test the software. > IMHO any package that introduces new features would be considered a > "work in progress". I would consider Debian itself a "work in progress" > in that it changes and evolves on a daily basis which is a good thing. My use of "work in progress" was about the homepage, which does not yet contain any useful information. As I did not test the software yet, this and the low version number is my only impression of the development. It makes the impression that the development just started and that it might be to early to be included into a distribution. If that impression is wrong; good. Thats why I asked you. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-proxy, apt-cacher & approx
Hi, On Mon, Sep 22, 2008 at 01:14:42PM +0800, Thomas Goirand wrote: > mismatch error). I was wondering if approx is any better than the other > two. Did any of you try? I made similar observations with the use of apt-cacher and apt-proxy and therefore switched to approx. This is working like a charm for me since over a year. I'm using (except configured mirrors) a default conf. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: quickplay
Hi Charlie, On Mon, Sep 22, 2008 at 09:57:09AM -0500, Charliej wrote: > I have been thinking about this quite a bit, and you are absolutely > correct. Upstreams documentation is sourly lacking. I asked myself the > question "If I was the end user would I use something so poorly > documented" and of course the answer was no. So I have decided to take > quickplay down from m.d.n for now. I will keep the ITP bug open as I > will be working with upstream to improve on the short comings you have > expressed above and resubmit at a later date. okay. I wouldn't say that I'm glad or that it was my intension to let you choice your decision in this way, but I am happy that I brought you to *think* about this point. Feel free to CC me, when you've got a package that you feel to be ready for inclusion. I will gladly have a look at it then, if I find the time. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: elfrc [uploaded]
Hi, On Sun, Sep 21, 2008 at 03:11:28PM +0200, Cyril Brulebois wrote: > In addition to Patrick's comments, I'd suggest to “s/program to //” this > description. thanks for noting that. BTW. the package has been uploaded. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: NMU for tinyscheme 1.37-3.1 (fix RC bugs)
Hi, On Wed, Sep 24, 2008 at 01:34:02AM +0200, Luca Falavigna wrote: > I uploaded on mentors.d.n NMU candidate for tinyscheme 1.37-3.1 [1], > which fixes two RC bugs [2-3]. I attached a debdiff of the changes > provided in the bug reports. Could you please have a look at it? good. uploaded. Thanks for your contributions to Debian. Best Regards Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]