Re: RFS: lebiniou, lebiniou-data
Etienne,
On Thu, Jun 30, 2011 at 08:30:54AM +0200, Etienne Millon wrote:
> > > - The dependency against lebiniou-data is not versioned. That means
> > > that lebiniou is meant to be usable with any version of
> > > lebiniou-data. In such a case I think you need to specify exactly
> > > one version. With a single source package, you could depend on
> > > lebinou-data (= ${source:Version}).
> >
> > ${binary:Version} sounds even better to me for this usecase.
>
> If I understand it correctly, ${source:Version} will allow binNMUs of
> the Arch:any package without having to provide a binNMU of the
> Arch:all package (which is impossible).
>
> Or am I missing something ?
No, you got it exactly right. I just had them two mixed up. Sorry.
--
Cheers,
Kilian
signature.asc
Description: Digital signature
Re: RFS: lebiniou, lebiniou-data
> > - The dependency against lebiniou-data is not versioned. That means
> > that lebiniou is meant to be usable with any version of
> > lebiniou-data. In such a case I think you need to specify exactly
> > one version. With a single source package, you could depend on
> > lebinou-data (= ${source:Version}).
>
> ${binary:Version} sounds even better to me for this usecase.
If I understand it correctly, ${source:Version} will allow binNMUs of
the Arch:any package without having to provide a binNMU of the
Arch:all package (which is impossible).
Or am I missing something ?
--
Etienne Millon
--
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/20110630063054.ga4...@john.ssi.corp
RFS: latex-mk (updated package)
Dear mentors, I am looking for a sponsor for the new version 2.1-1 of my package "latex-mk". It builds these binary packages: latex-mk - tool for managing LaTeX projects The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/latex-mk - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/latex-mk/latex-mk_2.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards Wences Arana -- Wences Arana nacido para ser libre Debian FTW 9455 B304 491E 1165 43C8 1B34 8678 4112 D3AC 9B13 -- 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/BANLkTi==KP4R_yvuzBg=dgucmm2+3np...@mail.gmail.com
Re: RFS: s3ql (new python application)
On 06/29/2011 09:37 AM, Kilian Krause wrote: >>> 2. You symlink your contrib scripts from /usr/share/doc (!) >>> into /usr/bin which is not really the best solution out there. Please >>> decide whether these shall either go as examples (and not symlinked >>> to /usr/bin/) or whether they are official applications - in which case >>> they don't belong into /usr/share/doc. >> >> Well, I think they are certainly not examples. I would be fine to put >> expire_backups and pcp into /usr/bin, but I think that benchmark.py and >> make_dummy.py are relatively unlikely to be called in day to day use, so >> I am hesitant to put them there. >> >> How about putting the former into /usr/bin and symlinking them from >> /usr/share/doc/s3ql/contrib (i.e., to the links the other way around)? > > If it's not share/doc/s3ql but share/s3ql I'm perfectly agreed with your > proposal. ;-) Ok, new package is on mentors: dget http://mentors.debian.net/debian/pool/main/s/s3ql/s3ql_1.0.1-2.dsc -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- 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/4e0bccdb.5090...@rath.org
Re: RFS: webhoneypot (4th and last try)
Le mercredi 29 juin 2011 23:07:09, Matteo Cypriani a écrit : > Hi Christian, > > I had a quick look at your package, and here are some remarks. > > First, the project's page mention the following: > "This project is used to develop the honeypot. Do not use this code to > install a honeypot unless you are interested in helping development." > I wonder if such a program can enter the Debian archive. Maybe a DD > could give his opinion about that? To me it doesn't seem like a restriction but more like an advice. Except if it appears in source file's header or LICENSE/COPYING file, I don't think there is an issue here. Note that I'm not DD myself. > > About the packaging itself, I think you could use debhelper 8 and > simplify debian/rules. > > debian/source/format: > There is an extra blank line, I don't know if it is disturbing or not. > > debian/README.debian should be debian/README.Debian. > > debian/manpages/webhoneypot.1: > -Please see /usr/share/doc/webhoneypot/README.debian for details. > +Please see /usr/share/doc/webhoneypot/README.Debian for details. > > debian/copyright: > * Consider updating to the last DEP-5 format (there is a lot of changes > since r135). > * The "Licence" field should include the GPL copyright notice header. > * You should mention the copyright and license information for the > packaging files with a section "Files: debian/*". Tip: you can use config-edit to update, with config-edit -application dpkg- copyright -ui none -save Then review the changes done to the copyright file. > > debian/patches/debian-changes-0.1.r123-1: > I think you should split this into several patches and document what > each patch is for, preferably using the DEP-3 format. And also rename the patches. A patch with this name seems like created automatically by dpkg-source because there was some changes outside the debian/ directory. Note that I didn't look at your source package so this is pure speculation. > > Hope this helps, > > Matteo Best regards, Thomas Preud'homme -- 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/201106292358.14166.thomas.preudho...@celest.fr
Re: RFS: tnat64 -- IPv4 to NAT64 redirector
* Andrew O. Shadoura , 2011-06-30, 00:30: 5. Lintian issues (lintian -iI --pedantic): W: tnat64: package-name-doesnt-match-sonames libtnat64-0.1 W: tnat64: non-dev-pkg-with-shlib-symlink usr/lib/libtnat64.so.0.1 usr/lib/libtnat64.so I: tnat64: no-symbols-control-file usr/lib/libtnat64.so.0.1 Isn't really relevant, as this is a LD_PRELOAD-able library. Then there's no reason to install the library into /usr/lib. Install it to a private directory instead. And you don't need any symlinks either. -- Jakub Wilk -- 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/20110629213931.ga6...@jwilk.net
Re: RFS: tnat64 -- IPv4 to NAT64 redirector
Hello, On Wed, 29 Jun 2011 16:11:56 -0500 Elías Alejandro wrote: > I am not a DD, so I can't sponsor your contribution. I'm sorry. But > here my fast review about your package: > 1. Bump Standards-Version to 3.9.2 Yes, I know. > 2. Maybe you can use debhelper version 8 under: debian/compat, > debian/control Possibly. > 3. debian/copyright: please use DEP-5 format[0] I don't think it's a good idea. > 4. Newest version on remote site is 0.03 I know, I'm the upstream. > 5. Lintian issues (lintian -iI --pedantic): >W: tnat64: package-name-doesnt-match-sonames libtnat64-0.1 >W: tnat64: non-dev-pkg-with-shlib-symlink usr/lib/libtnat64.so.0.1 > usr/lib/libtnat64.so I: tnat64: no-symbols-control-file > usr/lib/libtnat64.so.0.1 Isn't really relevant, as this is a LD_PRELOAD-able library. -- WBR, Andrew signature.asc Description: PGP signature
Re: RFS: webhoneypot (4th and last try)
Hi Christian, I had a quick look at your package, and here are some remarks. First, the project's page mention the following: "This project is used to develop the honeypot. Do not use this code to install a honeypot unless you are interested in helping development." I wonder if such a program can enter the Debian archive. Maybe a DD could give his opinion about that? About the packaging itself, I think you could use debhelper 8 and simplify debian/rules. debian/source/format: There is an extra blank line, I don't know if it is disturbing or not. debian/README.debian should be debian/README.Debian. debian/manpages/webhoneypot.1: -Please see /usr/share/doc/webhoneypot/README.debian for details. +Please see /usr/share/doc/webhoneypot/README.Debian for details. debian/copyright: * Consider updating to the last DEP-5 format (there is a lot of changes since r135). * The "Licence" field should include the GPL copyright notice header. * You should mention the copyright and license information for the packaging files with a section "Files: debian/*". debian/patches/debian-changes-0.1.r123-1: I think you should split this into several patches and document what each patch is for, preferably using the DEP-3 format. Hope this helps, Matteo signature.asc Description: This is a digitally signed message part.
Re: RFS: tnat64 -- IPv4 to NAT64 redirector
Hi, I am not a DD, so I can't sponsor your contribution. I'm sorry. But here my fast review about your package: 1. Bump Standards-Version to 3.9.2 2. Maybe you can use debhelper version 8 under: debian/compat, debian/control 3. debian/copyright: please use DEP-5 format[0] 4. Newest version on remote site is 0.03 5. Lintian issues (lintian -iI --pedantic): W: tnat64: package-name-doesnt-match-sonames libtnat64-0.1 W: tnat64: non-dev-pkg-with-shlib-symlink usr/lib/libtnat64.so.0.1 usr/lib/libtnat64.so I: tnat64: no-symbols-control-file usr/lib/libtnat64.so.0.1 [0] http://dep.debian.net/deps/dep5/ Regards, -- Elías Alejandro -- 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/20110629211156.GC2316@debianero
Re: mrim-prpl sponsorship
Hi again, debian/watch can be improved, clean initial comments and check[0] then test with: uscan --no-download --verbose [0] http://googlecode.debian.net/ Regards, -- Elías Alejandro -- 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/20110629204830.GB2316@debianero
Re: mrim-prpl sponsorship
Hi, I am not a DD, and so I can't sponsor your contribution. I'm sorry. But here my fast review about your package: 1. debian/changelog, seems it first Debian release?. just include a first release (no other version that no appear officially under Debian) also please read[0] to improve your entries. 2. Bump Standards-Version to 3.9.2 3. debhelper is 7. Bump to 8 under: debian/compat, debian/control 4. debian/copyright: please use DEP-5 format[1] 5. debian/rules: clean the initial comment. why, mkdir -p $(CURDIR)/debian/mrim-prpl/usr/lib/purple-2 ? it seems be enough with debian/dirs content (please check out) 7. it stops building: I: Copying back the cached apt archive contents I: Copying source file I: copying [mrim-prpl_0.1.28~rc1-1.dsc] I: copying [./mrim-prpl_0.1.28~rc1.orig.tar.gz] I: copying [./mrim-prpl_0.1.28~rc1-1.debian.tar.gz] I: copying [./SIGNATURE-] cp: cannot stat `./SIGNATURE-': No such file or directory [0] http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-debian-changelog [1] http://dep.debian.net/deps/dep5/ Regards, -- Elías Alejandro -- 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/20110629203754.GA2316@debianero
Re: RFS: ps2eps (updated package)
Hi Matteo, On Wed, Jun 29, 2011 at 06:36:05PM +0200, Matteo Cypriani wrote: > Le mercredi 29 juin 2011 18:14:14, Kilian Krause a écrit : > > On Wed, Jun 29, 2011 at 05:51:28PM +0200, Matteo Cypriani wrote: > > > Yes, I though this was not an issue because the binary are small. > > > I will try to negotiate with upstream a binary-free tarball, and if > > > possible with the source DocBook file to generate the manpages, instead > > > of including the useless PDF and HTML versions. > > > If it is not possible for upstream, I'll repack > > > > it's not about "small" or "useful". It's about license and copyright. > > The license should be satisfied, since the source is shipped, no? It seems to > me that it is a problem only if the binaries come from a modified, unshipped > source (which I admit is not easily provable). You may be right that the license is the same as the source. Yet it's a derived work that *may* be licensed differently depending on who did the build and what license he put onto his binary. That's why this has to be clarified for each and every file in a source package - even pictures, fonts, audio/video files and documentation like PDF have to have a license. Moreover that's why GFDL and others were written to overcome the problem that plain GPL does have with binary stuff - because the GPL more than others has a problem adressing non-source code as it was never formulated to cover binaries (at least GPL-2). So the problem may in fact be that the binary is GPL but that cannot be satisfied with the formulation of the GPL terms. > > Always. And sometimes about security and trustability. > > The binaries are not in the final package, so why would it be a security > issue > for the end-user? And new upstream releases may consider it a wise thing to put certain wrappers in and make the install target ship one of the prebuilt binary blobs which keeps the user's view totally untouched. Yet your package just got broken wrt. the DFSG. Would you notice? Not to mention users who download the source and would believe the "other" binary is so much better than the one from the deb. How do you make sure this one does not have any backdoors compiled in? The latter issues were more of illustrating nature though and not specifically with this case in mind. -- Best regards, Kilian signature.asc Description: Digital signature
Re: RFS: phing (another try)
Hi, thanks I will fix that soon. Regards, Nicolas 2011/6/29 Elías Alejandro > Hi, > I'm not DD. I'm sorrry. This my fast review about your package: > > 1. debhelper is 7. Bump to 8 under: debia/compat , debian/control > 2. Bump Standards-Version to 3.9.2 > 3. no necessary quilt as build-dependency[0] > 4. under debian/copyright specify license version, LGPL-3 (i.e) > 5. for your patch, use DEP-3 format [1] cleaning "#'s" > 6. clean the coments from debian/rules, uhm... seems it could be just > (please try it): > dh $@ > > > [0] > http://wiki.debian.org/Projects/DebSrc3.0#Does_a_3.0_.28quilt.29_source_package_need_to_build-depend_on_quilt.3F > [1] http://dep.debian.net/deps/dep3/ > > Regards, > > > -- > Elías Alejandro > > > -- > 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/20110629170300.GB2308@debianero > >
Re: RFS: winefish
Hi, On Tue, Jun 28, 2011 at 07:51:14PM -0500, Ruben Molina wrote: > I'm not a DD, but I had done a short review of your package... Also me, here my fast review about your package only to add: > > You need to work in your debian/copyright, because the package's license > is GPL-2+, and not just GPL, and you are missing lots of entries, e.g.: > There are many files © by Olivier Sessink, Eugene Morenko, Chris Mazuc, > Oskar Swida, Pablo De Napoli, or the Winefish Development Team ... > You should probably take a look at: http://dep.debian.net/deps/dep5/ > > Also, you should clean your debian/rules, all those commented lines can > be safely removed, and you can probably use some debhelper's tiny rules > here... Please take a look at /usr/share/doc/debhelper/examples/ 1. Bump Standards-Version to 3.9.2 2. debhelper is 7. Bump to 8 under: debian/compat, debian/control 3. fail building: /usr/bin/install -c -m 644 inline_images/winefish_icon1.png /usr/share/pixmaps/winefish-icon.png /usr/bin/install: cannot create regular file `/usr/share/pixmaps/winefish-icon.png': Permission denied make[1]: *** [install-icon] Error 1 make[1]: Leaving directory `/tmp/buildd/winefish-1.3.3' make: *** [install] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 Regards, -- Elías Alejandro -- 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/20110629175733.GE2308@debianero
Re: RFS: mesk
Hi, I am not a DD, and so I can't sponsor your contribution. I'm sorry. But here my fast review about your package: 1. Bump Standards-Version to 3.9.2 2. debhelper is 7. Bump to 8 under: debia/compat, debian/control 3. debian/copyright: please use DEP-5 format[0] 4. debian/rules: clean the initial comment 5. your patch could be under DEP-3 format[1] 6. Lintian issues: - extended-description-is-probably-too-short - empty-binary-package [0] http://dep.debian.net/deps/dep5/ [1] http://dep.debian.net/deps/dep3/ -- Elías Alejandro -- 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/20110629174342.GD2308@debianero
Re: RFS: Rodent Beta filemanager
Hi, I am not a DD, and so I can't sponsor your contribution. I'm sorry. But here my fast review about your package: 1. debian/changelog: no close some bug, ITP or ITA? So clean: "(Closes: #) " and your initial Debian release should be 4.6.2-1 no just 4.6.2 2. debhelper is 7. Bump to 8 under: debia/compat , debian/control 3. Bump Standards-Version to 3.9.2 4. Vcs-SVN, and Vcs-browser should be just for Debian packaging work no upstream works. 5. debian/copyright: please use DEP-5 format[0] and complete the fields please. 6. debian/rules: clean verbose comment 7. your files: README.Debian, README.source, rodent-doc.docs, rodent-doc.install seems useless, please check if really they should be there. [0] http://dep.debian.net/deps/dep5/ Regards, -- Elías Alejandro -- 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/20110629172059.GC2308@debianero
Re: RFS: phing (another try)
Hi, I'm not DD. I'm sorrry. This my fast review about your package: 1. debhelper is 7. Bump to 8 under: debia/compat , debian/control 2. Bump Standards-Version to 3.9.2 3. no necessary quilt as build-dependency[0] 4. under debian/copyright specify license version, LGPL-3 (i.e) 5. for your patch, use DEP-3 format [1] cleaning "#'s" 6. clean the coments from debian/rules, uhm... seems it could be just (please try it): dh $@ [0] http://wiki.debian.org/Projects/DebSrc3.0#Does_a_3.0_.28quilt.29_source_package_need_to_build-depend_on_quilt.3F [1] http://dep.debian.net/deps/dep3/ Regards, -- Elías Alejandro -- 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/20110629170300.GB2308@debianero
Re: RFS: ps2eps (updated package)
Le mercredi 29 juin 2011 18:14:14, Kilian Krause a écrit : > On Wed, Jun 29, 2011 at 05:51:28PM +0200, Matteo Cypriani wrote: > > Yes, I though this was not an issue because the binary are small. > > I will try to negotiate with upstream a binary-free tarball, and if > > possible with the source DocBook file to generate the manpages, instead > > of including the useless PDF and HTML versions. > > If it is not possible for upstream, I'll repack > > it's not about "small" or "useful". It's about license and copyright. The license should be satisfied, since the source is shipped, no? It seems to me that it is a problem only if the binaries come from a modified, unshipped source (which I admit is not easily provable). > Always. And sometimes about security and trustability. The binaries are not in the final package, so why would it be a security issue for the end-user? Matteo -- Ma clef GPG est disponible sur keyserver.veridis.com My GPG key is available on keyserver.veridis.com signature.asc Description: This is a digitally signed message part.
Re: RFS: lebiniou, lebiniou-data
Hi,
On Wed, Jun 29, 2011 at 05:54:49PM +0200, Etienne Millon wrote:
> debian/control
> --
>
> - The VCS-* fields should be relative to the debian packaging, not
> the upstream repository. From what I've seen, this source package
> has been generated from the upstream "debian/" subdirectory. This
> is misleading because you can't easily export a tarball and use it
> as a .orig file.
>
> As you are the upstream author, I suggest that you use a single
> source package to build these two binary packages (one .dsc, two
> .debs). That should ease maintenance, including the following
> point.
>
> - The dependency against lebiniou-data is not versioned. That means
> that lebiniou is meant to be usable with any version of
> lebiniou-data. In such a case I think you need to specify exactly
> one version. With a single source package, you could depend on
> lebinou-data (= ${source:Version}).
>
Also, debhelper is 7. Bump to 8 under: debia/compat , debian/control
Regards,
--
Elías Alejandro
--
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/20110629164011.GA2308@debianero
Re: RFS: lebiniou, lebiniou-data
Hi,
On Wed, Jun 29, 2011 at 05:54:49PM +0200, Etienne Millon wrote:
> A few extra remarks from a non-DD :
>
> debian/control
> --
>
> - The VCS-* fields should be relative to the debian packaging, not
> the upstream repository. From what I've seen, this source package
> has been generated from the upstream "debian/" subdirectory. This
> is misleading because you can't easily export a tarball and use it
> as a .orig file.
Thanks for pointing this out. The problem generally is that updating the
debian package otherwise would demand for a new upstream release if this is
not split apart. That's usually not what you want.
Therefore please only make a Debian-native (upstream=Debian, version without
-number suffix) package for stuff that is exclusively targetted at Debian
and can receive new releases anytime the Debian version asks for it.
> As you are the upstream author, I suggest that you use a single
> source package to build these two binary packages (one .dsc, two
> .debs). That should ease maintenance, including the following
> point.
Sounds good to me.
> - The dependency against lebiniou-data is not versioned. That means
> that lebiniou is meant to be usable with any version of
> lebiniou-data. In such a case I think you need to specify exactly
> one version. With a single source package, you could depend on
> lebinou-data (= ${source:Version}).
${binary:Version} sounds even better to me for this usecase.
--
Best regards,
Kilian
signature.asc
Description: Digital signature
Re: RFS: ps2eps (updated package)
Hi Matteo, On Wed, Jun 29, 2011 at 05:51:28PM +0200, Matteo Cypriani wrote: > Wow, that was really quick! Heh, happens if you do this more often and have your tools quite ready at hand. ;-) > Le mercredi 29 juin 2011 16:32:49, Kilian Krause a écrit : > > 1. Your package source still contains binaries in bin/linux, bin/win, > > bin mac-os-x, bin/hpux ... > > > > Please prepare a DFSG-repack and remove *all* binary blobs. Using the > > get-orig-source target will help with this. If you need a copy-template > > feel free to ping me. > > > > As this was already present in the old version, I'm letting this > > through. I wonder how they got past ftpmasters anyway. > > Yes, I though this was not an issue because the binary are small. > I will try to negotiate with upstream a binary-free tarball, and if possible > with the source DocBook file to generate the manpages, instead of including > the > useless PDF and HTML versions. > If it is not possible for upstream, I'll repack it's not about "small" or "useful". It's about license and copyright. Always. And sometimes about security and trustability. > > 2. debian/patches/minus-sign-manpages.diff does not contain any notion > > that it was forwarded upstream. > > That's true, I'll discuss this with upstream, but it seems that the manpage > is > generated, so it might be complicated. Then even more so. ;-) > > 3. I see no good reason to not ship README.txt as is but to rename it to > > README > > My bad, I just kept the behaviour of the old package without thinking too > much :-) Heh. Can happen. ;-) > > 4. Have you tried to have a look at #236049? > > I had a quick look. It is marked as forwarded, and I don't really have time > to > fix that by myself currently. I'll ask upstream if this had really been > forwarded. That was my intention. Thanks! > > 5. dpi is an acronym and should be capitalized in the description > > OK. > > > > Anyway, built, signed, uploaded. > > > > Thanks for stepping up as new maintainer! > > And thanks a lot for helping us in that way… so quickly! No problem. My pleasure. Keep up the good work and take good care of your new package! -- Best regards, Kilian signature.asc Description: Digital signature
RFS: qasmixer
To: debian-mentors@lists.debian.org Dear mentors, I am looking for a sponsor for my package "qasmixer". * Package name: qasmixer Version : 0.12.0-3 Upstream Author : Sebastian Holtermann * URL : http://xwmw.org/qasmixer/ * License : GPL V3 Section : multimedia It builds these binary packages: qasmixer - A mixer for the Linux sound system ALSA powered by a QT GUI My motivation for maintaining this package is: I'm the author of qasmixer and would like to have it in my favourite distribution Debian. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/qasmixer - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/qasmixer/qasmixer_0.12.0-3.dsc I would be glad if someone uploaded this package for me. Kind regards Sebastian Holtermann -- 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/4e0b4c0b.9000...@gmx.de
Re: RFS: lebiniou, lebiniou-data
Hello,
A few extra remarks from a non-DD :
debian/control
--
- The VCS-* fields should be relative to the debian packaging, not
the upstream repository. From what I've seen, this source package
has been generated from the upstream "debian/" subdirectory. This
is misleading because you can't easily export a tarball and use it
as a .orig file.
As you are the upstream author, I suggest that you use a single
source package to build these two binary packages (one .dsc, two
.debs). That should ease maintenance, including the following
point.
- The dependency against lebiniou-data is not versioned. That means
that lebiniou is meant to be usable with any version of
lebiniou-data. In such a case I think you need to specify exactly
one version. With a single source package, you could depend on
lebinou-data (= ${source:Version}).
Hope that helps,
--
Etienne Millon
--
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/20110629155449.gb21...@john.ssi.corp
Re: RFS: ps2eps (updated package)
Hi Kilian, Wow, that was really quick! Le mercredi 29 juin 2011 16:32:49, Kilian Krause a écrit : > 1. Your package source still contains binaries in bin/linux, bin/win, > bin mac-os-x, bin/hpux ... > > Please prepare a DFSG-repack and remove *all* binary blobs. Using the > get-orig-source target will help with this. If you need a copy-template > feel free to ping me. > > As this was already present in the old version, I'm letting this > through. I wonder how they got past ftpmasters anyway. Yes, I though this was not an issue because the binary are small. I will try to negotiate with upstream a binary-free tarball, and if possible with the source DocBook file to generate the manpages, instead of including the useless PDF and HTML versions. If it is not possible for upstream, I'll repack > 2. debian/patches/minus-sign-manpages.diff does not contain any notion > that it was forwarded upstream. That's true, I'll discuss this with upstream, but it seems that the manpage is generated, so it might be complicated. > 3. I see no good reason to not ship README.txt as is but to rename it to > README My bad, I just kept the behaviour of the old package without thinking too much :-) > 4. Have you tried to have a look at #236049? I had a quick look. It is marked as forwarded, and I don't really have time to fix that by myself currently. I'll ask upstream if this had really been forwarded. > 5. dpi is an acronym and should be capitalized in the description OK. > Anyway, built, signed, uploaded. > > Thanks for stepping up as new maintainer! And thanks a lot for helping us in that way… so quickly! Matteo -- Ma clef GPG est disponible sur keyserver.veridis.com My GPG key is available on keyserver.veridis.com signature.asc Description: This is a digitally signed message part.
Re: RFS: lebiniou, lebiniou-data
Hi Olivier, On 05/04/11 18:24, Olivier Girondel wrote: > Dear mentors, > > I am looking for a sponsor for my packages "lebiniou" and > "lebiniou-data". Sadly I am not a DD, but I am responding to Michael's request for non-DDs to review packages. (http://lists.debian.org/debian-mentors/2011/06/msg00388.html) Technical quality of the package is overall very good. Not to mention the program itself is very impressive, I'll definitely be using it in the future. wrt to debian/copyright file there are a few issues: * You might consider using DEP-5 as a best practice, this is up to you. * You should probably mention the original author and license of src/pnglite.[ch] in the copyright file. * You should mention the copyright on fonts/FreeMono.ttf and preferably ship the source if possible. Alternatively, repack and exclude it. (About the latter, I see that in Makefile.am you use --enable-debian to disable installing the fonts. I would say as a matter of style you should keep all debian-specific tweaks inside the 'debian' directory. Arguably it's better to patch the Makefile than to put this option in. Regardless of where you put the option, though, everything in the _source_ package needs a copyright statement.) * In lebiniou-data, I'm loving the images! Many of them are homemade, but some of them look like they might be copyrighted. All these images need license statements in debian/copyright. I'm guessing it won't be practical to dig up these for some of them, so if I were you I would just strip out the potentially problematic ones and only leave the ones you are sure about. * Manpage is lebiniou.6, but I'm not sure if Le Biniou would be called a "game", though you can see it as one. I'd be comfortable with it under section 1. * A few natural language nit picks about the description: "When you run Le Biniou it gives a revolutionary rendering of the sound you are playing." I don't disagree that it's revolutionary ;) but evolutionary might fit better with the short package description. "chose your own series of pictures" You probably mean 'choose' "discover a multidimensional –spatial and chromatic– way" Dash separation normally looks like " - ". You want a space before 'spatial' and a space after 'chromatic'. "comprehending musics and sounds" 'Musics' is actually a valid plural but that's quite a strange academic usage, I'm guessing you meant just 'music'. * I would prefer to have sequences.tar.gz installed unpacked, as it's very small. No big deal though. * The program didn't seem to detect audio from Rhythmbox out of the box, presumably as it was trying to use the alsa plugin where rhythmbox uses pulseaudio. Maybe consider adding a note to the manual about how to switch the audio plugin, for new users. Nice work! One step closer. ;) Cheers, David -- 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/iuffc7$3si$1...@dough.gmane.org
Re: RFS: ps2eps (updated package)
Hi Matteo, On Wed, 2011-06-29 at 15:41 +0200, Matteo Cypriani wrote: > Hi all, > > I am looking for a sponsor for the new version 1.68-1 of my package "ps2eps". > > It builds these binary packages: > ps2eps - convert PostScript to EPS (Encapsulated PostScript) files > > The package appears to be lintian clean. > > The upload would no bug except the ITA (#534380), but it introduces a new > upstream release and the packaging was modernised. > The changes can be seen in the collab-maint Git repository: > http://anonscm.debian.org/gitweb/?p=collab-maint/ps2eps.git > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/p/ps2eps > - Source repository: deb-src http://mentors.debian.net/debian unstable main > - dget http://mentors.debian.net/debian/pool/main/p/ps2eps/ps2eps_1.68-1.dsc > > I would be glad if someone uploaded this package for me. Thanks for your work. My comments are: 1. Your package source still contains binaries in bin/linux, bin/win, bin mac-os-x, bin/hpux ... Please prepare a DFSG-repack and remove *all* binary blobs. Using the get-orig-source target will help with this. If you need a copy-template feel free to ping me. As this was already present in the old version, I'm letting this through. I wonder how they got past ftpmasters anyway. 2. debian/patches/minus-sign-manpages.diff does not contain any notion that it was forwarded upstream. 3. I see no good reason to not ship README.txt as is but to rename it to README 4. Have you tried to have a look at #236049? 5. dpi is an acronym and should be capitalized in the description Anyway, built, signed, uploaded. Thanks for stepping up as new maintainer! -- Best regards, Kilian signature.asc Description: This is a digitally signed message part
Re: OpenMPI-bin missing on some arches (Was: mrbayes-mpi: uninstallable on mipsen and s390)
On 29 June 2011 at 08:30, Dirk Eddelbuettel wrote:
|
| On 29 June 2011 at 15:01, Andreas Tille wrote:
| | Hi,
| |
| | > Your package is uninstallable on some archs:
| | >
| | >mrbayes-mpi/mips unsatisfiable Depends: openmpi-bin
| | >mrbayes-mpi/mipsel unsatisfiable Depends: openmpi-bin
| | >mrbayes-mpi/s390 unsatisfiable Depends: openmpi-bin
| |
| | I admit I'm not so comfortable with these architectures. Is there any
| | drop-in replacement for openmpi on these and if yes, what do I need to
| | specify in debian/{control,rules}?
|
| There is. We are simply slow in implementing this for all packages.
|
| [ Long and boring story: MPICH was never in Debian, LAM deprecated, OpenMPI
| undermaintained. I adopted it a few years ago; Manuel then took over. Open
| MPI _upstream_ never had support for certain arches (for performance / ASM
| use reasons) so we always had these 'holess'. ]
[ Forgot add here that now that we have proper MPICH2 everywhere, it serves
as a fallback where Open MPI --- which AFAIK is still the default where
available --- cannot be used. ]
Dirk
| The situation is mostly fixed and automatic now. Instead of depending on
| openmpi, just depend in mpi-default-dev and everything should just work (TM).
|
| | Could any other package with the same problem serve as an example?
|
| Here is what my pgapack package does:
|
|Build-Depends: debhelper (>= 7.0), mpi-default-dev
|
| and here is my Rmpi package (which also needs R):
|
|Build-Depends: debhelper (>= 7.0.0), cdbs, r-base-dev (>= 2.12.0),
mpi-default-dev
|
| Hope this helps, Dirk
|
| | Kind regards
| |
| |Andreas.
| |
| | --
| | http://fam-tille.de
| |
| |
| | --
| | To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
| | with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org
| | Archive: http://lists.debian.org/20110629130159.ga13...@an3as.eu
| |
|
| --
| Gauss once played himself in a zero-sum game and won $50.
| -- #11 at http://www.gaussfacts.com
|
|
| --
| To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
| with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
| Archive: http://lists.debian.org/19979.10474.628037.729...@max.nulle.part
|
--
Gauss once played himself in a zero-sum game and won $50.
-- #11 at http://www.gaussfacts.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/19979.12416.328142.51...@max.nulle.part
RFS: ps2eps (updated package)
Hi all, I am looking for a sponsor for the new version 1.68-1 of my package "ps2eps". It builds these binary packages: ps2eps - convert PostScript to EPS (Encapsulated PostScript) files The package appears to be lintian clean. The upload would no bug except the ITA (#534380), but it introduces a new upstream release and the packaging was modernised. The changes can be seen in the collab-maint Git repository: http://anonscm.debian.org/gitweb/?p=collab-maint/ps2eps.git The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/ps2eps - Source repository: deb-src http://mentors.debian.net/debian unstable main - dget http://mentors.debian.net/debian/pool/main/p/ps2eps/ps2eps_1.68-1.dsc I would be glad if someone uploaded this package for me. Cheers, Matteo -- Ma clef GPG est disponible sur keyserver.veridis.com My GPG key is available on keyserver.veridis.com signature.asc Description: This is a digitally signed message part.
Re: OpenMPI-bin missing on some arches (Was: mrbayes-mpi: uninstallable on mipsen and s390)
On 29 June 2011 at 15:01, Andreas Tille wrote:
| Hi,
|
| > Your package is uninstallable on some archs:
| >
| >mrbayes-mpi/mips unsatisfiable Depends: openmpi-bin
| >mrbayes-mpi/mipsel unsatisfiable Depends: openmpi-bin
| >mrbayes-mpi/s390 unsatisfiable Depends: openmpi-bin
|
| I admit I'm not so comfortable with these architectures. Is there any
| drop-in replacement for openmpi on these and if yes, what do I need to
| specify in debian/{control,rules}?
There is. We are simply slow in implementing this for all packages.
[ Long and boring story: MPICH was never in Debian, LAM deprecated, OpenMPI
undermaintained. I adopted it a few years ago; Manuel then took over. Open
MPI _upstream_ never had support for certain arches (for performance / ASM
use reasons) so we always had these 'holess'. ]
The situation is mostly fixed and automatic now. Instead of depending on
openmpi, just depend in mpi-default-dev and everything should just work (TM).
| Could any other package with the same problem serve as an example?
Here is what my pgapack package does:
Build-Depends: debhelper (>= 7.0), mpi-default-dev
and here is my Rmpi package (which also needs R):
Build-Depends: debhelper (>= 7.0.0), cdbs, r-base-dev (>= 2.12.0),
mpi-default-dev
Hope this helps, Dirk
| Kind regards
|
|Andreas.
|
| --
| http://fam-tille.de
|
|
| --
| To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
| with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
| Archive: http://lists.debian.org/20110629130159.ga13...@an3as.eu
|
--
Gauss once played himself in a zero-sum game and won $50.
-- #11 at http://www.gaussfacts.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/19979.10474.628037.729...@max.nulle.part
Re: RFS: s3ql (new python application)
On 06/29/2011 03:02 AM, Kilian Krause wrote: > Nikolaus, > > On Tue, 2011-06-28 at 14:56 -0400, Nikolaus Rath wrote: >> dget http://mentors.debian.net/debian/pool/main/s/s3ql/s3ql_1.0.1-1.dsc > > thanks for the update. > > 1. Regarding the example scrips you ship I'm sort of undecided whether > they would actually fit better in examples rather than "contrib". I > guess yes. > > usr/share/doc/s3ql/contrib/benchmark.py > usr/share/doc/s3ql/contrib/expire_backups.py > usr/share/doc/s3ql/contrib/make_dummy.py > usr/share/doc/s3ql/contrib/pcp.py I don't quite agree. These are not examples of any sort, but programs that can be useful in combination with S3QL. > usr/share/doc/s3ql/contrib/s3ql_backup.sh This could arguably be called an example, yes. But I think it would be nice to stick with the upstream layout (where all these are in contrib), so that people can use e.g. the online documentation (which explicitly refers to scripts in contrib). > > 2. You symlink your contrib scripts from /usr/share/doc (!) > into /usr/bin which is not really the best solution out there. Please > decide whether these shall either go as examples (and not symlinked > to /usr/bin/) or whether they are official applications - in which case > they don't belong into /usr/share/doc. Well, I think they are certainly not examples. I would be fine to put expire_backups and pcp into /usr/bin, but I think that benchmark.py and make_dummy.py are relatively unlikely to be called in day to day use, so I am hesitant to put them there. How about putting the former into /usr/bin and symlinking them from /usr/share/doc/s3ql/contrib (i.e., to the links the other way around)? > Anyway, built, signed, uploaded. Thanks! Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- 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/4e0b28f3.10...@rath.org
Re: RFS: s3ql (new python application)
Hi Nikolaus, On Wed, 2011-06-29 at 09:30 -0400, Nikolaus Rath wrote: > On 06/29/2011 03:02 AM, Kilian Krause wrote: > > Nikolaus, > > > > On Tue, 2011-06-28 at 14:56 -0400, Nikolaus Rath wrote: > >> dget http://mentors.debian.net/debian/pool/main/s/s3ql/s3ql_1.0.1-1.dsc > > > > thanks for the update. > > > > 1. Regarding the example scrips you ship I'm sort of undecided whether > > they would actually fit better in examples rather than "contrib". I > > guess yes. > > > > usr/share/doc/s3ql/contrib/benchmark.py > > usr/share/doc/s3ql/contrib/expire_backups.py > > usr/share/doc/s3ql/contrib/make_dummy.py > > usr/share/doc/s3ql/contrib/pcp.py > > I don't quite agree. These are not examples of any sort, but programs > that can be useful in combination with S3QL. Then they are IMHO still wrong in *DOC* and belong into /usr/share/s3ql (instead of /usr/share/doc/s3ql) - with or without a symlink to /usr/bin. > > usr/share/doc/s3ql/contrib/s3ql_backup.sh > > This could arguably be called an example, yes. But I think it would be > nice to stick with the upstream layout (where all these are in contrib), > so that people can use e.g. the online documentation (which explicitly > refers to scripts in contrib). in contrib under doc/? > > 2. You symlink your contrib scripts from /usr/share/doc (!) > > into /usr/bin which is not really the best solution out there. Please > > decide whether these shall either go as examples (and not symlinked > > to /usr/bin/) or whether they are official applications - in which case > > they don't belong into /usr/share/doc. > > Well, I think they are certainly not examples. I would be fine to put > expire_backups and pcp into /usr/bin, but I think that benchmark.py and > make_dummy.py are relatively unlikely to be called in day to day use, so > I am hesitant to put them there. > > How about putting the former into /usr/bin and symlinking them from > /usr/share/doc/s3ql/contrib (i.e., to the links the other way around)? If it's not share/doc/s3ql but share/s3ql I'm perfectly agreed with your proposal. ;-) -- Best regards, Kilian signature.asc Description: This is a digitally signed message part
Re: OpenMPI-bin missing on some arches (Was: mrbayes-mpi: uninstallable on mipsen and s390)
On Wed, 2011-06-29 at 15:01 +0200, Andreas Tille wrote:
> Hi,
>
> > Your package is uninstallable on some archs:
> >
> >mrbayes-mpi/mips unsatisfiable Depends: openmpi-bin
> >mrbayes-mpi/mipsel unsatisfiable Depends: openmpi-bin
> >mrbayes-mpi/s390 unsatisfiable Depends: openmpi-bin
>
> I admit I'm not so comfortable with these architectures. Is there any
> drop-in replacement for openmpi on these and if yes, what do I need to
> specify in debian/{control,rules}? Could any other package with the
> same problem serve as an example?
>
Try mpich2, or better still use mpi-defaults (mpi-defaults-dev).
mpi-defaults is a dummy package that pulls in what we deem to be the
most reliable mpi implementation for the architecture, which on those
arches is mpich2 not openmpi. lam4 is an alternate option, it was
previously the mpi-default but is currently being deprecated in favour
of mpich2.
Hope that helps,
Drew
--
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/1309353540.928.48.camel@pug
OpenMPI-bin missing on some arches (Was: mrbayes-mpi: uninstallable on mipsen and s390)
Hi,
> Your package is uninstallable on some archs:
>
>mrbayes-mpi/mips unsatisfiable Depends: openmpi-bin
>mrbayes-mpi/mipsel unsatisfiable Depends: openmpi-bin
>mrbayes-mpi/s390 unsatisfiable Depends: openmpi-bin
I admit I'm not so comfortable with these architectures. Is there any
drop-in replacement for openmpi on these and if yes, what do I need to
specify in debian/{control,rules}? Could any other package with the
same problem serve as an example?
Kind regards
Andreas.
--
http://fam-tille.de
--
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/20110629130159.ga13...@an3as.eu
Re: Compiling Qt translation files
On 2011-06-29, Dmitry Shachnev wrote: > Will it be better if I provide .ts text-format source for translations > and compile them during build? This will add a big build-dependency on > Qt. the Qt linguist tools have recently been split out from the qt dev tools to make it easier to just require those. /Sune -- 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/slrnj0lsoi.p7v.nos...@sshway.ssh.pusling.com
Re: RFS: gadmin-proftpd (adopted, updated package)
Hello Kilian
On 06/27/2011 02:00 AM, Kilian Krause wrote:
>
> And I see during compilation that /var/log/secure and /var/log/xferlog are
> used. IIRC the default for proftpd is /var/log/proftpd/{secure,xferlog}. Do
> you
> reckon running gadmin-proftpd works ok?
Works well at here, but i'll investigate about it.
>
> From your changelog:
> * debian/patches/03-desktop.patch: Removing encoding field.
> => why is that needed? Having UTF-8 explicitly spelled out doesn't feel bad
> to me.
as per freedesktop spec and desktop-file-validator, a desktop file must
not contain encoding field. cmiiw
>
> * debian/patches/04-spell_in_binary.patch: Fix typos in binary.
> => there is no notion this one was pushed upstream. I would suggest to do
> that if not already done.
Ok, i'll send to upstream
>
> Further I see:
> dpkg-shlibdeps: warning: dependency on libfontconfig.so.1 could be avoided if
> "debian/gadmin-proftpd/usr/sbin/gadmin-proftpd" were not uselessly linked
> against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libm.so.6 could be avoided if
> "debian/gadmin-proftpd/usr/sbin/gadmin-proftpd" were not uselessly linked
> against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on librt.so.1 could be avoided if
> "debian/gadmin-proftpd/usr/sbin/gadmin-proftpd" were not uselessly linked
> against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libgio-2.0.so.0 could be avoided if
> "debian/gadmin-proftpd/usr/sbin/gadmin-proftpd" were not uselessly linked
> against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libcairo.so.2 could be avoided if
> "debian/gadmin-proftpd/usr/sbin/gadmin-proftpd" were not uselessly linked
> against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libpango-1.0.so.0 could be avoided if
> "debian/gadmin-proftpd/usr/sbin/gadmin-proftpd" were not uselessly linked
> against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libgmodule-2.0.so.0 could be avoided
> if "debian/gadmin-proftpd/usr/sbin/gadmin-proftpd" were not uselessly linked
> against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libgthread-2.0.so.0 could be avoided
> if "debian/gadmin-proftpd/usr/sbin/gadmin-proftpd" were not uselessly linked
> against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libpangocairo-1.0.so.0 could be
> avoided if "debian/gadmin-proftpd/usr/sbin/gadmin-proftpd" were not uselessly
> linked against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libfreetype.so.6 could be avoided if
> "debian/gadmin-proftpd/usr/sbin/gadmin-proftpd" were not uselessly linked
> against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libpangoft2-1.0.so.0 could be avoided
> if "debian/gadmin-proftpd/usr/sbin/gadmin-proftpd" were not uselessly linked
> against it (they use none of its symbols).
>
> which I guess should be solved if possible with subsequent uploads.
>
I'm confused with this message, i think that was because B-D to
lib-gtk2-dev. but i'm not sure about it
>
>> The package can be found on mentors.debian.net:
>> - URL: http://mentors.debian.net/debian/pool/main/g/gadmin-proftpd
>> - Source repository: deb-src http://mentors.debian.net/debian unstable main
>> contrib non-free
>> - dget
>> http://mentors.debian.net/debian/pool/main/g/gadmin-proftpd/gadmin-proftpd_0.4.2-1.dsc
>>
>> I would be glad if someone uploaded this package for me.
>
> built, signed, uploaded.
>
> Thanks for your work.
>
Thank very much Kilian!
--
[ Mahyuddin Susanto ]
signature.asc
Description: OpenPGP digital signature
Re: Compiling Qt translation files
Thanks, I'll change it in the next version. - Dmitry Shachnev -- 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/BANLkTi=t=hzhuzjcpi5um7h35z90me7...@mail.gmail.com
Re: Compiling Qt translation files
Dmitry, On Wed, 2011-06-29 at 11:32 +0400, Dmitry Shachnev wrote: > I just got my `retext' package accepted. > > Currently the orig tarball includes compiled binary arch-independent > .qm files (but I can easily change this, since I'm the upstream author > too). > Will it be better if I provide .ts text-format source for translations > and compile them during build? This will add a big build-dependency on > Qt. to me source files is always the preferred method to go. If that adds build-deps no problem with me. OTOH there is nothing wrong with binary files that come with a proper license/copyright and can be recreated by available tools with a documented procedure. So if you want my recommendation: go for the larger build-deps and text files for your orig.tar.gz. That's always easier to review just in case. -- Best regards, Kilian signature.asc Description: This is a digitally signed message part
Compiling Qt translation files
Hello! I just got my `retext' package accepted. Currently the orig tarball includes compiled binary arch-independent .qm files (but I can easily change this, since I'm the upstream author too). Will it be better if I provide .ts text-format source for translations and compile them during build? This will add a big build-dependency on Qt. - Dmitry Shachnev (http://qa.debian.org/developer.php?login=mitya57%40gmail.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/BANLkTi=q=ou9zphrseomyw4rydnyx3v...@mail.gmail.com
Re: RFS: odvr
Hi Guillermo, On Tue, 2011-06-28 at 12:32 -0430, Guillermo Lengemann wrote: > Dear mentors, > > I am looking for a sponsor for my package "odvr". > > * Package name: odvr > Version : 0.1.5-1 > Upstream Author : Tristan Willy > * URL : http://code.google.com/p/odvr/ > * License : GNU GPL v3 > Section : sound > > It builds these binary packages: > odvr - Support sound recorder Olympus VN models > > The package appears to be lintian clean. > > The upload would fix these bugs: 513271 > > My motivation for maintaining this package is: use the application and i > want learn package for Debian GNU/Linux. > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/o/odvr > - Source repository: deb-src http://mentors.debian.net/debian unstable > main contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/o/odvr/odvr_0.1.5-1.dsc > > I would be glad if someone uploaded this package for me. Thank you for your work. Here are my comments: 1. Your debian/changelog has a badly formatted line above your signature. Shows up highligted in vim syntax for example. 2. debian/compat is still at 7. Please use 8 3. Standards-Version is still at 3.9.1. Should be easy enough to bump that to 3.9.2 which is current. 4. debian/odvr128x128.png copyright? Yours? Gimped that picture yourself? If so, that'd be ok. If not, please mention. Eventually you can talk upstream into including something directly though. 5. debian/patches/debian-changes-0.1.5-1 still contains template lines. Please remove them and add when/where it was forwarded upstream. - install -D -o root -g root -m 755 odvr $(DESTDIR)/usr/bin + install -o root -g root -m 755 odvr $(DESTDIR)/usr/bin I don't understand though. Why would you want to drop the -D here? Changing your patch name into something more meaningful like "destdir.patch" will get rid of this warning: W: odvr source: format-3.0-but-debian-changes-patch ...which seems you've already done in debian/patches/install-makefile.patch. So why is debian/patches/debian-changes-0.1.5-1 needed anyway? And why do you alter the "release" target when you don't use it? And why do you patch out the "Ubuntu" when you could just extend that line to include Debian. Obviously upstream would like the file in /etc/udev/rules.d whereas you now ship it in /lib/udev/rules.d. This is somewhat asking for problems communicating back and forth without any obvious benefit I could see. And just for the record: debian/patches/fix-ico-desktop-create.patch and debian/patches/fix-image-ico-create.patch are empty and not used anyway 6. debian/rules is still old-style. Please try to update to debhelper version 7 style - it'll clean your rules significantly. 7. You add DESTDIR support in your patch. Yet your debian/rules does use: $(MAKE) prefix=`pwd`/debian/`dh_listpackages` install Why? 8. Unused dh_ lines in debian/rules can be deleted even in old-style 9. unused lines in debian/watch should be deleted as well. Apart from that your debian/watch doesn't work. Running uscan gives: -- In debian/watch, processing watchfile line: http://code.google.com/p/odvr/ odvr-(.*)\.tar\.gz uscan warning: In debian/watch, no matching hrefs for watch line http://code.google.com/p/odvr/ odvr-(.*)\.tar\.gz -- Scan finished 10. If you can convince upstream to look into the useless linking of libs that'd be great. Though I know it's painful. ;-) See the lines like: dpkg-shlibdeps: warning: dependency on libpangoft2-1.0.so.0 could be avoided if "debian/odvr/usr/bin/odvr-gui" were not uselessly linked against it (they use none of its symbols). in the build output. 11. Your source ships a binary blob: P: odvr source: source-contains-prebuilt-binary odvr.x86 12. Your copyright is not DEP-5 format. Please insert the missing lines. 13. Your manpages seem to be not entirely clean: I: odvr: hyphen-used-as-minus-sign usr/share/man/man1/odvr-gui.1.gz:27 I: odvr: hyphen-used-as-minus-sign usr/share/man/man1/odvr-gui.1.gz:28 I: odvr: hyphen-used-as-minus-sign usr/share/man/man1/odvr.1.gz:81 I: odvr: hyphen-used-as-minus-sign usr/share/man/man1/odvr.1.gz:82 Overall not bad for a first try. I guess the above should be easy to fix. And then the upload should be piece of cake once this is addressed. -- Cheers, Kilian signature.asc Description: This is a digitally signed message part
Re: Bug#625120: clonalframe: FTBFS: src/move_hidden.cpp:169:62: error: taking address of temporary [-fpermissive]
Hi, sorry for the late reply to this bug. I can reproduce the problem on my side but I'm not finally sure that this is really a problem of clonalframe or whether it is a bad coincidence with libgsl0-dev. The line in question where the problem occures is: src/move_hidden.cpp:423:59: error: taking address of temporary [-fpermissive] 423:Util::normalize(&(gsl_matrix_row(e,i+1).vector)); So I suspect that there are temporary variables used where they should not but these are not declared in Move_hidden::makee(). My c++ knowledge ist too limited to track down the problem in a reasonable time frame and thus I CC debian-mentors and upstream (Xavier please find the full log of this bug below or at http://bugs.debian.org/625120). Any help is welcome Andreas. On Mon, May 02, 2011 at 02:30:18PM +0200, Lucas Nussbaum wrote: > Source: clonalframe > Version: 1.2-1 > Severity: serious > Tags: wheezy sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20110502 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Relevant part: > > g++ -c -pipe -W -Wall -O3 -static -DHAVE_INLINE -DGSL_RANGE_CHECK_OFF -Isrc > > -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB > > -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. > > -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 > > -Ibuild -o build/move_hidden.o src/move_hidden.cpp > > src/move_hidden.cpp:25:5: warning: unused parameter 'p' [-Wunused-parameter] > > src/move_hidden.cpp: In member function 'void > > wb::Move_hidden::forwardfast(wb::Param*, wb::Tree*)': > > src/move_hidden.cpp:127:33: warning: comparison between signed and unsigned > > integer expressions [-Wsign-compare] > > src/move_hidden.cpp:133:41: warning: comparison between signed and unsigned > > integer expressions [-Wsign-compare] > > src/move_hidden.cpp:137:45: warning: comparison between signed and unsigned > > integer expressions [-Wsign-compare] > > src/move_hidden.cpp:132:21: warning: unused variable 'top' > > [-Wunused-variable] > > src/move_hidden.cpp:132:27: warning: unused variable 'left' > > [-Wunused-variable] > > src/move_hidden.cpp:132:34: warning: unused variable 'right' > > [-Wunused-variable] > > src/move_hidden.cpp: In member function 'gsl_matrix* > > wb::Move_hidden::forward(wb::Param*)': > > src/move_hidden.cpp:169:62: error: taking address of temporary > > [-fpermissive] > > src/move_hidden.cpp: In member function 'void > > wb::Move_hidden::backward(wb::Param*, gsl_matrix*, wb::Tree*)': > > src/move_hidden.cpp:202:17: warning: unused variable 'd' [-Wunused-variable] > > src/move_hidden.cpp: In member function 'void > > wb::Move_hidden::makee(wb::Param*, wb::Tree*)': > > src/move_hidden.cpp:423:59: error: taking address of temporary > > [-fpermissive] > > make[2]: *** [build/move_hidden.o] Error 1 > > The full build log is available from: > > http://people.debian.org/~lucas/logs/2011/05/02/clonalframe_1.2-1_lsid64.buildlog > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > About the archive rebuild: The rebuild was done on about 50 AMD64 nodes > of the Grid'5000 platform, using a clean chroot. Internet was not > accessible from the build systems. > > -- > | Lucas Nussbaum > | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | > | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | > > > > ___ > Debian-med-packaging mailing list > debian-med-packag...@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/debian-med-packaging > -- http://fam-tille.de -- 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/20110629071744.gb31...@an3as.eu
Re: RFS: s3ql (new python application)
Nikolaus, On Tue, 2011-06-28 at 14:56 -0400, Nikolaus Rath wrote: > dget http://mentors.debian.net/debian/pool/main/s/s3ql/s3ql_1.0.1-1.dsc thanks for the update. 1. Regarding the example scrips you ship I'm sort of undecided whether they would actually fit better in examples rather than "contrib". I guess yes. usr/share/doc/s3ql/contrib/benchmark.py usr/share/doc/s3ql/contrib/expire_backups.py usr/share/doc/s3ql/contrib/make_dummy.py usr/share/doc/s3ql/contrib/pcp.py usr/share/doc/s3ql/contrib/s3ql_backup.sh 2. You symlink your contrib scripts from /usr/share/doc (!) into /usr/bin which is not really the best solution out there. Please decide whether these shall either go as examples (and not symlinked to /usr/bin/) or whether they are official applications - in which case they don't belong into /usr/share/doc. Anyway, built, signed, uploaded. As we'll be landing in NEW anyway, please prepare any new upload with 1.0.1-2 version fixing these bugs. We don't even need to wait until we'll be accepted from NEW into main to push this into incoming. Thanks! -- Cheers, Kilian signature.asc Description: This is a digitally signed message part
