Re: RFS: kst (updated package)
Ruben, On Tue, 2011-06-28 at 19:55 -0500, Ruben Molina wrote: El mar, 28-06-2011 a las 16:12 +0200, David Kalnischkies escribió: On Tue, Jun 28, 2011 at 15:54, Ruben Molina rmol...@udea.edu.co wrote: Thanks for your help! Looks like it was wrong to assume a common set of symbols for all the arches. May I ask you to remove debian/*.symbols, and try to build the package again? Set in your debian/rules this instead of removal: export DPKG_GENSYMBOLS_CHECK_LEVEL=0 It will cause dpkg-gensymbols to proceed regardless of the symbol-outcome Thanks David, I re-uploaded the package following your advise. - dget http://mentors.debian.net/debian/pool/main/k/kst/kst_2.0.3-1.dsc thanks. Comments are: 1. Still uses debhelper 7. Could/should be 8. 2. Your symbols obviously contain the debian version for libkst2math2, libkst2core2, libkst2widgets2 You may want to try pkg-kde-tools using (http://pkg-kde.alioth.debian.org/symbolfiles.html) in case your libs are C++ to lessen the pain a bit. 3. You're not building a lib*-dbg package to help with debugging including symbols. Would be nice to have one. 4. Just to make sure you've checked. There is a kst binary in stable. Have you tested the upgrade path if this version enters testing and thus will become the next stable version? The wnpp bug report reads that KST1 and KST2 are not fully feature-compatible. 5. You've shortened the description compared to the 1.7 version. This may be a good thing, yet you've dropped entirely the remark that this is a KDE app. Is it now GNOME/KDE/XFCE/... i.e. freedesktop.org compatible? Anyhow. Build, signed, uploaded. Thanks for stepping up as new maintainer. -- Best regards, Kilian signature.asc Description: This is a digitally signed message part
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
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: 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 tristan.wi...@gmail.com * 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
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: 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
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: 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
On 2011-06-29, Dmitry Shachnev mity...@gmail.com 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
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: 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
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: 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: 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
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: 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: 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 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
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
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 sebh...@xwmw.org * 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: 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
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: 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: 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: 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: 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: #) is the bug number of your ITP 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: 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: 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: phing (another try)
Hi, thanks I will fix that soon. Regards, Nicolas 2011/6/29 Elías Alejandro eal...@gmail.com 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)
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: 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: 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: 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: 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
Hello, On Wed, 29 Jun 2011 16:11:56 -0500 Elías Alejandro eal...@gmail.com 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: tnat64 -- IPv4 to NAT64 redirector
* Andrew O. Shadoura bugzi...@tut.by, 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: 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: 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
