Re: RFS: azureus (updated package, fixes RC bug)
On Wed Aug 12 15:08, Onkar Shinde wrote: I've fixed all warnings, and now the package is entirely lintian clean (even with --pedantic). IMHO it's ready for uploading. (I should be able to look at this tonight) I have few comments about the package. 1. In the launcher script, use of Sun java is being forced. That's a bad thing. Try to use java-wrappers to detect JRE, specify classpath and hence simplify the launcher script. Hmm, if Sun Java (as opposed to openjdk) is required to run it needs to be in contrib not main. This needs to be avoided. If it's just a case of java -jar with the right classpath there's also jarwrapper. 4. Are you using any features specific to version 7 of debhelper? If not then reduce the version in build-dep and adjust compat file accordingly. debhelper 7 is in stable and old-stable backports, I don't see any reason why it shouldn't be the standard compat version. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: RFS: azureus (updated package, fixes RC bug)
On Tue, Aug 11, 2009 at 11:57 PM, Adrian Perezadrianperez@gmail.com wrote: Sorry about the pixmap size, gimp really played at me on this ;) I've fixed all warnings, and now the package is entirely lintian clean (even with --pedantic). IMHO it's ready for uploading. I have few comments about the package. 1. In the launcher script, use of Sun java is being forced. That's a bad thing. Try to use java-wrappers to detect JRE, specify classpath and hence simplify the launcher script. 2. You should block all the auto-updates for this package if it is possible by patching the code. This makes sure that user is always using the package shipped in distribution and there is consistency in bug reports. 3. Is fastjar really a required build dependency? 4. Are you using any features specific to version 7 of debhelper? If not then reduce the version in build-dep and adjust compat file accordingly. 5. Why is junit a build dependency? I didn't see any tests being run at the time of package build. 6. debian/build.properties should be debian/ant.properties. But don't think this is major issue. Hope this helps. Regards, Onkar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: trend
Dear mentors, I am looking for a sponsor for my package trend. * Package name: trend Version : 1.0-1 Upstream Author : Yuri D'Elia wav...@thregr.org * URL : http://www.thregr.org/~wavexx/software/trend/ * License : LGPL Section : utils It builds these binary packages: trend - a general-purpose, efficient trend graph The package appears to be lintian clean. The upload would fix these bugs: 541106 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/trend - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/trend/trend_1.0-1.dsc I would be glad if someone uploaded this package for me. Kind regards Yuri D'Elia -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
How to specify a command to run if SELinux is installed subsequent to installing a package
I am packaging GT.M (http://fis-gtm.com http://sourceforge.net/projects/fis-gtm) which is released under AGPL v3. GT.M requires the ability to execute dynamically compiled code (it's a feature of the MUMPS language). To give GT.M this permission with SELinux, the usual installation of GT.M executes a command such as chcon -t texrel_shlib_t libgtmshr.so. But this presumes that SELinux is installed and operational. If SELinux is installed or configured later, this command will need to be run at that time. Is there a way to tell the Debian package manager, if SELinux is installed or turned on, run this command? Thank you very much, in advance. Regards -- Bhaskar K.S. Bhaskar Senior Vice President Fidelity Information Services, Inc. 2 West Liberty Boulevard, Suite 300 Malvern, PA 19355, USA +1 (610) 578-4265 office +1 (610) 620-3355 mobile -- GT.M - Rock solid. Lightning fast. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: How to specify a command to run if SELinux is installed subsequent to installing a package
Probably just run chcon at install time when selinux is active? You want the maintainer scripts stuff, which is documented here: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html http://women.debian.org/wiki/English/MaintainerScripts -- 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
Re: How to specify a command to run if SELinux is installed subsequent to installing a package
Hi! K.S. Bhaskar schrieb: GT.M requires the ability to execute dynamically compiled code (it's a feature of the MUMPS language). To give GT.M this permission with SELinux, the usual installation of GT.M executes a command such as chcon -t texrel_shlib_t libgtmshr.so. But this presumes that SELinux is installed and operational. If SELinux is installed or configured later, this command will need to be run at that time. Is there a way to tell the Debian package manager, if SELinux is installed or turned on, run this command? AFAIK this is not possible. With my quite non existance knowlegde on selinux, I think you should contact the maintainers of the sepolicy to ship it with your changes by default. Best regards, Alexander signature.asc Description: OpenPGP digital signature
Re: RFS: trend
On Wed, Aug 12, 2009 at 8:37 PM, Yuri D'Eliawav...@users.sf.net wrote: I am looking for a sponsor for my package trend. Which of the things I wrote in private mail did you take action on and which actions did you take for each of them? -- 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
Re: RFS: azureus (updated package, fixes RC bug)
On Wed, 2009-08-12 at 15:08 +0530, Onkar Shinde wrote: I have few comments about the package. There are welcome, that was what I was asking for. ;) 1. In the launcher script, use of Sun java is being forced. That's a bad thing. Try to use java-wrappers to detect JRE, specify classpath and hence simplify the launcher script. Done with java-wrappers. Thanks. 2. You should block all the auto-updates for this package if it is possible by patching the code. This makes sure that user is always using the package shipped in distribution and there is consistency in bug reports. Working on it, although I'm not quite sure users may want this. 3. Is fastjar really a required build dependency? Actually, no, that was from previous packaging. Dropped. 4. Are you using any features specific to version 7 of debhelper? If not then reduce the version in build-dep and adjust compat file accordingly. Matthew answered that. 5. Why is junit a build dependency? I didn't see any tests being run at the time of package build. It's actually required for compiling, although I could exclude tests from the build, but those actually help me with testing, funny, ah.? 6. debian/build.properties should be debian/ant.properties. But don't think this is major issue. Agree. Isn't a major issue, could be renamed of course, for now I don't see why. Hope this helps. Sure it did. Uploaded to mentors, and commited at: svn://svn.debian.org/svn/pkg-java/trunk/azureus. Regards, Onkar -- Best regards, Adrian Perez adrianperez@gmail.com signature.asc Description: This is a digitally signed message part
Re: RFS: trend
On Wed, 12 Aug 2009 22:58:59 +0800 Paul Wise p...@debian.org wrote: On Wed, Aug 12, 2009 at 8:37 PM, Yuri D'Eliawav...@users.sf.net wrote: I am looking for a sponsor for my package trend. Which of the things I wrote in private mail did you take action on and which actions did you take for each of them? First, I made sure that the package built from source in a chroot (this is the first time I ever used pbuilder/cowbuilder/etc). qemubuilder looked promising for testing all the archs at once, but failed to work for me (bug #441043). The package built fine inside cowbuilder/pbuilder from a fresh sid in both i386/amd64 variants. The package built and executed fine inside a native ppc debian host that I have here (again using pbuilder). I tried crosscompiling with gcc also for arm looking for compilation issues, but I didn't try all the other variants inside the qemu images you suggested. The source does not contain any libraries. No compilation warnings are produced. I tested the executable against valgrind (with both memcheck and helgrind; since I am upstream, this was a rather easy task). For instance, lintian only reported warnings in the man page which I didn't notice before, so I fixed them directly in the original source package with a new release instead of bloating the package with patch managers. There are no security threats that the package can expose directly. This is a simple, non-setuid program. There are no configuration files with permission issues. No files are ever created directly. No network connections are established. I did read already most of documentation links you sent me. After reading again the debian policy I've switched the priority or the original package from optional to extra. I also switched the versioning scheme of the upstream source to mayor.minor (I previously just had a date). I'm using the package myself on all my machines. The only unclear task was about uploading the package to mentors.debian.org. Why building a binary package is required if only the source is used? I didn't assign any package tags in debian/control. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: I want to delete an ITP
Hello Leinier, first of all, this question is more fit for debian-mentors that for -devel, so I'm adding the list to CC (please follow up there, removing -devel). 2009/8/12 Leinier Cruz Salfran salfra...@ipigto.rimed.cu: Hello. I'm creating my first package, after reading the debian policy and others mails in 'debian-mentors' list I want to delete the ITP Bug #539568 in order to create a new one with the same library but with other name .. How can I do that? Well, if you only want to change the package name, simply retitle the bug. Instructions are at [1]. Please also note that the package name you specify in the ITP is the source package name, not the binary one(s) (and not, the may also not correspond, in some cases). [1] http://www.debian.org/Bugs/server-control In case you need also to add new information, do so mailing the bug at nn...@bugs.debian.org Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: I want to delete an ITP
2009/8/12 Leinier Cruz Salfran salfra...@ipigto.rimed.cu: I changed the source package name. I readed [1] .. Correct me if I'm wrong, please well, if you ask, you should wait for a reply... I can send a mail to 'cont...@bugs.debian.org' with body: reassign 539568 libsockets++2 2.3.5 no, 'wnpp' metapackage is the correct one to use for ITPs retitle 539568 libsockets++2: C++ sockets class library is this the same title as before (hint: ITP: libsockets++ -- C++ sockets wrapper library) with only the package name changed? (hint: no) - retitle it correctly. Moreover, why adding the '2' to the package name? (I didn't follow the thread that lead to this package rename). one question mark is more the enough to express a question. Thanks welcome -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: azureus (updated package, fixes RC bug)
On Wed Aug 12 11:44, Adrian Perez wrote: Sure it did. Uploaded to mentors, and commited at: svn://svn.debian.org/svn/pkg-java/trunk/azureus. Uploaded Matt -- Matthew Johnson signature.asc Description: Digital signature
How to change description of IPT bug
I recently submitted some intention to package bugs, and have received suggestions to improve the title and detailed descriptions. I can see how to change the title (using the retitle command described at http://www.debian.org/Bugs/server-control), but I seem to be missing or overlooking the interface to modify the detailed description. Thanks in advance. Regards -- Bhaskar -- GT.M - Rock solid. Lightning fast. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: I want to delete an ITP
i catch the point
i have no need to modify the source package name .. it can be
'libsockets++'
the builded package name can be 'libsockets++2' (due to debian-policy
8.1) and 'libsockets++-dev'
in future releases... builded: 'libsockets++3' and 'libsockets++-dev'
i have a question: in the next releases of debian there may be 2
versions of my package ('libsockets++2' and 'libsockets++3')???
?
i suppose the answer is positive if i ask a sponsor to upload the
packages, but if question is some sponsor uploaded my package today
(libsockets++2) and there is an update tomorrow (libsockets++3) and
there is another package depending on (libsockets++2)???
would be better idea if I created the package libsockets++' and
'libsockets++-dev'???
thanks...
El jue, 13-08-2009 a las 00:09 +0200, Sandro Tosi escribió:
2009/8/12 Leinier Cruz Salfran salfra...@ipigto.rimed.cu:
I changed the source package name.
I readed [1] .. Correct me if I'm wrong, please
well, if you ask, you should wait for a reply...
I can send a mail to 'cont...@bugs.debian.org' with body:
reassign 539568 libsockets++2 2.3.5
no, 'wnpp' metapackage is the correct one to use for ITPs
retitle 539568 libsockets++2: C++ sockets class library
is this the same title as before (hint: ITP: libsockets++ -- C++
sockets wrapper library) with only the package name changed? (hint:
no) - retitle it correctly.
Moreover, why adding the '2' to the package name? (I didn't follow the
thread that lead to this package rename).
one question mark is more the enough to express a question.
Thanks
welcome
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
RFS: libsockets++
Dear mentors, I am looking for a sponsor for my package libsockets++. * Package name: libsockets++ Version : 2.3.5-1 Upstream Author : Anders Hedstrom gry...@alhem.net * URL : http://www.alhem.net/Sockets/ * License : GPL-2 Section : libs It builds these binary packages: libsockets++-dev - C++ sockets class library - development files libsockets++2 - C++ sockets class library The package appears to be lintian clean. The upload would fix these bugs: 539568 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libsockets++ - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libsockets++/libsockets++_2.3.5-1.dsc I would be glad if someone uploaded this package for me. Kind regards Leinier Cruz Salfran signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: RFS: trend
Good work! On Thu, Aug 13, 2009 at 12:31 AM, Yuri D'Eliawav...@users.sf.net wrote: qemubuilder looked promising for testing all the archs at once, but failed to work for me (bug #441043). Bummer. Apparently qemu 0.11 will be much better in terms of arch support, so you might consider re-trying that later when it enters sid/experimental. For instance, lintian only reported warnings in the man page which I didn't notice before, so I fixed them directly in the original source package with a new release instead of bloating the package with patch managers. Excellent. There are no security threats that the package can expose directly. This is a simple, non-setuid program. There are no configuration files with permission issues. No files are ever created directly. No network connections are established. Ok. Did you try fuzzing the inputs to the program? I did read already most of documentation links you sent me. After reading again the debian policy I've switched the priority or the original package from optional to extra. I also switched the versioning scheme of the upstream source to mayor.minor (I previously just had a date). Excellent. The only unclear task was about uploading the package to mentors.debian.org. Why building a binary package is required if only the source is used? To ensure that the package can build, generally people wouldn't bother otherwise. I didn't assign any package tags in debian/control. Debtags are added once the package enters the archive: http://debtags.alioth.debian.org/edit.html Anyone can modify debtags for any package and the modifications are approved by the debtags moderator before being added to the Packages files. One more thing, is there a non-interactive test suite? This would be useful to ensure that it works on all the platforms where it builds. -- 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
RFS: cd-discid
Dear mentors, I am looking for a sponsor for my package cd-discid. * Package name: cd-discid Version : 0.9-2 Upstream Author : Robert Woodcock r...@debian.org * URL : http://lly.org/~rcw/cd-discid/ * License : GPLv2 or Artistic Section : sound It builds these binary packages: cd-discid - CDDB DiscID utility The package appears to be lintian clean. The upload would fix these bugs: 527477 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/cd-discid - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/cd-discid/cd- discid_0.9-2.dsc I would be glad if someone uploaded this package for me. Kind regards -- Timur -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: trend
On Wed, Aug 12, 2009 at 8:37 PM, Yuri D'Elia wav...@users.sf.net wrote: I am looking for a sponsor for my package trend. A review of the source, binary packages and upstream code: The configure/configure-stamp targets don't do anything so they can probably be removed, unless you switch upstream from plain make to autoconf/automake (which I suggest due to the features it gives you). Lots of unnessecary whitespace and comments in debian/rules. debian/rules doesn't handle DEB_BUILD_OPTIONS=noopt or DEB_BUILD_OPTIONS=parallel=N (see debian-policy). debian/examples can be reduced to one line: examples/* The upstream code is LGPLv2+ but the Debian packaging is GPLv3 only, was that intentional? Generally it is recommended to keep the same license as upstream for the Debian packaging. The AUTHORS file doesn't add anything over debian/copyright and README, I suggest not installing it into the .deb. IIRC debian policy recommends compiling with -Wall, but trend is not compiled that way. When I add -Wall and -Wextra I get these warnings from gcc (not sure why trend.cc warnings are produced for color.cc): make[1]: Entering directory `/tmp/buildd/trend-1.0/src' g++ -MD -Wall -O2 -Wextra -c -o trend.o trend.cc g++ -MD -Wall -O2 -Wextra -c -o color.o color.cc trend.cc:344: warning: unused parameter 'fd' trend.cc: In function 'void drawFillZero(const Graph)': trend.cc:799: warning: suggest parentheses around comparison in operand of != trend.cc: In function 'void drawFillDelta(const Graph)': trend.cc:867: warning: suggest parentheses around comparison in operand of != trend.cc: At global scope: trend.cc:1718: warning: unused parameter 'x' trend.cc:1718: warning: unused parameter 'y' trend.cc:1829: warning: unused parameter 'state' trend.cc: In function 'bool parseNums(std::vectordouble, std::allocatordouble , char*)': trend.cc:1920: warning: suggest parentheses around assignment used as truth value trend.cc: In function 'bool parseStrings(std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , char*)': trend.cc:1930: warning: suggest parentheses around assignment used as truth value trend.cc: In function 'void setLimits()': trend.cc:1419: warning: 'hi' may be used uninitialized in this function trend.cc: In function 'void drawFillDelta(const Graph)': trend.cc:844: warning: 'l2' may be used uninitialized in this function trend.cc:843: warning: 'l1' may be used uninitialized in this function trend.cc: In function 'void drawFillZero(const Graph)': trend.cc:782: warning: 'last' may be used uninitialized in this function trend.cc: In function 'size_t drawLine(const Graph, double)': trend.cc:714: warning: 'pos' may be used uninitialized in this function trend.cc: In function 'bool readFNum(FILE*, double)': trend.cc:326: warning: 'st' may be used uninitialized in this function g++ -o trend trend.o color.o -lglut -lGL -lGLU make[1]: Leaving directory `/tmp/buildd/trend-1.0/src' Complaints from lintian --info --display-info --display-experimental --pedantic --show-overrides --checksums --color auto: P: trend: no-upstream-changelog I: trend: hyphen-used-as-minus-sign usr/share/man/man1/trend.1.gz:74 You might want to consider using the new debhelper 7 features since you depend on that version (unfortunately the video for Joey Hess' DebConf9 talk isn't yet available): https://penta.debconf.org/dc9_schedule/events/418.en.html It is fun to do cat /dev/urandom | trend, you might want to include that in the examples in the manual page. -- 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
