On Thu, Jul 07, 2011 at 04:39:58PM +0200, Peter T. Breuer wrote: > "Also sprach Debian Bug Tracking System:" > > On Wed, Jul 06, 2011 at 07:16:55PM +0200, Peter T. Breuer wrote: > > > Package: openni-dev > > > Version: 1.1.0.41-5+maverick1 > > > > There is no such package in Debian, nor in Ubuntu, come to that, so we > > cannot help with your bug report. As far as I can tell, you must have > > got this package from > > https://launchpad.net/~v-launchpad-jochen-sprickerhof-de/+archive/pcl. > > Sure, no problem. It's part of stuff necessary to compile PCL (point > cloud library, sf.net), which is kind-of a VTK-ey thingamajig for 3-D > model manipulation. DEB packages are supplied on the point cloud > library site, but in the end I recompiled them to avoid the problem I > reported .. there's a wrongheaded -msse2 in the default compile options.
I agree with the substance of your report, certainly. If they make serious use of SSE2, perhaps they should be making use of the hwcap mechanism to ship multiple variants of libraries with different optimisation settings, the way things like OpenSSL do. That way it could work on older systems without sacrificing performance on newer ones. > I wrongly assumed that the bug report would go to the registered > maintainer, not to debian. Apologies! Time to file a bug report > against "reportbug"? It has the maintainer's email address available > in the dpkg status file, after all! It's certainly not the first time I've seen this type of problem. I don't see an existing bug report on the subject, but I might just be missing it. > > That user has no public address registered on Launchpad, so I can't even > > That's extremely helpful, but I KNOW where I got the thing from .. > www.pointcloud.org. The package maintainer is > > Maintainer: Jochen Sprickerhof <launch...@jochen.sprickerhof.de> > > I'll cc him on reply. Indeed, I'll repost the bug report to him, if I > find I have a clean copy somewhere. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;bug=632874 is a clean copy (and has an mbox link if you prefer). > > > Distributor ID: Ubuntu (nah .. I 'graded to debian immediately after > > > install years ago .. dunno where it gets it from). > > > Description: Ubuntu 8.04.1 (nahhhhh - where IS this from!). > > > > I deduce that your sidegrade to Debian was incomplete. At the very > > least, you appear to have: > > > > * Ubuntu's version of the base-files package > > Oh, great! A CLUE! You are really really being very helpful. That's > most un-maintainer-like in my experience! Are you sure this isn't your > first encounter with the luser population? > > ii base-files 6.4 Debian base system miscellaneous files > > Nope. > > > > * Either an old Ubuntu version of the reportbug package, or perhaps > > stale configuration in .reportbugrc > > ii reportbug 5.1.1 reports bugs in the Debian distribution > > Nope. How odd. I expect that 'lsb_release -av' will print roughly what was in your report, and it might be easier to track down the problem from that (a smaller target to strace, if nothing else). It's still unclear why reportbug is using lsb_release to get system information in the first place; you appear to be hitting ubuntu_infofunc in /usr/share/pyshared/reportbug/debianbts.py, but I don't know why that would be if you don't have Ubuntu's reportbug and there isn't something like 'bts ubuntu' in ~/.reportbugrc or /etc/reportbug.conf. > Not worth worrying about. I bequeath you the complete list, just to > demonstrate: [...] Indeed, I don't believe any of these are capable of confusing reportbug in this way. That does rather suggest that it's partly due to a configuration file somewhere, whether that be in ~ or /etc. Hopefully the above will help in case you have the time and inclination to pursue it ... > > 'uptodate' lines, it will list the packages that differ from the > > archives in your current /etc/apt/sources.list. > > Wonderful theory, but not so in practice. That's a shame. I did try it locally before saying that, although I tend to be pretty religious about maintaining my system as much in the package management system as possible (and obviously have an advantage there as a developer!). > Only the other week I recall making a big start on the output from > "cruft" in order to try and recover from the last time my dpkg status > file vanished due to some power surge about 6 months ago. And it's 40C > here .. and I made big progress, removing about 400M of "cruft" file > by file. Now if somebody would like to tell me why my /usr is STILL > nearly 4GB, and looks legit, I would love to know. It seems as though > any reasonable package nowadays takes 300MB! Packages emanating from Sun/Oracle do tend to be pretty hefty. I haven't used cruft in a long time, but find deborphan to be helpful. Regards, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
