Re: Allow package bug scripts to unconditionally stop reportbug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, lets be a bit sarcastic (not unrealistic, still happened). Am Fr den 8. Jan 2010 um 8:45 schrieb Frank Lin PIAT: > This is odd... it sounds like > "You wanted to file a bug, well... don't!" > > How can a package script know what a user want to report? On what basis > is it going to prevent the user from reporting a bug? I can think of > lots of bad reasons to use such feature, but I can't think of any > sensible one. > Some bad reasons: One more reason: * The maintainer makes no errors and don't wanted to be disturbed by a bug report. I don't want to tell a concrete package name to not start a flame. Ask by PM if you interested in. Regards Klaus - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEVAwUBS0byn5+OKpjRpO3lAQqxmggAjwVtXgIaZ6A+okr8ZDikqIB2K0gyCmKo UUvCYk2eU1flT4LYgd53L/zuqebL2Wq8P0Ev046CU3RBvSgA3UwHSdheQR6uASgW WfTk2sqTbs9y/sQTu53LaGs2RudaefI3H070FENc0JLn1SAgReZAZmQ+3mFlxvy+ a1DhkO7VUtFxQDC4Y90ozONc59M2ix1BPRZ2pAxNXrJuh5drWMWcavscx5e7LseD vnqKRwzXumyIiovaHsoA5HWc4+4DotW6g5dHfReYvBzap0JQUmPOR/mWxKNdmgDV wHtf2y82ZQQ3KaN5jQ+w/L1AGmpNpoDKfHx5Jnwf37FLDS8mXLip1Q== =mjgj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Apparent portmap to rpcbind transition?
On Thu, Jan 07, 2010 at 07:17:16PM +0100, Alexander Wirt wrote: > Ehm, the reason was a bug. nfs-common was broken, if connecting to localhost > it was only trying ::1, but without a fallback on 127.0.0.1. > There wasn't any indication in the package that this breakage was on purpose. > I guess it was just bad testing. > The NMU is in delayed/1 and should hit unstable in a few hours. Sure, but my main point is that looking at the package meant I noticed that it's now added rpcbind as an alternative portmapper. That's something which we should be doing over the entire distribution rather than in a few packages. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564231: ITP: libosl -- library for Shogi playing programs
Package: wnpp Severity: wishlist Owner: Daigo Moriwaki * Package name: libosl Version : 0.2.0 Upstream Author : Team GPS * URL : http://gps.tanaka.ecc.u-tokyo.ac.jp/gpsshogi/pukiwiki.php * License : BSD Programming Lang: C++ Description : library for Shogi playing programs OpenShogiLib (OSL) provides following features of Shogi playing programs, especially for Shogi programming study. Shogi is a Japanese two-player board game like Chess. 1. Board: reading/writing records, generating legal moves etc. 2. Evaluation function: piece values and a lot of features 3. Hash table: hashing boards etc. 4. Checkmate search: concurrent df-pn+ etc. 5. Search framework: full-depth search, realization probability etc. 6. Move category: mate, illegal moves etc. 7. Opening book 8. Gaming: search time control etc. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
hurd and SA_SIGINFO
Greetings! 1) What is the release candidate status of hurd-i386? Can I ignore FTBFS errors there for now? 2) The sigaction flags are not found anywhere on the porterbox, though they are mentioned in the sigaction man page. Take care, -- Camm Maguirec...@maguirefamily.org == "The earth is but one country, and mankind its citizens." -- Baha'u'llah -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: hurd and SA_SIGINFO
Camm Maguire, le Thu 07 Jan 2010 12:00:11 -0500, a écrit : > 1) What is the release candidate status of hurd-i386? It's not ready yet, surely not for Squeeze anyway. > Can I ignore FTBFS errors there for now? Yes, but when it's easy to fix them, please do. > 2) The sigaction flags are not found anywhere on the porterbox, though > they are mentioned in the sigaction man page. Yes, actually GNU/Hurd provides its own signal information structure (which was coined before sigaction, apparently). I started adding the sigaction interface but hasn't finished yet. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian error on- rpath: Would like an exemption
On Tue, Jan 05, 2010 at 07:58:36PM -0600, Dirk Eddelbuettel wrote: > > littler (aka 'r') is a small wrapper around GNU R that Jeff Horner and I > released in 2006 and have been maintaining since. It is similar to Rscript > (which appeared a little later as part of base R) but implemented differently > -- we query a lot of the environment at build time and encode this. And we > also use an -rpath against R's main dynamic library. As a consequence, we > start faster than either Rscript or R. > > And I was about to make a new upstream release, but now see > > E: littler: binary-or-shlib-defines-rpath ./usr/bin/r $ objdump -p /usr/bin/r |grep RPATH RPATH /usr/lib64/R/lib:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jni:/usr/lib/libfakeroot:/usr/lib64/libfakeroot:/usr/lib32/libfakeroot And you only seem to be using libraries from /lib, /usr/lib and /usr/lib/R/lib. I think lintian is right to complain. Anyway, I think that /usr/lib/R/lib/libR.so really should be in /usr/lib/ and that you shouldn't need an rpath at all. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian error on- rpath: Would like an exemption
Kurt, Thanks for taking the time to follow-up on this. On 8 January 2010 at 22:04, Kurt Roeckx wrote: | On Tue, Jan 05, 2010 at 07:58:36PM -0600, Dirk Eddelbuettel wrote: | > | > littler (aka 'r') is a small wrapper around GNU R that Jeff Horner and I | > released in 2006 and have been maintaining since. It is similar to Rscript | > (which appeared a little later as part of base R) but implemented differently | > -- we query a lot of the environment at build time and encode this. And we | > also use an -rpath against R's main dynamic library. As a consequence, we | > start faster than either Rscript or R. | > | > And I was about to make a new upstream release, but now see | > | > E: littler: binary-or-shlib-defines-rpath ./usr/bin/r | | $ objdump -p /usr/bin/r |grep RPATH | RPATH /usr/lib64/R/lib:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jni:/usr/lib/libfakeroot:/usr/lib64/libfakeroot:/usr/lib32/libfakeroot | | And you only seem to be using libraries from /lib, /usr/lib and /usr/lib/R/lib. | | I think lintian is right to complain. | | Anyway, I think that /usr/lib/R/lib/libR.so really should be in | /usr/lib/ and that you shouldn't need an rpath at all. A few quick comments: i)There are several entries because I (at compile time) deconstruct the LD_LIBRARY_PATH set by /usr/bin/R (a shell script) used to load R from /usr/lib/R/bin/exec/, this uses /usr/lib/R/lib. We could strip every thing but /usr/lib64/R/lib and the Java libs, but why bother ii) /usr/lib/R/lib (or /usr/lib64/R/lib) is needed and will not move, unless someone (you ?) convinces R Core to change it. (Hint: Won't happen). This is how it is, this has been discussed before and you are kindly invited to read up on the old discussions. iii) /usr/bin/r, for which I am 1/2 of upstream, won't change either because this embedding of R is its whole point (vis-a-vis the shellscript /usr/bin/R) My post was a false alert anyway; I had one actual bug with an 'empty' entry and that has been fixed. Cheers, Dirk -- Three out of two people have difficulties with fractions. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564285: ITP: openmolar -- dental practice management software
Package: wnpp Severity: wishlist Owner: David Paleino * Package name: openmolar Version : 0.1.8 Upstream Author : Neil Wallace * URL : https://launchpad.net/openmolar * License : GPL-3+ Programming Lang: Python Description : dental practice management software Well, a long description is yet to come :) -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: This is a digitally signed message part.
