Re: RFS: icoutils (updated package)
2010/11/11 Markus Schölzel : > I am looking for a sponsor for the new version 0.29.1-0.1 > of my package "icoutils". I pinged the maintainer, Colin Watson, about your upload on IRC. I would suggest that you get in touch with him via mail. New upstream versions are not appropriate for unstable at this stage in the release cycle. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik_irasejr7v19tps8rysj+bx3elc94irhr+...@mail.gmail.com
kredit tanpa agunan scb solusi keuangan anda
Personal loan atau kredit tanpa agunan dari standard chartered bank memberikan pinjaman hingga Rp.150.000.000 , bunga hingga 1,50 % / bulan.Proses yang mudah dan cepat 7- 10 hari kerja dengan kepastian approval yg tinggi DATA YG DIBUTUHKAN UNTUK PENGAJUAN 1 BUNGA 1,50 %: 1.Foto copy KTP 2.Foto copy Credit Card 3.Foto copy billing credit card 1 bulan terakhir 4.Foto copy NPWP untuk pinjaman diatas Rp.50 juta 5.Foto Copy nomor rek.tabungan 6.Materai Rp. 6.000 1 bh. Untuk keterangan lebih lanjut hubungi : HARTAWAN 0858-83824829 Or harta...@yahoo.co.id -- View this message in context: http://old.nabble.com/kredit-tanpa-agunan-scb-solusi-keuangan-anda-tp30210584p30210584.html Sent from the debian-mentors mailing list archive at Nabble.com. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/30210584.p...@talk.nabble.com
Re: RFS: kstars-data-extra-tycho2 (third try)
Hi again, I think sounded pretty rude in my earlier mail; I'm sorry, I didn't mean to be rude. I just had got the impression that you were waving away other people's suggestions for no reason obvious to me. [...] > > > > Would you mind to elaborate in what respect this is going to be more than > > your little pet package? Is kstars that often installed on true multi-user > > systems such that a quick hack is warranted? > > I do not want a quick hack but a truly good package that allows users to have > their systems fully installed through Debian packaging systems. I do not know > why one needs to download data from the network for a program that is > packaged: kstars data is not a non-distributable PDF reader to need an > installer outside the packaging system. Is it? > You're right; I just hadn't fully accepted that is was a simple data package that will ensure the data doesn't get stored for each and every user, but just once and for all on the system. [...] > > > > I find it very unfortunate that you refuse to integrate with existing > > Debian work right from the start. Given that your package is unlikely to > > make it into Squeeze anyway, IMHO there is no need to hurry. Why not > > prepare a nicely integrated package right away, what would you expect to > > gain from this first shot if you'll later plan to transition to > > stardata-common anyway? > > I agree that there is no hurry, but I'm working on the set to have it in > shape > for wheezy. Would you prefer for me to wait? > Oh no, surely not, I was rather hoping that ... > About the transition to stardata-common, the problem with that is that I'm > still not convinced that it is compatible with this package set. The source > for this version of the Tycho2 package is not the original data as-is but a > subset of it, but even the stardata-common concept may be not applicable to > other packages of the set like ephemerides, DST rules, images or icons, as > stardata-common is "Common framework for handling stardata catalogues in > Debian" and not anything similar to "Common framework for handling > astronomical and related data in Debian". > [...] (more detailed explanation of your point) ... you could go for stardata-common right now. This might be a bit more work (and you would hence possibly miss the Squeeze freeze), but I still believe in it being beneficial. It would actually even more reduce the disk space and band width usage if several packages shared such data. I understand that this is non-trivial. So why was I panicking? Once the package has entered the archive, it will stay. It does what you wanted it to do, and it will be hard to enforce any changes. Here and now is my only chance to try to convince you to follow a different route. Of course, bugs could be filed, but none of them would be of release-critical severity. > > Please don't feel offended in any way, but I'm not going to sponsor such a > > package. Of course many others might have a very different attitude and > > will take it, so just don't count on me. > > I'm not offended: I try to learn from everybody's comments, either > constructive or not, but it seems to me (personal humble opinion) that you > missed the point of these packages. I think that a good enough solution is > better than an asimptotycally unreachable perfect one, moreover if it is > later > improvable, and even if the perfect solution is actually reachable but in a > long term. > [...] I think I got the point of your packages and while I might still not be the one sponsoring them, it would be for technical reasons only (my knowledge of KDE stuff is really limited). Which may not make a difference for you, but at least for me it was important to have my attitude adjusted. I still hope that there is a convergence towards a common data set for packages interested in the same data, but it shall not block an initial upload. Best regards, Michael pgpA3ifkdtutZ.pgp Description: PGP signature
Re: RFS: lightspeed (updated package)
Hi, sorry for the late reply. Tony Palma writes: > I notified the author and upload the package to mentors with a very > large patch(build-update.diff). Now I'm using > dh $@ --with autotools_dev > and their respectives overrides, to manage the updates of > config.{guess,sub}. There are still changes to these files in the diff: lightspeed-1.2a/config/config.sub lightspeed-1.2a/config/config.guess They should not be included in the diff. You might also want to update ./configure (and Makefile.in) itself in d/rules, for example by using dh-autoreconf, instead of including these rather large changes in the diff. Is the copy of libintl necessary? At least information about it is missing in debian/copyright: lightspeed-1.2a/intl/* (included in the diff) Some of the override_* targets in debian/rules are not necessary: dh_installchangelogs will install the ChangeLog file even when you do not pass the file name explicitly. You might also want to use debian/${package}.docs and debian/${package}.manpages instead of using override_* targets for dh_installdocs (dh_installman). Regards, Ansgar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjz47th6@marvin.43-1.org
Re: RFS: libgis - virtual globe library
On Sat, 13 Nov 2010 19:20:23 +, Andy Spencer wrote: > On 2010-11-13 10:58, David Paleino wrote: > > IMHO, the name of your project is rather too generic ("libgis"). It should > > be changed to something more descriptive, but that's your choice as > > upstream at the end. > > > > Apart from this, you're very welcome to maintain it under the Debian GIS > > Team umbrella. To join us, please join the pkg-grass [0] project on > > alioth.debian.org. > > > > [0]: https://alioth.debian.org/projects/pkg-grass/ > > I've never been good with names :) I agree that it is a little generic, > but I would rather leave it the way it is. I can't find any conflicts in > Contents-i386 and googling for "libgis" seems to indicate that it's a > fairly unique name, apart from a subsection of GRASS. > > Maintaining it under the "Debian GIS Team" would be nice. That website > looks pretty GRASS-specific though, would it be suitable for a non-GRASS > related package? Yes. The team is named "pkg-grass" mainly for historical reasons, now it maintains all sorts of GIS-related software -- from GRASS to OpenStreetMap things. > > - In debian/control, you misinterpreted the meaning of Vcs-* fields. Those > > should point to the location where the Debian packaging is kept, while you > > pointed at the upstream repository. You can choose to maintain the debian/ > > dir there as well, or host it on Alioth within the Debian GIS Team (which > > would be better for team-maintainance). > > Oops, I've removed the links for now and will add "proper" links once > version control is set up for the debian files. Alioth seems like a good > place, I'll look into how that works. If you join pkg-grass, you could ssh into alioth and do: $ cd /git/pkg-grass/ $ ./setup-repository libgis 'some description' After that, you can use git.debian.org/git/pkg-grass/libgis.git as remote in your packaging repository. Most (if not all) of the packages there use the git-buildpackage layout -- you might want to read about "git-import-origin", "git-import-dsc" and "git-buildpackage". > [..] > > - Your package doesn't seem to be lintian clean ;-) -- you pasted lintian's > > output in debian/lintian.txt, and there it clearly says to a) close an ITP > > bug and b) use a proper name for the binary (point 2 of my comments). Next > > time please read it ;) > > The first lintian file I generated was actually much bigger ;) > a) Fixed now (per Benoît's email) #603393 for reference > b) I wanted to discuss this one a little further before trying to > correct it. (See below) Ack. > Another point of interest is that mentors.debian.net says: > intian warnings: none > intian errors: none > Even though there were some warnings. I copied the `lintian clean' > message from the template it generated, but I'm not sure if it generated > the `lintian clean' part or if that was hard coded. Well, no. AFAICT, mentors.debian.net doesn't use sid's lintian -- while a maintainer should always use that one. > > - Library packaging in Debian has to follow certain policies. The binary > > package you're producing should be named "libgis" (i.e. libgis0, > > or similar). This ensures that any dependant package depends on the correct > > version of the library. > > > > - Always in the lintian warning, it says you're missing a symbols file. > > Since it's a C project, I strongly suggest you to make one (I personally > > dislike C++ symbols files, but that's just me). Please read more at > > http://wiki.debian.org/UsingSymbolsFiles > > (I wanted to address these comments together) > > Personally, I'm not too concerned with the symbols file, or library > versioning at all for that matter. Now, I had better clarify before > someone bashes me with the libtool manual ;) Yeah. Such statements don't usually pass unpunished :-) > As I mentioned in my initial email, libgis was developed to support > another program called AWeather. Since AWeather is the only program that > currently uses libgis and it depends on the latest version anyway, I > don't expect there to be very many issues with library versioning. > > That being said, if/when I hear about other people wanting to use libgis > in their own programs (which I hope they will) I will start caring much > more about library versioning, a stable API, etc. Uploading a library in Debian, you're giving other users the chance to use it, and link against it. Even for private (as in not-published) projects. And breaking users' software for no reason isn't good ;) > Anyway, I suspect some library versioning will be required, but I think > doing as little as possible would (for now) be the most efficient way to > go. Does this sound correct for package names, or can I do without the > 0.4? > > - libgis-0.4-0 > - libgis-0.4-dev > - libgis-0.4-bin > - libgis-0.4-doc Nope. What's required in the package name is the SONAME, which in your case is 0. So the packages should look like: - libgis0 -
Re: RFS: libgis - virtual globe library
On 2010-11-13 10:58, David Paleino wrote: > IMHO, the name of your project is rather too generic ("libgis"). It should be > changed to something more descriptive, but that's your choice as upstream at > the end. > > Apart from this, you're very welcome to maintain it under the Debian GIS Team > umbrella. To join us, please join the pkg-grass [0] project on > alioth.debian.org. > > [0]: https://alioth.debian.org/projects/pkg-grass/ I've never been good with names :) I agree that it is a little generic, but I would rather leave it the way it is. I can't find any conflicts in Contents-i386 and googling for "libgis" seems to indicate that it's a fairly unique name, apart from a subsection of GRASS. Maintaining it under the "Debian GIS Team" would be nice. That website looks pretty GRASS-specific though, would it be suitable for a non-GRASS related package? > - In debian/control, you misinterpreted the meaning of Vcs-* fields. Those > should point to the location where the Debian packaging is kept, while you > pointed at the upstream repository. You can choose to maintain the debian/ > dir there as well, or host it on Alioth within the Debian GIS Team (which > would be better for team-maintainance). Oops, I've removed the links for now and will add "proper" links once version control is set up for the debian files. Alioth seems like a good place, I'll look into how that works. > - Why is libgis-doc an arch:any package? I didn't check its contents, but I > suspect it should be arch:all. ;) Fixed :) > - You might want to use DEP-5 format for your debian/copyright. Read more at > http://dep.debian.net/deps/dep5/ . It's entirely optional, and it won't be a > stopper if you leave it like it is now. That looks like a nice format, I've change debian/copyright accordingly. > - In libgis-dev.install , please avoid installing *.a files. We (as Debian) > are > deprecating them, and installing them in a brand new package is a bad thing. Removed. > - Your package doesn't seem to be lintian clean ;-) -- you pasted lintian's > output in debian/lintian.txt, and there it clearly says to a) close an ITP > bug and b) use a proper name for the binary (point 2 of my comments). Next > time please read it ;) The first lintian file I generated was actually much bigger ;) a) Fixed now (per Benoît's email) #603393 for reference b) I wanted to discuss this one a little further before trying to correct it. (See below) Another point of interest is that mentors.debian.net says: intian warnings: none intian errors: none Even though there were some warnings. I copied the `lintian clean' message from the template it generated, but I'm not sure if it generated the `lintian clean' part or if that was hard coded. > - Library packaging in Debian has to follow certain policies. The binary > package you're producing should be named "libgis" (i.e. libgis0, or > similar). This ensures that any dependant package depends on the correct > version of the library. > > - Always in the lintian warning, it says you're missing a symbols file. Since > it's a C project, I strongly suggest you to make one (I personally dislike > C++ symbols files, but that's just me). Please read more at > http://wiki.debian.org/UsingSymbolsFiles (I wanted to address these comments together) Personally, I'm not too concerned with the symbols file, or library versioning at all for that matter. Now, I had better clarify before someone bashes me with the libtool manual ;) As I mentioned in my initial email, libgis was developed to support another program called AWeather. Since AWeather is the only program that currently uses libgis and it depends on the latest version anyway, I don't expect there to be very many issues with library versioning. That being said, if/when I hear about other people wanting to use libgis in their own programs (which I hope they will) I will start caring much more about library versioning, a stable API, etc. Anyway, I suspect some library versioning will be required, but I think doing as little as possible would (for now) be the most efficient way to go. Does this sound correct for package names, or can I do without the 0.4? - libgis-0.4-0 - libgis-0.4-dev - libgis-0.4-bin - libgis-0.4-doc (using -version-info 0:0:0 -release 0.4.1) Thanks for all the comments. I'll build and post another set of packages this evening with these (and other) changes. pgp4iRhkm18jD.pgp Description: PGP signature
Re: RFS: pycam
Hi Lars, Lars Kruse wrote: > I am looking for a sponsor for my package "pycam". > > * Package name: pycam > Version : 0.4-1 > Upstream Author : Lode Leroy, Lars Kruse (that's me) > * URL : http://pycam.sourceforge.net > * License : GPL3 > Section : python > > It builds these binary packages: > pycam - CAM program & library written in Python Here are the few issues I spotted in your package: - You have debian/{postinst,prerm} scripts, but they do not do anything. You should just delete them. - In debian/copyright, there is no email address for either of the maintainers (and Sebastian Kuzminsky's email is not formatted correctly). While you're at it, you should also add yourself to the packaging copyright. You may also want to use the DEP-5 format [1] for that file. [1] http://dep.debian.net/deps/dep5/ - lintian -I gives the following warnings: I: pycam source: quilt-patch-missing-description 00.remove_windows_install_script.patch I: pycam source: quilt-patch-missing-description 01.remove-superfluous-files-from-doc.patch I: pycam source: debian-watch-file-is-missing and these three about the man page: I: pycam: spelling-error-in-manpage usr/share/man/man1/pycam.1.gz paramters parameters I: pycam: hyphen-used-as-minus-sign usr/share/man/man1/pycam.1.gz:248 I: pycam: hyphen-used-as-minus-sign usr/share/man/man1/pycam.1.gz:261 It would be nice if you could fix them. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101113175722.ga31...@debian.lan
Re: RFS: libgis - virtual globe library
On 2010-11-13 10:21, Benoît Knecht wrote: > I didn't really look at your package yet, but I just wanted to point out > that you're not closing any bugs with this release. You're supposed to > file a bug against WNPP (Work-Needing and Prospective Packages) and note > in the debian/changelog entry that this package would be closing that > bug. See [1] for details about the procedure. Thanks, I've filed bug #603393 [1], added it to debian/changelog, and noted it in the "comment" field on mentors.debian.net. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603393 pgpEN3Cag7NuN.pgp Description: PGP signature
Re: RFS: dalle
Hi Alberto, > Hi, > > I've uploaded a new package for review. Summary: > - Cleaned changelog. Added a thaks to Mònica. > - All source files now have license header (I didn't know > licensecheck ...) > - Email sent to the Pkg-mono-devel mailing list for help, review and > sponsor. > - copyright file changed to DEP5 > Thanks a lot for taking all this into account. From this point of view, the package looks really fine now. I would, however, hope that someone from pkg-mono-devel takes the time to review your package from a mono perspective and sponsor afterwards. > I've one question about licenses, as author of the software. > > I've taken some Apache-2 licensed code on dalle (GPL3). I've ported the > java code to c# (trivial). How do I have to license that files? > [...] Maybe someone else on this list knows (I don't), but probably asking on debian-le...@lists.debian.org is a much safer bet. I'd hope you can fine someone good knowledge on that list. Hope this helps, Michael pgptv30SWOBVd.pgp Description: PGP signature
Re: RFS: bluecove, bluecove-gpl
Hi Chris, > Dear mentors, > > I am looking for a sponsor for my packages "bluecove" and > "bluecove-gpl". > > Package name: bluecove > Version : 2.1.0-1 > Upstream Author : Many > URL : http://bluecove.org > License : LGPL and GPL > Section : java and libs > > Bluecove builds these binary packages: > libbluecove-2.1.0-java - Java library for Bluetooth (JSR-82 > implementation) > I briefly reviewed the copyright information of libbluecove and was kind of irritated by README and LICENSE saying it is LGPL while *all* (well, a few even missing license/copyright information) the source files say it is Apache 2.0 licensed!? Could you please get some clarifification from upstream? Please get this fixed first as BlueCove-GPL relies on this one and cannot be built without it. > BlueCove-GPL builds these binary packages: > libbluecove-gpl-2.1.0 - additional module for BlueCove support on Linux > (native library) > libbluecove-gpl-2.1.0-java - additional module for BlueCove support on > Linux (java library) > > BlueCove is lintian clean however BlueCove-GPL has two warnings: > E: libbluecove-gpl-2.1.0: > sharedobject-in-library-directory-missing-soname > usr/lib/libbluecove-2.1.0.so > W: libbluecove-gpl-2.1.0: > library-not-linked-against-libc ./usr/lib/libbluecove-2.1.0.so > > I would appreciate help with these as I have run out of ideas. > Run lintian with the additional flag -i to get a more detailed description, which can also be found here: http://lintian.debian.org/tags/sharedobject-in-library-directory-missing-soname.html http://lintian.debian.org/tags/library-not-linked-against-libc.html > The other small issue with the packages is the Maintainer, I created a > Java package recently (ant-contrib-cpptasks), for which the Maintainer > is the Debian Java Maintainers > , should this package (as > its a java package) have this Maintainer also? > [...] I guess this is up to you, whether you prefer future team maintenance or would like to stay the lone maintainer of these packages. Hope this helps, Michael pgpYSVR1VlqxE.pgp Description: PGP signature
Re: RFS: sima (autoqueue MPD client, find similar artists to queue)
Le 12/11/2010 10:55, Michal Čihař a écrit : > Dne Fri, 12 Nov 2010 10:30:51 +0100 > Geoffroy Youri Berret napsal(a): > >> The package can be found on mentors.debian.net: >> - URL: http://mentors.debian.net/debian/pool/main/s/sima >> - Source repository: deb-src http://mentors.debian.net/debian unstable >> main contrib non-free >> - dget http://mentors.debian.net/debian/pool/main/s/sima/sima_0.6.0-1.dsc > > The upstream tarball name is mpd_sima, maybe you want to name source > package same way? > > Why have you modified the source tarball? I thought the underscore is not allowed. http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Source Anyone to confirm? In case it is, should I follow a specific policy to name the package? Thanks for the review :) Cheers Geoff -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cdea6f5.70...@azylum.org
Re: RFS: libmatheval (updated package)
Hi Julian, [...] > > Unfortunately I only just realized this probably changes the abi (function > definition changed) and thus a soname bump. I'll have to look into this with > more detail. > So this RFS was probably a bit premature, but I would still be grateful for > an review of what is already done as this is my first package. > [...] Thank you very much for updating this package to match current packaging best-practice. Having checked the debdiff to the package currently in the archives, to me it looks pretty good, you should only fix one more thing: I: libmatheval source: binary-control-field-duplicates-source field "section" in package libmatheval1 Once you have also done the soname bump, please also consider introducing symbol control files. It could help to ensure you cannot accidentally miss such soname bumps. Hope this help, Michael pgp5fLz501rMO.pgp Description: PGP signature
Re: RFS: 9menu (updated package, Second try)
Hi, epsilon wrote: > I am looking for a sponsor for the new version 1.8-4 > of my package "9menu". > > It builds these binary packages: > 9menu - Creates X menus from the shell You can further simplify your debian/rules file by letting debhelper know what to do through files in debian/ instead of overrides. For example, instead of overriding dh_clean, you can list additional files to be removed in debian/clean. Same thing for dh_installman and dh_installdocs. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101113142557.gd3...@debian.lan
Re: RFS: icoutils (updated package)
Markus Schölzel wrote: > May you want to have a look at > - URL:http://mentors.debian.net/debian/pool/main/i/icoutils > - > dgethttp://mentors.debian.net/debian/pool/main/i/icoutils/icoutils_0.29.1-0.2.dsc > > Now there should not come up I: or P: warnings anymore. You seem to have a debian directory inside the debian directory (debian/debian), not sure how that happened. Other than that it seems okay, although I cannot comment on the software itself, I didn't try to run it. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101113141314.gc3...@debian.lan
Re: RFS: libvdpau (updated package)
Hi Michael, On Freitag, 12. November 2010, Michael Gilbert wrote: > but > is it really necessary to spend so much effort to contact the > maintainer (bullets 2, 4, and 5)? Yes. Also, your NMU attempt was about a RC bug you filed yourself (and recently before). I think the "wait longer to give maintainers time to reply" part was covered well in this thread, but not the part "because you filed that bug" part. It's one thing, to file a bug correctly. And it's another, to find the right fix. You provided both (nothing wrong with that alone!) and then asked for sponsoring the upload immediatly. Thats not good. cheers, Holger, who wanted to do the same a few days ago (#602765) and was quickly convinced (on irc, not in the bug log) that was a bad idea. Today I'll NMU though. signature.asc Description: This is a digitally signed message part.
RFS: icoutils (updated package)
Am 11.11.2010 17:46, schrieb Benoît Knecht: Hi Markus, Markus Schölzel wrote: I am looking for a sponsor for the new version 0.29.1-0.1 of my package "icoutils". It builds these binary packages: icoutils - Create and extract MS Windows icons and cursors The package appears to be lintian clean. The upload would fix these bugs: 511944, 516170, 589377 Since you're fixing a man page typo in this release (bug #516170), do you think you could fix those lintian warnings as well? I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/extresso.1.gz:63 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/extresso.1.gz:64 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:65 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:66 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:83 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:87 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:91 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:107 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:115 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:121 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:163 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:164 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz 12 more occurrences not shown I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:44 I: icoutils: spelling-error-in-manpage usr/share/man/man1/wrestool.1.gz preceeded preceded I: icoutils: spelling-error-in-manpage usr/share/man/man1/wrestool.1.gz preceeded preceded I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:60 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:80 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:85 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:174 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:175 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:176 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:177 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:178 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:182 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz 2 more occurrences not shown There are also two lintian --pedantic warnings that should be easy enough to fix: P: icoutils: copyright-refers-to-symlink-license usr/share/common-licenses/GPL P: icoutils: no-homepage-field Thanks for your hint! May you want to have a look at - URL:http://mentors.debian.net/debian/pool/main/i/icoutils - dgethttp://mentors.debian.net/debian/pool/main/i/icoutils/icoutils_0.29.1-0.2.dsc Now there should not come up I: or P: warnings anymore. Kind regards, Markus Schölzel -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cde6d49.2000...@web.de
Re: RFS: dbxml
Hi Jeroen, > Dear Mentors, > > I am looking for a sponsor for my package "dbxml". > > * Package name: dbxml > Version : 2.5.16-1 > Upstream Author : Oracle > * URL : > http://www.oracle.com/technology/software/products/berkeley-db/db/index.html > * License : BSD and Apache 1.1 > Section : unknown > [...] Thank you for tackling this large piece of software. I just did a review of the most basic Debian packaging stuff, I did not check proper function. - debian/changelog: "squeeze" is not a valid upload destination, you want unstable or even experimental. - debian/control: Section: unknown is no good. Current Standards-Version would be 3.9.1. You want default-jdk, not default-jdk-builddep. All description are extremly short. Maybe a common text describing what "Oracle Berkeley DB XML" is, how it differs from other libraries, etc. would be good for all packages. The current descriptions would then serve as second stanza. - debian/copyright: You have no give the license of your packaging. It might also make sense to go for DEP-5 format (http://dep.debian.net/deps/dep5/) - debian/dbxml-doc.{docs,install}: What does #DOCS# stand for? - libdbxml-java-gcj.post{inst,rm}: You must handle the various arguments that the post{inst,rm} might be called with. See http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html - debian/README.{Debian,source}: Read their contents and act accordingly. Package does not build: cd dbxml && /usr/bin/make clean make[1]: Entering directory `/home/tautschnig/debian/dbxml/dbxml-2.5.16/dbxml' make[1]: *** No rule to make target `clean'. Stop. make[1]: Leaving directory `/home/tautschnig/debian/dbxml/dbxml-2.5.16/dbxml' make: *** [clean] Error 2 You probably want to ignore errors in this step - a fresh download must be configured before doing the make clean. Hope this helps, Michael pgpgB85IXQGSZ.pgp Description: PGP signature
Re: RFS: libgis - virtual globe library
Hi Andy, Andy Spencer wrote: > I am looking for a sponsor for my package "libgis". > > * Package name: libgis > Version : 0.4.1-1 > Upstream Author : Andy Spencer (myself) > * URL : http://lug.rose-hulman.edu/code/projects/libgis/wiki > * License : GPL-3+ > Section : science > > It builds these binary packages: > libgis - A Virtual Globe library > libgis-bin - Example programs for libgis > libgis-dev - Development files for libgis > libgis-doc - HTML documentation for libgis I had a closer look at your package, and additionally to David's comments, I noticed the following: - In debian/control, libgis-bin should depend on ${shlibs:Depends} instead of listing all the libraries explicitly. And I don't think libgis-doc should Depend on libgis (but it could Recommend it, and libgis could Suggest libgis-doc). - In debian/docs, remove the ChangeLog entry; it is installed and gzipped automatically. - You should delete debian/lintian.txt (after reading it :-) ). Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101113102747.gb3...@debian.lan
Re: RFS: libgis - virtual globe library
Hello Andy, apart from Benoît's remark, which is correct, here are some comments: On Sat, 13 Nov 2010 07:19:39 +, Andy Spencer wrote: > * Package name: libgis > Version : 0.4.1-1 > Upstream Author : Andy Spencer (myself) > * URL : http://lug.rose-hulman.edu/code/projects/libgis/wiki > * License : GPL-3+ > Section : science > > It builds these binary packages: > libgis - A Virtual Globe library > libgis-bin - Example programs for libgis > libgis-dev - Development files for libgis > libgis-doc - HTML documentation for libgis IMHO, the name of your project is rather too generic ("libgis"). It should be changed to something more descriptive, but that's your choice as upstream at the end. Apart from this, you're very welcome to maintain it under the Debian GIS Team umbrella. To join us, please join the pkg-grass [0] project on alioth.debian.org. [0]: https://alioth.debian.org/projects/pkg-grass/ Here are some comments: - In debian/control, you misinterpreted the meaning of Vcs-* fields. Those should point to the location where the Debian packaging is kept, while you pointed at the upstream repository. You can choose to maintain the debian/ dir there as well, or host it on Alioth within the Debian GIS Team (which would be better for team-maintainance). - Library packaging in Debian has to follow certain policies. The binary package you're producing should be named "libgis" (i.e. libgis0, or similar). This ensures that any dependant package depends on the correct version of the library. - Why is libgis-doc an arch:any package? I didn't check its contents, but I suspect it should be arch:all. ;) - You might want to use DEP-5 format for your debian/copyright. Read more at http://dep.debian.net/deps/dep5/ . It's entirely optional, and it won't be a stopper if you leave it like it is now. - In libgis-dev.install , please avoid installing *.a files. We (as Debian) are deprecating them, and installing them in a brand new package is a bad thing. - Your package doesn't seem to be lintian clean ;-) -- you pasted lintian's output in debian/lintian.txt, and there it clearly says to a) close an ITP bug and b) use a proper name for the binary (point 2 of my comments). Next time please read it ;) - Always in the lintian warning, it says you're missing a symbols file. Since it's a C project, I strongly suggest you to make one (I personally dislike C++ symbols files, but that's just me). Please read more at http://wiki.debian.org/UsingSymbolsFiles Please re-ping me once you fixed all this, or if you have any doubt/question. Thank you for your work, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFS: libgis - virtual globe library
Hi Andy, Andy Spencer wrote: > I am looking for a sponsor for my package "libgis". > > * Package name: libgis > Version : 0.4.1-1 > Upstream Author : Andy Spencer (myself) > * URL : http://lug.rose-hulman.edu/code/projects/libgis/wiki > * License : GPL-3+ > Section : science > > It builds these binary packages: > libgis - A Virtual Globe library > libgis-bin - Example programs for libgis > libgis-dev - Development files for libgis > libgis-doc - HTML documentation for libgis I didn't really look at your package yet, but I just wanted to point out that you're not closing any bugs with this release. You're supposed to file a bug against WNPP (Work-Needing and Prospective Packages) and note in the debian/changelog entry that this package would be closing that bug. See [1] for details about the procedure. [1] http://www.debian.org/devel/wnpp/ Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101113092203.ga3...@debian.lan
Re: RFS: mediadownloader
Hi Marco, [...] (several previous reviews, you might want to acknowledge them in your changelog) Here's some more notes on your package: - debian/control: I don't quite understand what you mean by ", as well as mobile devices do." in your package description. You could probably also drop the URL, it's in the Homepage: field anyway. - debian/copyright: To the best of my knowledge, a simple is not acceptable. The optimal solution would be to even go for a DEP-5 formatted copyright file, see http://dep.debian.net/deps/dep5/ - debian/docs: lists README.txt twice - debian/rules: A debian/install (and maybe debian/dirs) should help to simplify your rules, I think. - A number of source files lack copyright- and license-information. As you are upstream, this should be fairly easy to fix. Hope this helps, Michael pgpmpSRcVb4Y6.pgp Description: PGP signature
Re: RFS: pyragua (updated package, 2nd try)
Hi, > Dear mentors, > > I am looking for a sponsor for the new version 0.2.5-2 of my package > "pyragua". > > It builds these binary packages: > pyragua- Very lightweight Python editor > > The package appears to be lintian clean. > [...] In this new version you changed to debhelper's compact rules file, with a number of overrides. Even though the results are still correct, I wonder why you do - override_dh_installchangelogs, override_dh_installmenu: I think not overriding those targets would produce exactly the same results, - override_dh_builddeb: is there a serious reason for doing that? You might also want to re-inspect all the other overrides and possibly consider to stay with debian/{docs,install,links,manpages} files instead of overriding the targets. Hope this helps, Michael pgp3PF2yUmWqf.pgp Description: PGP signature
Re: RFS: wav2cdr (updated package)
Hi Tony, I finally got around to review this package. > Dear mentors, > > I am looking for a sponsor for the new version 2.3.3-12 > of my package "wav2cdr". > > It builds these binary packages: > wav2cdr- Converts wav files into CD-ROM audio file format > > The package appears to be lintian clean. > [...] The package is mostly ready for upload, I just noticed two issues: - You updated the Standards-Version to 3.9.1 but did not document this in the changelog. Did you also check back with the checklist whether updating without changing anything was ok? - Your watchfile isn't working. And in fact it would make much more sense to use the author's web page instead of some maybe up-to-date mirror. Looking at http://volker.top.geek.nz/soft/pck/ it actually seems there is some 2.3.4 release!? Furthermore it would be great if you could persuade upstream to fix all these conversion errors that gcc reports while compiling. Hope this helps, Michael pgpp0Q1XLmbP3.pgp Description: PGP signature