Documentation generated by doxygen and Debian Policy
Hi list, I found that in package qxmpp is used HTML documentation from upstream tarball. This documentation was not generated by doxygen during build process. Should I make a bug report? If yes, which section of Debian Policy I should point to? Best regards, Boris -- 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/175731334821...@web6g.yandex.ru
Bug#661507: RFS: libblocxx/2.1.0-1 [ITP] BloCXX--C++ Framework for Application Development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 *** UPDATE *** New version from svn trunk (544~svn). Documentation (html + LaTeX) is now included in build-process. * Package name: libblocxx Version : 544~svn-1 It builds those binary packages: libblocxx-dbg - BloCxx debugging symbols libblocxx-dev - BloCxx development libraries and header files libblocxx-doc - BloCxx documentation and examples libblocxx8 - BloCxx - C++ Framework for Application Development To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libblocxx Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libb/libblocxx/libblocxx_544~svn-1.dsc More information about libblocxx can be obtained from http://blocxx.sf.net Changes since the last upload: * Initial release (Closes: #647639) * include documentation in build * add patch: use default automake * add patch: change BloCxx version to 544svn * add patch: fix path to dot in Doxyfile.in * add patch: exclude testsuite from documentation * add patch: don't build autogenerated manpages Regards, Björn Esser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+Py4IACgkQ3u1SIc8s7PXg7gD/QU/1i8AEj9btf4Bhi+tLWCmg 8qldyF3VL5OHe8mei10BANTyI5cIb5B0BlOREpK4kXab8VDmDN77i2Ji3SBuKTBI =VJFa -END PGP SIGNATURE- -- 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/4f8fcb83.6090...@googlemail.com
RFS: libblocxx/544~svn-1 (2nd try + updated pkg)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Severity: wishlish *** UPDATE *** New version from svn trunk (544~svn replaces 2.1.0). Documentation (html + LaTeX) is now included in build-process. Dear mentors, I am looking for a sponsor for my package "libblocxx". Have a look at it, please. * Package name: libblocxx Version : 544~svn-1 Upstream Author : (C) 2000-2009 Quest Software, Inc. (C) 2005-2006 Novell, Inc. All rights reserved. (C) 2000-2006 Vintela, Inc. All rights reserved. * URL : http://blocxx.sf.net/ * License : BSD-3 Section : libs It builds those binary packages: libblocxx-dbg - BloCxx debugging symbols libblocxx-dev - BloCxx development libraries and header files libblocxx-doc - BloCxx documentation and examples libblocxx8 - BloCxx - C++ Framework for Application Development To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libblocxx Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libb/libblocxx/libblocxx_544~svn-1.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: * Initial release (Closes: #647639) * include documentation in build * add patch: use default automake * add patch: change BloCxx version to 544svn * add patch: fix path to dot in Doxyfile.in * add patch: exclude testsuite from documentation * add patch: don't build autogenerated manpages Regards, Björn Esser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+PzTQACgkQ3u1SIc8s7PVE4AD+JEwQju+J7KxS4CGPAOixll1S zkprTxuNAqF4JxqYPFMA/1/cksuOHHDNwz6wOjPw4SIV8xr+joH2MVUHVZuczt7n =mY8V -END PGP SIGNATURE- -- 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/4f8fcd34.5040...@googlemail.com
Re: RFS: libblocxx/544~svn-1 (2nd try + updated pkg)
19.04.2012 12:30, Björn Esser пишет: > Severity: wishlish > > *** UPDATE *** > New version from svn trunk (544~svn replaces 2.1.0). > Documentation (html + LaTeX) is now included in build-process. > > Dear mentors, > > I am looking for a sponsor for my package "libblocxx". > Have a look at it, please. > > * Package name: libblocxx >Version : 544~svn-1 >Upstream Author : (C) 2000-2009 Quest Software, Inc. > (C) 2005-2006 Novell, Inc. All rights reserved. > (C) 2000-2006 Vintela, Inc. All rights reserved. > * URL : http://blocxx.sf.net/ > * License : BSD-3 >Section : libs > > It builds those binary packages: > > libblocxx-dbg - BloCxx debugging symbols > libblocxx-dev - BloCxx development libraries and header files > libblocxx-doc - BloCxx documentation and examples > libblocxx8 - BloCxx - C++ Framework for Application Development > > To access further information about this package, please visit the > following URL: > > http://mentors.debian.net/package/libblocxx > > > Alternatively, one can download the package with dget using this > command: > > dget -x > http://mentors.debian.net/debian/pool/main/libb/libblocxx/libblocxx_544~svn-1.dsc > > More information about hello can be obtained from > http://www.example.com. > > Changes since the last upload: > > * Initial release (Closes: #647639) > * include documentation in build > * add patch: use default automake > * add patch: change BloCxx version to 544svn > * add patch: fix path to dot in Doxyfile.in > * add patch: exclude testsuite from documentation > * add patch: don't build autogenerated manpages > > Regards, >Björn Esser > > I'm not intended to support this package :-), but here are some issues I see: 1. Version in configure.in is 2.3.0, so debian package it should be 2.3.0~svn544 or 2.2.0+svn544 (make sure if 2.3 is ongoing release) 2. hello http://www.example.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/4f8fd122.4080...@gmail.com
Re: RFS: libblocxx/2.3.0~svn544-1 (2nd try + updated pkg) (was: RFS: libblocxx/544~svn-1 (2nd try + updated pkg))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ok, so here we go again correcting the issues: Severity: wishlish *** UPDATE *** New version from svn trunk (2.3.0~svn544 replaces 2.1.0). Documentation (html + LaTeX) is now included in build-process. Dear mentors, I am looking for a sponsor for my package "libblocxx". Have a look at it, please. * Package name: libblocxx Version : 2.3.0~svn544 Upstream Author : (C) 2000-2009 Quest Software, Inc. (C) 2005-2006 Novell, Inc. All rights reserved. (C) 2000-2006 Vintela, Inc. All rights reserved. * URL : http://blocxx.sf.net/ * License : BSD-3 Section : libs It builds those binary packages: libblocxx-dbg - BloCxx debugging symbols libblocxx-dev - BloCxx development libraries and header files libblocxx-doc - BloCxx documentation and examples libblocxx8 - BloCxx - C++ Framework for Application Development To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libblocxx Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libb/libblocxx/libblocxx_2.3.0~svn544-1.dsc More information about BloCxx can be obtained from http://blocxx.sf.net/ Changes since the last upload: * Initial release (Closes: #647639) * include documentation in build * add patch: use default automake * add patch: fix path to dot in Doxyfile.in * add patch: exclude testsuite from documentation * add patch: don't build autogenerated manpages Regards, Björn Esser Am 19.04.2012 10:47, schrieb Igor Pashev: > 19.04.2012 12:30, Björn Esser пишет: >> Severity: wishlish >> >> *** UPDATE *** New version from svn trunk (544~svn replaces >> 2.1.0). Documentation (html + LaTeX) is now included in >> build-process. >> >> Dear mentors, >> >> I am looking for a sponsor for my package "libblocxx". Have a >> look at it, please. >> >> * Package name: libblocxx Version : 544~svn-1 >> Upstream Author : (C) 2000-2009 Quest Software, Inc. (C) >> 2005-2006 Novell, Inc. All rights reserved. (C) 2000-2006 >> Vintela, Inc. All rights reserved. * URL : >> http://blocxx.sf.net/ * License : BSD-3 Section : >> libs >> >> It builds those binary packages: >> >> libblocxx-dbg - BloCxx debugging symbols libblocxx-dev - BloCxx >> development libraries and header files libblocxx-doc - BloCxx >> documentation and examples libblocxx8 - BloCxx - C++ Framework >> for Application Development >> >> To access further information about this package, please visit >> the following URL: >> >> http://mentors.debian.net/package/libblocxx >> >> >> Alternatively, one can download the package with dget using this >> command: >> >> dget -x >> http://mentors.debian.net/debian/pool/main/libb/libblocxx/libblocxx_544~svn-1.dsc >> >> >> More information about hello can be obtained from >> http://www.example.com. >> >> Changes since the last upload: >> >> * Initial release (Closes: #647639) * include documentation in >> build * add patch: use default automake * add patch: change >> BloCxx version to 544svn * add patch: fix path to dot in >> Doxyfile.in * add patch: exclude testsuite from documentation * >> add patch: don't build autogenerated manpages >> >> Regards, Björn Esser >> >> > > I'm not intended to support this package :-), but here are some > issues I see: > > 1. Version in configure.in is 2.3.0, so debian package it should > be 2.3.0~svn544 or 2.2.0+svn544 (make sure if 2.3 is ongoing > release) > > 2. hello http://www.example.com :-) > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+P1+QACgkQ3u1SIc8s7PVE/AEAtxnSdWlvZ8kWiCn/46RxrWUu W7A/74iKYzmuMbAk2NYA/2FTalcIFCUJ29knzW9cHU0aqXI4sLYslLs7Hu30X22W =Xnq2 -END PGP SIGNATURE- -- 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/4f8fd7e4.3060...@googlemail.com
Re: Help writing a watch file for rnahybrid
Hi Paul, On Thu, Apr 19, 2012 at 02:54:42PM +0800, Paul Wise wrote: > On Thu, Apr 19, 2012 at 2:40 PM, Andreas Tille wrote: > > > The first question is: Why does it not find a new version at all: > > uscan relies solely on links and since there are no links to the > tarballs, it cannot find any tarballs. Thanks for the explanation. > > you don't know a reasonable solution I might need to negotiate > > with upstream about a more friendly download option. > > Yes, please cluebat upstream. :-) OK, I'll do so. By chance I ran into another watch file problem: version=3 http://www.bioconductor.org/packages/release/bioc/html/qvalue.html \ ../src/contrib/qvalue_([\d\.]+)\.tar\.gz runs into -- Downloading updated package qvalue_1.30.0.tar.gz uscan warning: In directory ., downloading http://www.bioconductor.org/../src/contrib/qvalue_1.30.0.tar.gz failed: 400 Bad Request Upstream hides their source directory somehow and a wget http://www.bioconductor.org/packages/release/src/contrib/qvalue_1.30.0.tar.gz ends up in 404 (so even if the relative URL would be properly resolved a download might fail). So while we at least can find out the proper new version number it requires manual download. Any idea? 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/20120419093432.gb1...@an3as.eu
Re: RFC: Clonewise - Detecting code reuse and embedded code copies
On Tue, Apr 17, 2012 at 12:35 PM, Silvio Cesare wrote: > The Debian Package clonewise-core (currently in the mentors archive) > http://mentors.debian.net/package/clonewise-core > http://www.foocodechu.com/downloads/clonewise Here is a review of the package: You should file an ITP bug: http://www.debian.org/devel/wnpp/#l1 Which debian.net domain would you like me to register on your behalf and what IP address or domain name should I point it to? clonewise.debian.net? This would be the location for the results of running this over the Debian archive. There are a pair of embedded code copies in the libs/ dir :) snap and glib should be packaged separately. All the .ex files in the debian/ dir should be removed or renamed. Please add a debian/watch file: http://wiki.debian.org/debian/watch debian/README.source and debian/README.Debian look like they can be removed. debian/README looks like it should be renamed to debian/README.Debian debian/docs is empty and can be removed. Please remove or fix and uncomment the commented-out Vcs-* fields in debian/control. The Vcs-* fields should point at the VCS containing the packaging for clonewise-core. libfuzzy2 should not be in Depends, since the shlibs mechanism should automatically add that. Would it be better to link to this page in the Homepage field? http://www.foocodechu.com/?q=clonewise-automatically-identifying-package-clones%20and-inferring-security-vulnerabilities The build process isn't very verbose. You should disable that either upstream or in debian/rules. The upstream code doesn't contain per-file copyright and license info: http://tieguy.org/blog/2012/03/17/on-the-importance-of-per-file-license-information/ Would it be possible to either rename the binaries to not include a capital letter or include symlinks? Lower-case is generally easier to type. You mentioned on IRC that ssdeep needs to be in Depends, please add it. When I run Clonewise-BuildDatabase, I get a lot of this warning, would it be possible to silence that? ssdeep: Did not process files large enough to produce meaningful results. Would it be possible to make Clonewise-BuildDatabase use a local Debian mirror instead of run apt-get source lots of times? When we start running it on the Debian archive it would be best to do it that way. The package is a native package while it should not be one since it might be useful to any Debian derivative. I would also encourage you to structure your upstream development so that the core code is flexible enough to also support other packaging systems, like those of Fedora, Gentoo etc and provide package-format-specific parts to do the right thing on each package format type. Your upstream build system does not support setting the install prefix and hardcodes /usr instead of /usr/local. People installing from source will get non-packaged files in /usr. Some configuration or command-line options would be useful so that the database can be located at any path and the Clonewise-BuildDatabase script does not need to be run as root. Any particular reason to use -O3? I imagine the performance of clonewise would mostly be limited by IO and by the speed of ssdeep and that the compiler optimisation level would make no difference. In general it is better to use -O2. Since you are upstream, please take a look at our upstream guide and the links in the External advice section: http://wiki.debian.org/UpstreamGuide lintian complaints: W: clonewise-core source: dh-make-template-in-source debian/clonewise-core.cron.d.ex W: clonewise-core source: dh-make-template-in-source debian/clonewise-core.default.ex W: clonewise-core source: dh-make-template-in-source debian/clonewise-core.doc-base.EX W: clonewise-core source: dh-make-template-in-source debian/emacsen-install.ex W: clonewise-core source: dh-make-template-in-source debian/emacsen-remove.ex W: clonewise-core source: dh-make-template-in-source debian/emacsen-startup.ex W: clonewise-core source: dh-make-template-in-source debian/init.d.ex W: clonewise-core source: dh-make-template-in-source debian/manpage.1.ex W: clonewise-core source: dh-make-template-in-source debian/manpage.sgml.ex W: clonewise-core source: dh-make-template-in-source debian/manpage.xml.ex W: clonewise-core source: dh-make-template-in-source debian/menu.ex W: clonewise-core source: dh-make-template-in-source debian/postinst.ex W: clonewise-core source: dh-make-template-in-source debian/postrm.ex W: clonewise-core source: dh-make-template-in-source debian/preinst.ex W: clonewise-core source: dh-make-template-in-source debian/prerm.ex W: clonewise-core source: dh-make-template-in-source debian/watch.ex P: clonewise-core source: unversioned-copyright-format-uri http://dep.debian.net/deps/dep5 W: clonewise-core source: missing-license-text-in-dep5-copyright gpl-3.0+ (paragrah at line 5) W: clonewise-core source: out-of-date-standards-version 3.9.2 (current is 3.9.3) I: clonewise-core: spelling-error-in-binary usr/bin/Clonewise
Re: Help writing a watch file for rnahybrid
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Try something like: version=3 http://www.bioconductor.org/packages/release/bioc/src/contrib/qvalue_([\d\.]+)\.tar\.gz `wget http://www.bioconductor.org/packages/release/bioc/src/contrib/qvalue_1.30.0.tar.gz` works fine for me. Cheers, Björn Esser Am 19.04.2012 11:34, schrieb Andreas Tille: > Hi Paul, > > On Thu, Apr 19, 2012 at 02:54:42PM +0800, Paul Wise wrote: >> On Thu, Apr 19, 2012 at 2:40 PM, Andreas Tille wrote: >> >>> The first question is: Why does it not find a new version at >>> all: >> >> uscan relies solely on links and since there are no links to the >> tarballs, it cannot find any tarballs. > > Thanks for the explanation. > >>> you don't know a reasonable solution I might need to negotiate >>> with upstream about a more friendly download option. >> >> Yes, please cluebat upstream. > > :-) OK, I'll do so. > > > By chance I ran into another watch file problem: > > version=3 > http://www.bioconductor.org/packages/release/bioc/html/qvalue.html > \ ../src/contrib/qvalue_([\d\.]+)\.tar\.gz > > > runs into > > -- Downloading updated package qvalue_1.30.0.tar.gz uscan warning: > In directory ., downloading > http://www.bioconductor.org/../src/contrib/qvalue_1.30.0.tar.gz > failed: 400 Bad Request > > Upstream hides their source directory somehow and a > > wget > http://www.bioconductor.org/packages/release/src/contrib/qvalue_1.30.0.tar.gz > > ends up in 404 (so even if the relative URL would be properly > resolved a download might fail). So while we at least can find out > the proper new version number it requires manual download. Any > idea? > > Kind regards > > Andreas. > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+P4HoACgkQ3u1SIc8s7PXg0gD7BpYzLGbGq7FaiiLzOoosweUR UAT0PCbPMt9LvueS/zgA/iXwuJYCK8T5x9oWjBN4dbRM2Ap2N+BFaY7DLCK8nZb/ =dUbI -END PGP SIGNATURE- -- 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/4f8fe07a.2020...@googlemail.com
Re: RFC: Clonewise - Detecting code reuse and embedded code copies
This is interesting. is this related to http://www.fossology.org/projects/fossology fosology in any way? mike On Tue, Apr 17, 2012 at 6:35 AM, Silvio Cesare wrote: > The Debian Package clonewise-core (currently in the mentors archive) > http://mentors.debian.net/package/clonewise-core > http://www.foocodechu.com/downloads/clonewise > -- > > Clonewise is a tool for detecting code reuse in Debian packages. This is > also > known as detecting embedded code copies. Debian maintains a database of > packages that embed code in the security tracker. Clonewise is a tool to > automate and supplement the manual tracking of packages. > > The primary use of it is for the security team who may identify a > vulnerability > in a library and want to know if that library is reused and embedded in any > other Debian packages. > > -- QUICK GUIDE > > You might want to install the Clonewise database instead of generating it > (which can take several days when you first run Clonewise). > > Download it from http://www.foocodechu.com/downloads/clonewise/ > > Example usage to discover if the source package libpng is reused in other > Debian packages is as follows: > > $ Clonewise -vv libpng > libpng CLONED_IN_SOURCE afterstep (18.457640) >MATCH png.c (5.605583) (33.00) >MATCH pngtrans.c (6.409078) (57.00) >MATCH pngwtran.c (6.442979) (80.00) >libpng CLONED_IN_PACKAGE libafterimage-dev >libpng CLONED_IN_PACKAGE afterstep >libpng CLONED_IN_PACKAGE afterstep-data >libpng CLONED_IN_PACKAGE libafterimage0 >libpng CLONED_IN_PACKAGE afterstep-dbg >libpng CLONED_IN_PACKAGE libafterstep1 > libpng CLONED_IN_SOURCE fltk1.1 (44.336105) >MATCH png.c (5.605583) (58.00) >MATCH pngerror.c (6.442979) (57.00) >MATCH pngmem.c (6.442979) (85.00) >MATCH pngpread.c (6.514438) (52.00) >MATCH pngrio.c (6.478071) (77.00) >MATCH pngtrans.c (6.409078) (63.00) >MATCH pngwtran.c (6.442979) (80.00) >libpng CLONED_IN_PACKAGE fltk1.1-doc >libpng CLONED_IN_PACKAGE fltk1.1-games >libpng CLONED_IN_PACKAGE libfltk1.1 >libpng CLONED_IN_PACKAGE libfltk1.1-dbg >libpng CLONED_IN_PACKAGE libfltk1.1-dev > [ snip ] > > So libpng is embedded in the source packages afterstep and fltk1.1. > Looking at my version of the embedded-code-copies file on the security > tracker, I can see that fltk1.1 is actually referenced as libfltk1.1 and > has > been fixed a while ago. The security tracker is meant to report the source > package name, so this should probably be fixed. Clonewise otherwise > ignores embedded code copies that have been fixed (according to the > security tracker). I can't see afterstep in the tracker, so again, we might > need to make an update. We don't know if afterstep has been patched > to use a system library so we need to investigate more - like seeing > if libpng is a dependency of the afterstep package. In real usage, if > libpng > is buggy, it's probably important to do this and check the afterstep > package > to see if is vulnerable to a libpng bug. > > The matching files have a weight and a score that represents the > significance > of the file in the repository and and the similarity of the file between > the > two packages. > > CLONED_IN_SOURCE are the source packages. > CLONED_PACKAGE are the binary packages built from the source package. > > -- BUILDING THE DATABASE > > If you don't install clonewise-database, then the database of the package > repository will probably need to be built the first time you run Clonewise. > You will need to be the superuser to do this and in all likelihood it will > take several days to complete. > > Clonewise will run Clonewise-BuildDatabase when the database has not been > built. It will download the entire Debian source repository, unpack the > packages and generate signatures for each package. > > -- CONFIGURATION FILES > > There are a number of configuration files in Clonewise. > > /var/lib/Clonewise/extensions - contains a list of filename extensions that > are used to identify source code. Clonewise ignores all reuse of non > program > code in package contents and this is how it knows this. > > /var/lib/Clonewise/threshold - is the default threshold of the amount of > code > reuse that needs to occur before Clonewise reports it. If you get too many > false positives, then increase this number. You can also override this > threshold on the command line with Clonewise -C . > > /var/lib/Clonewise/ignore-these-fixed - is a list of package pairs from > the embedded-code-copies file maintained in the Debian security tracker > where > it has been reported that the packages in question have been modified so > system wide libraries are being used and there is no embedded code in the > build. > > /var/lib/Clonewise/ignore-these-false-positi
Bug#661507: RFS: libblocxx/2.1.0-1 [ITP] BloCXX--C++ Framework for Application Development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ok, so here we go again correcting some issues: *** UPDATE *** New version from svn trunk (2.3.0~svn544 replaces 2.1.0). Documentation (html + LaTeX) is now included in build-process. Dear mentors, I am looking for a sponsor for my package "libblocxx". Have a look at it, please. * Package name: libblocxx Version : 2.3.0~svn544 Upstream Author : (C) 2000-2009 Quest Software, Inc. (C) 2005-2006 Novell, Inc. All rights reserved. (C) 2000-2006 Vintela, Inc. All rights reserved. * URL : http://blocxx.sf.net/ * License : BSD-3 Section : libs It builds those binary packages: libblocxx-dbg - BloCxx debugging symbols libblocxx-dev - BloCxx development libraries and header files libblocxx-doc - BloCxx documentation and examples libblocxx8 - BloCxx - C++ Framework for Application Development To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libblocxx Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libb/libblocxx/libblocxx_2.3.0~svn544-1.dsc More information about BloCxx can be obtained from http://blocxx.sf.net/ Changes since the last upload: * Initial release (Closes: #647639) * include documentation in build * add patch: use default automake * add patch: fix path to dot in Doxyfile.in * add patch: exclude testsuite from documentation * add patch: don't build autogenerated manpages Regards, Björn Esser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+P2P4ACgkQ3u1SIc8s7PXRlAD/YSseels8iw6jSwkycEYf//Tk ccqTD2vne479a+5b3ZwA/0WQcjJFDfrUnU6v+nutjz3Kdj24YbDDOl+a3npPzubO =pI2V -END PGP SIGNATURE- -- 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/4f8fd8fe.6050...@googlemail.com
Bug#669016: RFS: gyoto/0.0.1-1 [ITP] -- general relativistic ray-tracing and orbit computation
Hi,
I've updated the package which now installs the headers in a
subdirectory of /usr/include:
http://mentors.debian.net/package/gyoto
http://mentors.debian.net/debian/pool/main/g/gyoto/gyoto_0.0.2-1.dsc
Regards, Thibaut.
Le 16/04/12 17:10, Thibaut Paumard a écrit :
> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
> I am looking for a sponsor for my package "gyoto"
>
> * Package name: gyoto
>Version : 0.0.1-1
>Upstream Author : Frédéric Vincent & myself
> * URL : http://gyoto.obspm.fr
> * License : GPL-3+
>Section : science
>
> Gyoto aims at providing a framework for computing orbits and ray-traced images
> in General relativity. It consists in a shared library (libgyoto0), utility
> programs (in the gyoto package), and a plug-in for the Yorick programing
> language (in yorick-gyoto). Gyoto can be extended with plug-ins (see
> libgyoto0-dev).
>
> The source package builds those binary packages:
> gyoto - General relativistic ray-tracing
> gyoto-dbg - debugging symbols for gyoto, libgyoto0 and yorick-gyoto
> gyoto-doc - documentation for the Gyoto library
> libgyoto0 - General relativistic geodesic integration and ray-tracing
> libgyoto0-dev - development files for libgyoto
> yorick-gyoto - General relativistic geodesic integration for the Yorick
> language
>
> To access further information about this package, please visit the following
> URL:
> http://mentors.debian.net/package/gyoto
>
> Alternatively, one can download the package with dget using this command:
> dget -x http://mentors.debian.net/debian/pool/main/g/gyoto/gyoto_0.0.1-1.dsc
>
> Once installed, the packages can be tested as follows (a test suite is already
> ran during build):
> - gyoto package:
> Compute the example sceneries with
> for file in /usr/share/doc/gyoto/examples/example-*.xml; do gyoto ${file}
> `basename ${file%xml}fits`; done
> The two *rotstar* example file won't run, they depend on the option al plug-
> in lorene which is not compiled. The other files should produce FITS image
> files which you can visualize using e.g. spydr from the yorick-spydr package
> or
> simply with the gimp :
> spydr *.fits
>
> - yorick-gyoto package:
> You can first run gyotoy:
> gyotoy
> You should see a plot representing the orbit of a star around a black hole.
> You
> can play with the
> projection, the initial parameters etc.
>
> Then you can run the test suite:
> ln -s /usr/share/doc/gyoto/ doc
> cp -R /usr/share/doc/yorick-gyoto/examples ./
> cd examples
> gunzip *.gz
> yorick -batch check.i
>
> Best regards, Thibaut.
>
>
>
> -- System Information:
> Debian Release: wheezy/sid
> APT prefers unstable
> APT policy: (500, 'unstable')
> Architecture: i386 (i686)
>
> Kernel: Linux 3.2.0-2-686-pae (SMP w/1 CPU core)
>
>
>
--
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/4f8fdc69.2020...@free.fr
Bug#669209: RFS: yp-svipc/0.13-1 [ITP] -- System V InterProcess Communication for Python/Yorick
Eeek, I replied to the wrong bug. For the record, my review is here: http://lists.debian.org/debian-python/2012/04/msg00078.html -- 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/20120419091146.ga4...@jwilk.net
Processed (with 1 errors): Bug#661507: RFS: libblocxx/2.3.0~svn544-1 [ITP] BloCXX--C++ Framework for Application Development
Processing commands for cont...@bugs.debian.org: > retitle 661507 RFS: libblocxx/2.3.0~svn544-1 [ITP] BloCXX--C++ Bug #661507 [sponsorship-requests] RFS: libblocxx/2.1.0-1 [ITP] -- BloCXX--C++ Framework for Application Development Changed Bug title to 'RFS: libblocxx/2.3.0~svn544-1 [ITP] BloCXX--C++' from 'RFS: libblocxx/2.1.0-1 [ITP] -- BloCXX--C++ Framework for Application Development' > Framework for Application Development Unknown command or malformed arguments to command. > End of message, stopping processing here. Please contact me if you need assistance. -- 661507: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661507 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.133482744429783.transcr...@bugs.debian.org
Processed (with 1 errors): Bug#661507: RFS: libblocxx/2.3.0~svn544-1 [ITP] BloCXX--C++ Framework for Application Development
Processing commands for cont...@bugs.debian.org: > retitle 661507 RFS: libblocxx/2.3.0~svn544-1 [ITP] BloCXX--C++ Framework Bug #661507 [sponsorship-requests] RFS: libblocxx/2.3.0~svn544-1 [ITP] BloCXX--C++ Changed Bug title to 'RFS: libblocxx/2.3.0~svn544-1 [ITP] BloCXX--C++ Framework' from 'RFS: libblocxx/2.3.0~svn544-1 [ITP] BloCXX--C++' > for Application Development Unknown command or malformed arguments to command. > End of message, stopping processing here. Please contact me if you need assistance. -- 661507: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661507 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.133482952210288.transcr...@bugs.debian.org
Re: RFC: Clonewise - Detecting code reuse and embedded code copies
On Thu, Apr 19, 2012 at 5:53 PM, Mike Dupont wrote: > This is interesting. is this related > to http://www.fossology.org/projects/fossology fosology in any way? Unrelated. IIRC Fossology is mainly about looking at copyright and license information. Clonewise is for automatically detecting embedded code copies. Our current methods for finding embedded code copies are all manual: http://wiki.debian.org/EmbeddedCodeCopies -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6eqwmx7kfj51hvsu_hhj+7yiy9s2huzjqwd_ap7bbm...@mail.gmail.com
Processed (with 1 errors): Bug#661507: RFS: libblocxx/2.3.0~svn544 [ITP] BloCXX - C++ Framework for Application Development
Processing commands for cont...@bugs.debian.org: > retitle 661507 RFS: libblocxx/2.3.0~svn544 [ITP] BloCxx - C++ Bug #661507 [sponsorship-requests] RFS: libblocxx/2.3.0~svn544-1 [ITP] BloCXX--C++ Framework Changed Bug title to 'RFS: libblocxx/2.3.0~svn544 [ITP] BloCxx - C++' from 'RFS: libblocxx/2.3.0~svn544-1 [ITP] BloCXX--C++ Framework' > Framework for Application Development Unknown command or malformed arguments to command. > End of message, stopping processing here. Please contact me if you need assistance. -- 661507: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661507 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.133482993712828.transcr...@bugs.debian.org
Processed (with 1 errors): Bug#661507: RFS: libblocxx/2.3.0~svn544 [ITP] BloCXX - C++ Framework for Application Development
Processing commands for cont...@bugs.debian.org: > retitle 661507 RFS: libblocxx/2.3.0~svn544 [ITP] BloCxx - C++ Framework for Bug #661507 [sponsorship-requests] RFS: libblocxx/2.3.0~svn544 [ITP] BloCxx - C++ Changed Bug title to 'RFS: libblocxx/2.3.0~svn544 [ITP] BloCxx - C++ Framework for' from 'RFS: libblocxx/2.3.0~svn544 [ITP] BloCxx - C++' > Application Development Unknown command or malformed arguments to command. > End of message, stopping processing here. Please contact me if you need assistance. -- 661507: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661507 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.133483124222058.transcr...@bugs.debian.org
Re: RFS: libblocxx/2.3.0~svn544-1 (2nd try + updated pkg)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The fixed and rebuild package has correctly uploaded to mentors now. Am 19.04.2012 11:16, schrieb Björn Esser: > Ok, so here we go again correcting the issues: > > Severity: wishlish > > *** UPDATE *** New version from svn trunk (2.3.0~svn544 replaces > 2.1.0). Documentation (html + LaTeX) is now included in > build-process. > > Dear mentors, > > I am looking for a sponsor for my package "libblocxx". Have a look > at it, please. > > * Package name: libblocxx Version : 2.3.0~svn544 > Upstream Author : (C) 2000-2009 Quest Software, Inc. (C) 2005-2006 > Novell, Inc. All rights reserved. (C) 2000-2006 Vintela, Inc. All > rights reserved. * URL : http://blocxx.sf.net/ * > License : BSD-3 Section : libs > > It builds those binary packages: > > libblocxx-dbg - BloCxx debugging symbols libblocxx-dev - BloCxx > development libraries and header files libblocxx-doc - BloCxx > documentation and examples libblocxx8 - BloCxx - C++ Framework for > Application Development > > To access further information about this package, please visit the > following URL: > > http://mentors.debian.net/package/libblocxx > > > Alternatively, one can download the package with dget using this > command: > > dget -x > http://mentors.debian.net/debian/pool/main/libb/libblocxx/libblocxx_2.3.0~svn544-1.dsc > > More information about BloCxx can be obtained from > http://blocxx.sf.net/ > > Changes since the last upload: > > * Initial release (Closes: #647639) * include documentation in > build * add patch: use default automake * add patch: fix path to > dot in Doxyfile.in * add patch: exclude testsuite from > documentation * add patch: don't build autogenerated manpages > > Regards, Björn Esser > > > Am 19.04.2012 10:47, schrieb Igor Pashev: >> 19.04.2012 12:30, Björn Esser пишет: >>> Severity: wishlish >>> >>> *** UPDATE *** New version from svn trunk (544~svn replaces >>> 2.1.0). Documentation (html + LaTeX) is now included in >>> build-process. >>> >>> Dear mentors, >>> >>> I am looking for a sponsor for my package "libblocxx". Have a >>> look at it, please. >>> >>> * Package name: libblocxx Version : 544~svn-1 >>> Upstream Author : (C) 2000-2009 Quest Software, Inc. (C) >>> 2005-2006 Novell, Inc. All rights reserved. (C) 2000-2006 >>> Vintela, Inc. All rights reserved. * URL : >>> http://blocxx.sf.net/ * License : BSD-3 Section >>> : libs >>> >>> It builds those binary packages: >>> >>> libblocxx-dbg - BloCxx debugging symbols libblocxx-dev - >>> BloCxx development libraries and header files libblocxx-doc - >>> BloCxx documentation and examples libblocxx8 - BloCxx - C++ >>> Framework for Application Development >>> >>> To access further information about this package, please visit >>> the following URL: >>> >>> http://mentors.debian.net/package/libblocxx >>> >>> >>> Alternatively, one can download the package with dget using >>> this command: >>> >>> dget -x >>> http://mentors.debian.net/debian/pool/main/libb/libblocxx/libblocxx_544~svn-1.dsc >>> >>> >>> > >>> More information about hello can be obtained from >>> http://www.example.com. >>> >>> Changes since the last upload: >>> >>> * Initial release (Closes: #647639) * include documentation in >>> build * add patch: use default automake * add patch: change >>> BloCxx version to 544svn * add patch: fix path to dot in >>> Doxyfile.in * add patch: exclude testsuite from documentation >>> * add patch: don't build autogenerated manpages >>> >>> Regards, Björn Esser >>> >>> > >> I'm not intended to support this package :-), but here are some >> issues I see: > >> 1. Version in configure.in is 2.3.0, so debian package it should >> be 2.3.0~svn544 or 2.2.0+svn544 (make sure if 2.3 is ongoing >> release) > >> 2. hello http://www.example.com :-) > > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+P7HwACgkQ3u1SIc8s7PUjowD/d/aG+JXmOBObGorDvCdpJqba nlPe5op206iCjruqoyIBAK0xgsAqe5+Q5f2W53IB0ZD5Rs3iq0fGqlnAM12CTETx =0EHN -END PGP SIGNATURE- -- 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/4f8fec7d.1010...@googlemail.com
Bug#669209: RFS: yp-svipc/0.13-1 [ITP] -- System V InterProcess Communication for Python/Yorick
(message originally sent to the ITP instead of the RFS)
Hi,
Le 18/04/12 21:03, Jakub Wilk a écrit :
> (I don't intend to sponsor this package.)
Thanks for the comments nevertheless. I've fixed them all.
In the meantime, upstream succeeded in porting this extension to python
3, so I've updated the package accordingly:
http://mentors.debian.net/package/yp-svipc
http://mentors.debian.net/debian/pool/main/y/yp-svipc/yp-svipc_0.14-1.dsc
> I'd rather not use ${python:Provides}. See:
> http://lists.debian.org/20110324164804.ga5...@jwilk.net
I see there's a consensus in this direction and that's in line with [1],
but that's contrary to the Python Policy as published in [2] which
states " Provides in binary packages of the form |python-foo| must be
specified, if the package contains an extension for more than one python
version."
[1] http://wiki.debian.org/Python/Policy
[2] http://www.debian.org/doc/packaging-manuals/python-policy/
I'm guessing [2] should be fixed and I'll file a bug report to that
effect tomorrow*.
Regards, Thibaut.
* http://bugs.debian.org/669346
signature.asc
Description: OpenPGP digital signature
Re: Documentation generated by doxygen and Debian Policy
On Thu, Apr 19, 2012 at 3:36 AM, Boris Pek wrote: > Hi list, > > I found that in package qxmpp is used HTML documentation from upstream > tarball. > This documentation was not generated by doxygen during build process. Should > I make a bug report? If yes, which section of Debian Policy I should point to? Well, there's nowhere in the DFSG or copyright (i'm assuming) that says that it must be in some format X. If the original source is, in fact, HTML, there's no problem. The idea is that you communicate the program in a preferable format which can be used (or in some cases, actually is) the thing you distribute. If the docs were generated, and they have a better source format, you should encourage them to use that. The relevant Debian policy is DFSG point 2[1] (Must include source code) :) > > Best regards, > Boris > > > -- > 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/175731334821...@web6g.yandex.ru > HTH, Paul [1]: http://www.debian.org/social_contract -- All programmers are playwrights, and all computers are lousy actors. #define sizeof(x) rand() :wq -- 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/CAO6P2QTJUn8+occ1E=uP787PGYYXM6dyJabcCVOeGYKYoQYy=q...@mail.gmail.com
Bug#669373: RFS: flactag/2.0.1-1 ITP #507876
Package: sponsorship-requests Severity: wishlist Dear mentors, We are looking for a sponsor for our package "flactag" * Package name: flactag Version : 2.0.1-1 Upstream Author : Andy Hawkins * URL : http://flactag.sourceforge.net/ * License : GPL v3 Section : sound It builds these binary packages: flactag- Tagger for whole-album FLAC files using data from MusicBrainz To access further information about this package, please visit the following URL: http://mentors.debian.net/package/flactag Alternatively, one can download the package and dependencies with dget using these commands: dget -x http://mentors.debian.net/debian/pool/main/libm/libmusicbrainz/libmusicbrainz_4.0.1-1.dsc dget -x http://mentors.debian.net/debian/pool/main/f/flactag/flactag_2.0.1-1.dsc More information about flactag can be obtained from http://flactag.sourceforge.net NOTE: The preparation of the new upstream releases of these packages and the building of the Debian packages has been a collaborative effort between myself, Andy Hawkins and Timo Aaltonen Regards, Daniel Pocock -- 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/4f900e27.6020...@pocock.com.au
Re: Documentation generated by doxygen and Debian Policy
>> I found that in package qxmpp is used HTML documentation from upstream >> tarball. >> This documentation was not generated by doxygen during build process. Should >> I make a bug report? If yes, which section of Debian Policy I should point >> to? > > Well, there's nowhere in the DFSG or copyright (i'm assuming) > that says that it must be in some format X. If the original source is, > in fact, HTML, there's no problem. > > The idea is that you communicate the program in a preferable format > which can be used (or in some cases, actually is) the thing you > distribute. > > If the docs were generated, and they have a better source format, you > should encourage them to use that. > > The relevant Debian policy is DFSG point 2[1] (Must include source code) :) Thank you for a reply. Perhaps I wrote unclear. In few steps: 1) There is some HTML documentation [1] in upstream tarball. 2) This documentation was generated using Doxygen. 3) This documentation was packaged in package libqxmpp-doc as is. 4) I can not find in tarball the necessary sources for Doxygen and instructions how to generate this documentation manually. The question is: should I make a bug report in this case? I am not subscribed to debian-devel list, so I've asked here. Best regards, Boris [1] http://qxmpp.googlecode.com/svn-history/tags/qxmpp-0.4.0/doc/html/ -- 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/69811334841...@web30e.yandex.ru
Re: Documentation generated by doxygen and Debian Policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Boris! I just investigated a bit inside the source-tar doing this: cd doc qmake make ./doxyfilter -g sed -i -e's/GENERATE_LATEX.*= NO/GENERATE_LATEX = YES/'\ - -e's/GENERATE_MAN.*= NO/GENERATE_MAN = YES/' ./Doxyfile doxygen ./Doxyfile cd .. there you go having freshly generated docs as html, LaTeX and man-pages. Hope this helps you a bit. Feel free to contact me if there are issues/questions. Cheers, Björn Am 19.04.2012 15:18, schrieb Boris Pek: >>> I found that in package qxmpp is used HTML documentation from >>> upstream tarball. This documentation was not generated by >>> doxygen during build process. Should I make a bug report? If >>> yes, which section of Debian Policy I should point to? >> >> Well, there's nowhere in the DFSG or copyright (i'm assuming) >> that says that it must be in some format X. If the original >> source is, in fact, HTML, there's no problem. >> >> The idea is that you communicate the program in a preferable >> format which can be used (or in some cases, actually is) the >> thing you distribute. >> >> If the docs were generated, and they have a better source format, >> you should encourage them to use that. >> >> The relevant Debian policy is DFSG point 2[1] (Must include >> source code) :) > > Thank you for a reply. > > Perhaps I wrote unclear. In few steps: 1) There is some HTML > documentation [1] in upstream tarball. 2) This documentation was > generated using Doxygen. 3) This documentation was packaged in > package libqxmpp-doc as is. 4) I can not find in tarball the > necessary sources for Doxygen and instructions how to generate this > documentation manually. > > The question is: should I make a bug report in this case? > > I am not subscribed to debian-devel list, so I've asked here. > > Best regards, Boris > > [1] > http://qxmpp.googlecode.com/svn-history/tags/qxmpp-0.4.0/doc/html/ > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+QFncACgkQ3u1SIc8s7PUu3gD+MN43TNeN7wgDVfE/Z3EcyUih GLsojczunkw4cwdK5QwA/ik1XtT59I/uW8q7kcy0Czlwq1Fak+FovVZJoLrVVH9C =uyfw -END PGP SIGNATURE- -- 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/4f901677.2060...@googlemail.com
Re: Documentation generated by doxygen and Debian Policy
On Thu, Apr 19, 2012 at 9:18 AM, Boris Pek wrote: >>> I found that in package qxmpp is used HTML documentation from upstream >>> tarball. >>> This documentation was not generated by doxygen during build process. >>> Should >>> I make a bug report? If yes, which section of Debian Policy I should point >>> to? >> >> Well, there's nowhere in the DFSG or copyright (i'm assuming) >> that says that it must be in some format X. If the original source is, >> in fact, HTML, there's no problem. >> >> The idea is that you communicate the program in a preferable format >> which can be used (or in some cases, actually is) the thing you >> distribute. >> >> If the docs were generated, and they have a better source format, you >> should encourage them to use that. >> >> The relevant Debian policy is DFSG point 2[1] (Must include source code) :) > > Thank you for a reply. > > Perhaps I wrote unclear. In few steps: > 1) There is some HTML documentation [1] in upstream tarball. > 2) This documentation was generated using Doxygen. A, I see. > 3) This documentation was packaged in package libqxmpp-doc as is. > 4) I can not find in tarball the necessary sources for Doxygen and > instructions > how to generate this documentation manually. Are these API docs? Is it just a case of a missing Doxyfile (I think that's the name) or is there something more? Is it missing from Upstream's source tree? > > The question is: should I make a bug report in this case? It's important to protect our users' freedoms, and it'd be the clear right thing to do to include source in the source dist in Debian, but I'd not accuse upstream of anything. I'd send a mail out, asking where the source is for the docs, and how one might rebuild them. > > I am not subscribed to debian-devel list, so I've asked here. This is a perfect place to ask. > > Best regards, > Boris > > [1] http://qxmpp.googlecode.com/svn-history/tags/qxmpp-0.4.0/doc/html/ Just a quick glance shows this: http://qxmpp.googlecode.com/svn-history/tags/qxmpp-0.4.0/doc/doc.pro Could that be used to generate a Doxyfile and run the generation of the docs? I've not looked at it in a super long time, so I'm not sure how Doxygen works anymore. > > > -- > 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/69811334841...@web30e.yandex.ru > -- All programmers are playwrights, and all computers are lousy actors. #define sizeof(x) rand() :wq -- 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/cao6p2qtfxvqwukrrey5eekzyrheq614ehqe5-8zpq9jsagu...@mail.gmail.com
Re: Documentation generated by doxygen and Debian Policy
Le 19/04/12 15:18, Boris Pek a écrit : >>> I found that in package qxmpp is used HTML documentation from upstream >>> tarball. >>> This documentation was not generated by doxygen during build process. >>> Should >>> I make a bug report? If yes, which section of Debian Policy I should point >>> to? >> >> Well, there's nowhere in the DFSG or copyright (i'm assuming) >> that says that it must be in some format X. If the original source is, >> in fact, HTML, there's no problem. [...] > > Thank you for a reply. > > Perhaps I wrote unclear. In few steps: > 1) There is some HTML documentation [1] in upstream tarball. > 2) This documentation was generated using Doxygen. > 3) This documentation was packaged in package libqxmpp-doc as is. > 4) I can not find in tarball the necessary sources for Doxygen and > instructions >how to generate this documentation manually. > > The question is: should I make a bug report in this case? > Hi, The source are the .h and .cpp files, so they are included. What I don't see is the DoxyFile (giving a quick glance to the source package). From the timestamps of the html files, I'd say that they have been generated by the maintainer just before uploading (actually, they have been generated 7 minutes after the changlogg entry was last finalized). I believe it is generally accepted that every file that can be (re)generated during the build process should be, for various reasons. In particular: - we must make sure that the sources we ship are the right ones from the generated files; - we must be able to generate the files from their source using only Debian/main. However I can't find anywhere in the Policy that it's an actual requirement to re-generate this kind of files at build-time. So yes, I think you can file a bug requesting that the maintainer builds the doc as part of "dpkg-buildpackage", but I can't find a clear-cut requirement stated in the policy. If you can provide a patch, all the better. Best regards, Thibaut. -- 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/4f9019e7.90...@free.fr
Re: Documentation generated by doxygen and Debian Policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 As stated in my previous message, this is the way to generate the needed Doxyfile: cd doc (inside the tarball-basedir ) qmake ( produce Makefile ) make ( build ./doxyfilter ) ./doxyfilter -g ( generates Doxyfile ) after this some sed-magic to enable docs in LaTex and man-page format: sed -i -e's/GENERATE_LATEX.*= NO/GENERATE_LATEX = YES/'\ - -e's/GENERATE_MAN.*= NO/GENERATE_MAN = YES/' ./Doxyfile use doxygen to generate them docs: doxygen ./Doxyfile go back to tarball-basedir: cd .. done! Cheers, Björn Am 19.04.2012 15:57, schrieb Thibaut Paumard: > Le 19/04/12 15:18, Boris Pek a écrit : I found that in package qxmpp is used HTML documentation from upstream tarball. This documentation was not generated by doxygen during build process. Should I make a bug report? If yes, which section of Debian Policy I should point to? >>> >>> Well, there's nowhere in the DFSG or copyright (i'm assuming) >>> that says that it must be in some format X. If the original >>> source is, in fact, HTML, there's no problem. > [...] >> >> Thank you for a reply. >> >> Perhaps I wrote unclear. In few steps: 1) There is some HTML >> documentation [1] in upstream tarball. 2) This documentation was >> generated using Doxygen. 3) This documentation was packaged in >> package libqxmpp-doc as is. 4) I can not find in tarball the >> necessary sources for Doxygen and instructions how to generate >> this documentation manually. >> >> The question is: should I make a bug report in this case? >> > > Hi, > > The source are the .h and .cpp files, so they are included. What I > don't see is the DoxyFile (giving a quick glance to the source > package). From the timestamps of the html files, I'd say that they > have been generated by the maintainer just before uploading > (actually, they have been generated 7 minutes after the changlogg > entry was last finalized). > > I believe it is generally accepted that every file that can be > (re)generated during the build process should be, for various > reasons. In particular: - we must make sure that the sources we > ship are the right ones from the generated files; - we must be able > to generate the files from their source using only Debian/main. > > However I can't find anywhere in the Policy that it's an actual > requirement to re-generate this kind of files at build-time. > > So yes, I think you can file a bug requesting that the maintainer > builds the doc as part of "dpkg-buildpackage", but I can't find a > clear-cut requirement stated in the policy. > > If you can provide a patch, all the better. > > Best regards, Thibaut. > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+QHQwACgkQ3u1SIc8s7PUpKQEAo/vcIjppK4CBYbtHfqMGD4nK 8U2WiR8HUki95P+AAM0BAMZi2+kI0UI3azjrpNMrfhWmGXPzb7uNDrHxmC2xwuU0 =uwKg -END PGP SIGNATURE- -- 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/4f901d0c.2050...@googlemail.com
Re: Documentation generated by doxygen and Debian Policy
Thanks all for answers. I was searching for: /doxyfilter -g This command generates Doxyfile which is necessary for Doxygen. > However I can't find anywhere in the Policy that it's an actual > requirement to re-generate this kind of files at build-time. So do I. That's why I've asked here should I make a bug report or not? Best regards, Boris -- 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/128231334844...@web29d.yandex.ru
Re: Documentation generated by doxygen and Debian Policy
Le Thu, Apr 19, 2012 at 03:57:59PM +0200, Thibaut Paumard a écrit : > > I believe it is generally accepted that every file that can be > (re)generated during the build process should be, for various reasons. Hi all, I think that there is a consensus that generated files must be regenerable, and that it is a bug if their build system is broken. The best way to ensure this is to regenerate them at build time, however it is not a requirement. In particular, I do not see advantages in distributing rebuilds that would for instance only update time stamps. It is increasing debdiffs and heating the planet for no benefit. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20120419142040.ga30...@falafel.plessy.net
Re: Documentation generated by doxygen and Debian Policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 19.04.2012 16:16, schrieb Boris Pek: > Thanks all for answers. You're welcome. > I was searching for: /doxyfilter -g This command generates Doxyfile > which is necessary for Doxygen. > >> However I can't find anywhere in the Policy that it's an actual >> requirement to re-generate this kind of files at build-time. > > So do I. That's why I've asked here should I make a bug report or > not? I would say no, because putting something like this inside debian/rules will (re)generate the documentation (html, LaTeX, manpages) during pkg-build: You need to add doxygen-latex and graphviz as build-deps. override_dh_auto_build: dh_auto_build cd doc rm -rf html/ qmake make ./doxyfilter -g sed -i -e's/GENERATE_LATEX.*= NO/GENERATE_LATEX = YES/' \ -e's/GENERATE_MAN.*= NO/GENERATE_MAN = YES/' ./Doxyfile doxygen ./Doxyfile cd .. It's just up to you including the generated stuff inside the -doc pkg. > Best regards, Boris Feel free to ask me if you need some further help about packaging all the stuff. Cheers, Björn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF0EAREIAAYFAk+QIdIACgkQ3u1SIc8s7PU4qAD0DzeIGuvk7m7T3CaTxWjgrqMM TeamW1rzjbej+jGFrgEAq+tZxB+jVXlyfHiM68QoPD69UeWGCd/3gysAojiHK3c= =A7/s -END PGP SIGNATURE- -- 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/4f9021d2.9080...@googlemail.com
Re: Documentation generated by doxygen and Debian Policy
Le 19/04/12 16:20, Charles Plessy a écrit : > Le Thu, Apr 19, 2012 at 03:57:59PM +0200, Thibaut Paumard a écrit : >> >> I believe it is generally accepted that every file that can be >> (re)generated during the build process should be, for various reasons. > > Hi all, > > I think that there is a consensus that generated files must be regenerable, > and > that it is a bug if their build system is broken. The best way to ensure this > is to regenerate them at build time, however it is not a requirement. In > particular, I do not see advantages in distributing rebuilds that would for > instance only update time stamps. It is increasing debdiffs and heating the > planet for no benefit. > > Have a nice day, > Hi, File timestamps won't show up in debdiff. At the very least, the maintainer should (IMNSHO) regenerate the files himself and check that they match what ends-up being distributed. And he should also document this process in debian/README.source. Honestly, I think it's simpler and less error-prone to just distribute the regenerated files. But as you said, it's not a policy requirement. Regards, Thibaut. -- 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/4f9028f5.7090...@free.fr
Re: Documentation generated by doxygen and Debian Policy
Le 19/04/12 16:31, Björn Esser a écrit : > Am 19.04.2012 16:16, schrieb Boris Pek: >> Thanks all for answers. > > You're welcome. > >> I was searching for: /doxyfilter -g This command generates Doxyfile >> which is necessary for Doxygen. > >>> However I can't find anywhere in the Policy that it's an actual >>> requirement to re-generate this kind of files at build-time. > >> So do I. That's why I've asked here should I make a bug report or >> not? > > I would say no, because putting something like this inside > debian/rules will (re)generate the documentation (html, LaTeX, > manpages) during pkg-build: > Yes, that's exactly the point. On the other hand, since the the -doc package is arch-indep and the auto-builders don't regenerate arch-indep binary packages, this will really only run on the uploader's machine. > You need to add doxygen-latex and graphviz as build-deps. Rather as Build-Depends-Indep. > override_dh_auto_build: which would also run when building only the arch-dep packages. rather: build-doc: > cd doc ;\ > rm -rf html/ ;\ > qmake ;\ > make ;\ > ./doxyfilter -g ;\ > sed -i -e's/GENERATE_LATEX.*= NO/GENERATE_LATEX = YES/' ;\ > -e's/GENERATE_MAN.*= NO/GENERATE_MAN = YES/' ./Doxyfile ;\ > doxygen ./Doxyfile build-indep: build-doc dh $@ Regards, Thibaut. -- 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/4f9025c9.1070...@users.sourceforge.net
Bug#669401: RFS: roxterm/2.6.1-1
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "roxterm" * Package name: roxterm Version : 2.6.1-1 Upstream Author : Tony Houghton URL : http://roxterm.sourceforge.net License : GPL2+ Section : x11 It builds those binary packages: * roxterm - Multi-tabbed GTK+/VTE terminal emulator - virtual package for GTK3 * roxterm-common - Multi-tabbed GTK+/VTE terminal emulator - common files * roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator - GTK2 version * roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator - GTK3 version To access further information about this package, please visit the following URL: http://mentors.debian.net/package/roxterm Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_2.6.1-1.dsc More information about roxterm can be obtained from http://roxterm.sourceforge.net Changes since the last upload: * Ensure vte widgets realized before reading xid (Closes: #663736). * Explicitly close pty when deleting a terminal. * Warnings apply to closing windows via menu (Closes: #664887). * Debian packaging now maintained in master branch again. * Changed close warning dialog buttons to Yes/No. * Honour login option when restoring a session (Closes: #663739). * Reread GdkWindow when re-mapping windows when compositing changes. * debian/watch: Corrected pcre syntax for uncaptured bz2/gz suffix. Regards, Tony Houghton -- 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/20120419160313.5f9dccf3@tiber
Processed: Re: Bug#669373: RFS: flactag/2.0.1-1 ITP #507876
Processing commands for cont...@bugs.debian.org: > owner 669373 alger...@madhouse-project.org Bug #669373 [sponsorship-requests] RFS: flactag/2.0.1-1 ITP #507876 Owner recorded as alger...@madhouse-project.org. > tag 669373 + pending Bug #669373 [sponsorship-requests] RFS: flactag/2.0.1-1 ITP #507876 Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 669373: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669373 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13348518093511.transcr...@bugs.debian.org
Bug#669373: RFS: flactag/2.0.1-1 ITP #507876
owner 669373 alger...@madhouse-project.org tag 669373 + pending thanks Daniel Pocock writes: > We are looking for a sponsor for our package "flactag" > > * Package name: flactag >Version : 2.0.1-1 >Upstream Author : Andy Hawkins > * URL : http://flactag.sourceforge.net/ > * License : GPL v3 >Section : sound I have a big collection of whole-album flacs, and would like to see this package in Debian, so I'll do a review and handle the upload (once blocking issues - if any - are fixed, of course). -- |8] -- 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/87wr5bbt4i.fsf@algernon.balabit
Bug#669373: RFS: flactag/2.0.1-1 ITP #507876
> I have a big collection of whole-album flacs, and would like to see this > package in Debian, so I'll do a review and handle the upload (once > blocking issues - if any - are fixed, of course). > Great - thanks for the prompt reply Andy and I are lurking about in #flactag on irc.freenode.net -- 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/4f903c5c.7080...@pocock.com.au
Re: Bug#669373: RFS: flactag/2.0.1-1 ITP #507876
On Thu, Apr 19, 2012 at 03:07:51PM +0200, Daniel Pocock wrote: > flactag- Tagger for whole-album FLAC files using data from > MusicBrainz This is closing a fairly old (2008) ITP, so it might be good to re-evaluate other software in the same space that is in Debian now -- particularly beets, which appears to be very similar (also a CLI-interface, MusicBrainz-backed, album-oriented tagger but supports formats besides FLAC). If you think flactag's different enough, please highlight some of its unique features in the long description so users can choose the program that best suits them. Separately, please do not Build-Depend on libjpeg62-dev, as it's being removed. See #547393. > dget -x > http://mentors.debian.net/debian/pool/main/libm/libmusicbrainz/libmusicbrainz_4.0.1-1.dsc As you know, there's already a binary package "libmusicbrainz4-dev" in the archive, which Timo has been working on removing (thanks!). However, this new package still couldn't go in until the old one is removed. - Nicholas -- 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/20120419184103.gq15...@ofb.net
Re: Bug#669373: RFS: flactag/2.0.1-1 ITP #507876
On 19/04/12 20:41, Nicholas Breen wrote: > On Thu, Apr 19, 2012 at 03:07:51PM +0200, Daniel Pocock wrote: >> flactag- Tagger for whole-album FLAC files using data from >> MusicBrainz > > This is closing a fairly old (2008) ITP, so it might be good to re-evaluate > other software in the same space that is in Debian now -- particularly beets, > which appears to be very similar (also a CLI-interface, MusicBrainz-backed, > album-oriented tagger but supports formats besides FLAC). If you think > flactag's different enough, please highlight some of its unique features in > the > long description so users can choose the program that best suits them. I just had a quick look at beets description. I think the fact that beets is python and flactag+libmusicbrainz4 is C++ is a sufficient reason to have both in Debian. A second reason is that flactag is more lightweight: it doesn't try to be an all-in-one solution. Some people may prefer having separate tools to accomplish tasks that don't fit within the workflow of a solution like beets. > Separately, please do not Build-Depend on libjpeg62-dev, as it's being > removed. > See #547393. It does still appear in wheezy... http://packages.debian.org/search?keywords=libjpeg62-dev but we'll get rid of that dependency. If I understand correctly, flactag should depend on libjpeg8 (and not libjpeg7?) http://packages.debian.org/search?keywords=libjpeg8 >> dget -x >> http://mentors.debian.net/debian/pool/main/libm/libmusicbrainz/libmusicbrainz_4.0.1-1.dsc > > As you know, there's already a binary package "libmusicbrainz4-dev" in the > archive, which Timo has been working on removing (thanks!). However, this new > package still couldn't go in until the old one is removed. Given that the musicbrainz public API (as exposed from their internet server) has changed so dramatically, the old musicbrainz packages really do have to go, so this shouldn't be an issue? Is there any delay/lead time we should anticipate to purge the old package? -- 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/4f9064ed.1010...@pocock.com.au
Parsing single debian/control file using python-debian
Hi,
I'm unsure whether this might be the proper mailing list to ask
questions like this - but I have no better idea.
I intend to parse some machine readable files in some team maintained
packages. When trying something like
ctrl = open('debian/control','r')
for ctrlstanza in deb822.Packages.iter_paragraphs(ctrl):
print ctrlstanza
I get the full text of debian/control (same if I try
deb822.Sources.iter_paragraphs instead) - so there is no chance to parse
the single paragraphs in the Sources and Binary packages section. I
might be stupid because I'd regard this as a basic use case for
python-debian but I did not found a way to approach this. Any hint how
to do this properly?
Kind regards and thanks for any hint
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/20120419200126.ga14...@an3as.eu
Bug#663151: RFS: rhinote/0.7.4-2 -- virtual sticky-notes for your desktop
Dear mentors, please consider reviewing and sponsoring this new Rhinote upload. As you can see from the changelog entry reported below, the updated package contains several improvements that would make using Rhinote much better; moreover, a Debian member has already reviewed the patches and found them to be okay. Thank you for your time. On Thu, Mar 08, 2012 at 10:58:50PM +0100, Andrea Bolognani wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "rhinote" > > * Package name: rhinote > Version : 0.7.4-2 > Upstream Author : Marv Boyes > * URL : http://rhinote.tuxfamily.org/ > * License : GPL-2+ > Section : x11 > > It builds those binary packages: > > rhinote- virtual sticky-notes for your desktop > > To access further information about this package, please visit the following > URL: > > http://mentors.debian.net/package/rhinote > > Alternatively, one can download the package with dget using this command: > > dget -x > http://mentors.debian.net/debian/pool/main/r/rhinote/rhinote_0.7.4-2.dsc > > More information about rhinote can be obtained from > http://rhinote.tuxfamily.org/ . > > Changes since the last upload: > > * 001-simplify-imports.diff: > - improve the way modules are imported. > * 002-use-secure-printfile.diff: > - avoid potential symlink attacks and cluttering the user's home. > * 003-test-for-external-commands.diff: > - ensure external commands are available before calling them. > * 004-use-popen.diff: > - replace os.system() with the more secure subprocess.Popen(). > * 005-support-lp.diff: > - add support for the lp command in addition to lpr. > * 006-set-print-job-name.diff: > - provide a descriptive name for the print job. > * 007-set-class-name.diff: > - set application name for use by window managers. > * Simplify Depends: to cups-client | lpr. > * Bump Standards-Version to 3.9.3 (no changes needed). > > The software has been heavily patched after Paul Wise has reviewed it[1] > and found a bunch of issues with upstream’s code. He later took a look > at the patches[2] and found them to be okay. > > > [1] http://lists.debian.org/debian-mentors/2012/01/msg00579.html > [2] http://lists.debian.org/debian-mentors/2012/02/msg00077.html -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: NMU and delayed
On 04/13/2012 08:00 AM, Tobias Frost wrote: Am Freitag, den 13.04.2012, 01:39 +0400 schrieb Michael Tokarev: On 13.04.2012 01:08, Tomasz Muras wrote: Hello, A Debian developer has uploaded a NMU (moodle 1.9.9.dfsg2-5.1) to DELAYED/7-DAY [1]. I have incorporated his changes, and added a new release (moodle 1.9.9.dfsg2-6) - the changelog now looks like [2]. Is there any reason I should wait for that NMU to get processed in DELAYED queue? Or can I go ahead and upload a newer package with his and my changes? You can actually ask the developer who uploaded that NMU. And I guess he gave you some information about this, too. But, without actually looking at the provided links, I can say that usually an NMU which is uploaded into DELAYED queue especially gives the actual maintainer some time to catch up. Ie, if you can incorporate the changes and upload new version faster, just go ahead and do it. Provided the DELAYED queue wasn't choosen due to some other reason, -- in which case the developer who uploaded it there will know better for sure, again... > You do not need to wait for the NMU. > If you upload a newer version before the DELAY expires, the NMU is > automatically cancelled. Thanks for all the answers, I've uploaded updated package and NMU from the DELAYED queue got rejected because of the older version. I have kept the changelog entry from the NMU upload but what I didn't realize is that bugs closed by previous (NUM) changelog entry will not be closed automatically - so I had to close them manually. cheers, Tomek -- 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/4f908423.4020...@gmail.com
Bug#669565: RFS: gammaray/1.1.0-1 -- Tool for examining the internals of Qt application
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for package "gammaray". * Package name: gammaray Version : 1.1.0-1 Upstream Author : Klarälvdalens Datakonsult AB * URL : http://www.kdab.com/gammaray * License : GPL-2+ Section : devel It builds those binary packages: gammaray - Tool for examining the internals of Qt application gammaray-dbg - debugging symbols for gammaray Package source code can be accessed at collab-maint git repository: http://anonscm.debian.org/gitweb/?p=collab-maint/gammaray.git GammaRay is a tool for examining the internals of a Qt application and to some extent also manipulate it. GammaRay uses injection methods to hook into an application at runtime and provide access to a wide variety of interesting information. It provides easy ways of navigating through the complex internal structures you find in some Qt frameworks, such as QGraphicsView, model/view, QTextDocument, state machines and more. I would be glad if someone uploaded this package for me. Kind regards, Jakub Adam -- 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/4f908bd2.4050...@ktknet.cz
Tarball Debian Policy
Hello, I'm new on this list. I plan to create a source package to build several binary packages (including shell functions, shell scripts, udev rules and documentation). This will be a Debian native package. My question is about the tarball, especially files taking place outside of the debian/ directory: Is there best practice, implicit or explicit policy rules about the places where to put the files ? Can the directory trees reflect the paths files would have one time the binary packages will be installed on a system (for example: lib/bilibop/common.sh lib/bilibop/diskmap.sh lib/udev/bilibop_disk usr/bin/diskmap usr/share/initramfs-tools/hooks/bilibop-common usr/share/initramfs-tools/scripts/local-bottom/bilibop-lockfs etc.) or is it best to decrease path depth and even put as much files as possible at the root of the tarball ? Can I place them in arbitrary named directories or just shortcuts: bin/diskmap lib/bilibop_disk lib/common.sh lib/diskmap.sh initramfs-tools/bilibop-common initramfs-tools/bilibop-lockfs etc. or what ? Can I do as I want or have I to follow some good examples ? I have browsed some other tarballs with different conclusions, and read documentation, but never found something saying: "this is required" or more simply "this is a good way", "this is wrong, because..." or 'this is let at the discretion of the upstream developer". Is it the case ? Thanks in advance -- 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/n1r-kzt61kf...@safe-mail.net
Re: Documentation generated by doxygen and Debian Policy
Le Thu, Apr 19, 2012 at 05:02:13PM +0200, Thibaut Paumard a écrit : > Le 19/04/12 16:20, Charles Plessy a écrit : > > > > I think that there is a consensus that generated files must be regenerable, > > and > > that it is a bug if their build system is broken. The best way to ensure > > this > > is to regenerate them at build time, however it is not a requirement. In > > particular, I do not see advantages in distributing rebuilds that would for > > instance only update time stamps. It is increasing debdiffs and heating the > > planet for no benefit. > > File timestamps won't show up in debdiff. At the very least, the > maintainer should (IMNSHO) regenerate the files himself and check that > they match what ends-up being distributed. And he should also document > this process in debian/README.source. Honestly, I think it's simpler and > less error-prone to just distribute the regenerated files. But as you > said, it's not a policy requirement. There are other timestamps. Some documents contain the date where they were built, as an indication for the last time they were modified. For the packages I maintain, where I wrote manpages in DocBook XML, I do not regenerate them at each build and store the generated nroff code in the VCS where the package is maintained. This has the additional advantage that the package does not need to build-depend on the DocBook toolchain. debian/rules contains a target to rebuild, plus a comment explaining which packages to install. The point I am trying to make is that there is no single rule that has to be strictly followed by eveybody in all cases. Otherwise we would fall in the same selective blindess as for the freeness of pictures, videos, music and scientific data. Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20120420001744.ga13...@falafel.plessy.net
Bug#669580: RFS: auralquiz/0.8.1-1 -- simple music quiz game using your own music files
Package: sponsorship-requests Severity: normal Package name: auralquiz Version : 0.8.1 Upstream Author : Jan Kusanagi URL : http://jancoding.wordpress.com/auralquiz/ License : GPL-2+ Section : games It builds the single binary package 'auralquiz'. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/auralquiz Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/a/auralquiz/auralquiz_0.8.1-1.dsc Changes since the last upload: * Corrected the homepage/source URLs to point to the correct address. * wrap-and-sort -s the control file. * New upstream release. + Fixes FTBFS with gcc-4.7. (Closes: #667106) * Update the copyright Format URI now that it is formally released. * Bump Standards-Version to 3.9.3 without change. Thanks, Dean Evans -- 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/20120420173553.0007a409@sidspace
Re: Tarball Debian Policy
"bilibop project" writes: > I'm new on this list. > I plan to create a source package to build several binary packages > (including shell functions, shell scripts, udev rules and > documentation). This will be a Debian native package. My question is > about the tarball, especially files taking place outside of the > debian/ directory: You can do whatever you want outside of debian/. The tree can reflect what paths the files would have on the filesystem, or separate them by tool, or language, or role, or whatever else you find best. > or what ? Can I do as I want or have I to follow some good examples ? > I have browsed some other tarballs with different conclusions, and > read documentation, but never found something saying: "this is > required" or more simply "this is a good way", "this is wrong, > because..." or 'this is let at the discretion of the upstream > developer". Is it the case ? It is this last one. Upstream decides how the upstream tarball looks like. -- |8] -- 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/87r4vinckg@luthien.mhp
Re: NMU and delayed
Le 19/04/12 23:31, Tomasz Muras a écrit : > > Thanks for all the answers, I've uploaded updated package and NMU from > the DELAYED queue got rejected because of the older version. > I have kept the changelog entry from the NMU upload but what I didn't > realize is that bugs closed by previous (NUM) changelog entry will not > be closed automatically - so I had to close them manually. > Hi, You could have had your upload close them by passing -v to dpkg-genchanges when building. Regards, Thibaut. -- 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/4f91064b.2050...@free.fr
