Bug#825237: RFS: mrpt/1:1.4.0-1 [ITA] [RC]
Hi Sean, Paul, >> I think you should use a suffix other than -dbg because people expect >> -dbg to be detached debugging symbols. > > I would go with either -dbg (slight preference) or -debug. Thanks for the advice! Since -dbg is expected to carry a different content by so many people, I would go for "-debug" as an alternative. > The most recent version of libwxgtk*-dbg in Debian is just detached > debugging symbols i.e. the same as the *-dbgsym. The "-b extra runtime > checks" package has been dropped: see #655251. Thanks Sean, I went through the thread and that encouraged me to switch the "debug version libraries" to something different than "-dbg". By the way, my mentor finally answered and will *try* to upload the latest 1.4.0 version, but he is so swamped that it would be a good idea anyway to find someone else who is willing to help / mentoring this package... > It was already updated to sid :( Could you confirm that it succeeds for > you on a 32-bit machine, please? I don't have access to a 64-bit > machine for testing. I successfully cross-compiled it in sid for i386 from amd64, and today I installed a 32-bit VirtualBox image just to be sure, and the CMake error you mentioned does not show up there neither!! I can't explain it... it would be great if you could try just updating sid and rebuilding and it worked, but if keeps failing, the only difference I see in our configurations is the usage of ccache. Best, Jose Luis
Bug#825237: RFS: mrpt/1:1.4.0-1 [ITA] [RC]
On Fri, May 27, 2016 at 4:15 PM, Sean Whitton wrote: > I think you should use a suffix other than -dbg because people expect > -dbg to be detached debugging symbols. I would go with either -dbg (slight preference) or -debug. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#825237: RFS: mrpt/1:1.4.0-1 [ITA] [RC]
* Sean Whitton , 2016-05-27, 17:15: I think you should use a suffix other than -dbg because people expect -dbg to be detached debugging symbols. You could write to debian-de...@lists.debian.org and/or debian-ment...@lists.debian.org to see if anyone is aware of a precedent; Hey, we are already on -mentors. :-) I don't expect -dbg to be only detached debugging symbols. Actually, with the advent of automatic debug packages, symbols-only -dbg packages are (hopefully) going to become extinct. The most prominent precedent is probably pythonX.Y-dbg. -- Jakub Wilk
Bug#825237: RFS: mrpt/1:1.4.0-1 [ITA] [RC]
Hello, On Thu, May 26, 2016 at 11:55:07PM +0200, Jose Luis Blanco wrote: > > Based on your description, it sounds like the -g packages might be > > useful for someone. The only question is what you should call the > > binary package. Are you saying that those packages already exist in > > Debian for wxWidgets? What is the binary package name in that case? > > Here is the only example I know in Debian (may be other packages like this?) > > https://packages.debian.org/wheezy/libwxgtk2.8-dbg > And the rest of wx*-dbg packages: > https://packages.debian.org/source/wheezy/wxwidgets2.8 The most recent version of libwxgtk*-dbg in Debian is just detached debugging symbols i.e. the same as the *-dbgsym. The "-b extra runtime checks" package has been dropped: see #655251. I think you should use a suffix other than -dbg because people expect -dbg to be detached debugging symbols. You could write to debian-de...@lists.debian.org and/or debian-ment...@lists.debian.org to see if anyone is aware of a precedent; I'm afraid I don't know of one. > I tried to replicate your error under Debian sid amd64 without luck. I > tried with and without ccache (I noticed you use it and thought it may > be the problem). > > So, you want to give it another try after updating everything to "sid" > it would be great, but I can't offer any fix because it seems to build > clean in my local env, and in many other automated build farms > (travis-ci, Ubuntu PPA, etc.) It was already updated to sid :( Could you confirm that it succeeds for you on a 32-bit machine, please? I don't have access to a 64-bit machine for testing. -- Sean Whitton signature.asc Description: PGP signature
Bug#825237: RFS: mrpt/1:1.4.0-1 [ITA] [RC]
Hi Sean, >> Now that those -dbg packages have been renamed to -dbgsym, do you >> think it may be a good idea to generate again those debug packages? >> I would be really thankful for any advice regarding "good practices" >> in this sense... > > Based on your description, it sounds like the -g packages might be > useful for someone. The only question is what you should call the > binary package. Are you saying that those packages already exist in > Debian for wxWidgets? What is the binary package name in that case? Here is the only example I know in Debian (may be other packages like this?) https://packages.debian.org/wheezy/libwxgtk2.8-dbg And the rest of wx*-dbg packages: https://packages.debian.org/source/wheezy/wxwidgets2.8 > I think that the QA team's debcheck program checks for that, not > Lintian. > > Due to a lack of clarity about the difference between the extra and > optional priorities,[1] and the need to file a bug to actually change > it, most of us are ignoring the particular error you have quoted for > packages that already exist (though of course you should make sure new > packages are fully compliant with the policy). Ok, thanks for the advice! >> > Unfortunately, it fails to build on my 32-bit machine; log attached. >> >> wow, that's really unexpected! It seems there is an error in one CMake >> module: >> >> CMake Error at /usr/share/cmake-3.5/Modules/TestBigEndian.cmake:104 >> (message): >> TEST_BIG_ENDIAN found no result! >> >> Will investigate if it's a real problem with cmake or with my scripts. > > I can try the build again when you think you've fixed it; just let me know. I tried to replicate your error under Debian sid amd64 without luck. I tried with and without ccache (I noticed you use it and thought it may be the problem). So, you want to give it another try after updating everything to "sid" it would be great, but I can't offer any fix because it seems to build clean in my local env, and in many other automated build farms (travis-ci, Ubuntu PPA, etc.) Best, Jose Luis
Bug#825237: RFS: mrpt/1:1.4.0-1 [ITA] [RC]
control: owner -1 ! Dear Jose, On Wed, May 25, 2016 at 12:06:50PM +0200, Jose Luis Blanco wrote: > Thank you very much for the review, indeed any help is appreciated! No problem! > > You should drop the libmrpt-dbg package, since we now have automatic > > *-dbgsym binary package generation. > > Done (upstream). I wasn't aware of this change. > In the past, I provided -dbg packages with a totally different meaning > (very similar to those provided by wxWidgets, if you are familiar with > them): they were another version of all libraries, compiled with -g > and other flags that enabled many extra run-time checks. I dropped > those packages because of the (what I understood) was the preferred > meaning of -dbg packages in Debian. > > Now that those -dbg packages have been renamed to -dbgsym, do you > think it may be a good idea to generate again those debug packages? > I would be really thankful for any advice regarding "good practices" > in this sense... Based on your description, it sounds like the -g packages might be useful for someone. The only question is what you should call the binary package. Are you saying that those packages already exist in Debian for wxWidgets? What is the binary package name in that case? > > Could you explain why you changed the package priority optional->extra? > > I did it back in January and can't find an extended description in the > commit log about *why* I did it, but it was probably because of some > Lintian error/warning regarding this part of the policy (2.5 > Priorities): > > Packages must not depend on packages with lower priority values > (excluding build-time dependencies). In order to ensure this, the > priorities of one or more packages may need to be adjusted. > > I have switched it back to "optional" upstream and will try to > re-regenerate all packages and run Lintian to see if that was the > reason. I think that the QA team's debcheck program checks for that, not Lintian. Due to a lack of clarity about the difference between the extra and optional priorities,[1] and the need to file a bug to actually change it, most of us are ignoring the particular error you have quoted for packages that already exist (though of course you should make sure new packages are fully compliant with the policy). > > Unfortunately, it fails to build on my 32-bit machine; log attached. > > wow, that's really unexpected! It seems there is an error in one CMake module: > > CMake Error at /usr/share/cmake-3.5/Modules/TestBigEndian.cmake:104 > (message): > TEST_BIG_ENDIAN found no result! > > Will investigate if it's a real problem with cmake or with my scripts. I can try the build again when you think you've fixed it; just let me know. [1] a recent thread on debian-devel I can't seem to find right now -- Sean Whitton signature.asc Description: PGP signature
Bug#825237: RFS: mrpt/1:1.4.0-1 [ITA] [RC]
Dear Sean, Thank you very much for the review, indeed any help is appreciated! > You should drop the libmrpt-dbg package, since we now have automatic > *-dbgsym binary package generation. Done (upstream). I wasn't aware of this change. In the past, I provided -dbg packages with a totally different meaning (very similar to those provided by wxWidgets, if you are familiar with them): they were another version of all libraries, compiled with -g and other flags that enabled many extra run-time checks. I dropped those packages because of the (what I understood) was the preferred meaning of -dbg packages in Debian. Now that those -dbg packages have been renamed to -dbgsym, do you think it may be a good idea to generate again those debug packages? I would be really thankful for any advice regarding "good practices" in this sense... > Why have you marked this RFS as "[ITA]"? It means "intent to adopt" but > you're already the maintainer. Right, it was a mistake. > Could you explain why you changed the package priority optional->extra? I did it back in January and can't find an extended description in the commit log about *why* I did it, but it was probably because of some Lintian error/warning regarding this part of the policy (2.5 Priorities): Packages must not depend on packages with lower priority values (excluding build-time dependencies). In order to ensure this, the priorities of one or more packages may need to be adjusted. I have switched it back to "optional" upstream and will try to re-regenerate all packages and run Lintian to see if that was the reason. > Unfortunately, it fails to build on my 32-bit machine; log attached. wow, that's really unexpected! It seems there is an error in one CMake module: CMake Error at /usr/share/cmake-3.5/Modules/TestBigEndian.cmake:104 (message): TEST_BIG_ENDIAN found no result! Will investigate if it's a real problem with cmake or with my scripts. Again, thank you very much for the help. Best, Jose Luis
Bug#825237: RFS: mrpt/1:1.4.0-1 [ITA] [RC]
Package: sponsorship-requests Severity: important Dear mentors, Since 2008, I have had one very kind mentor taking care of my package "mrpt" (home page [1]), but I have not had any news from him for more than ~1 month, so I thought it would be a good idea to find out if someone else would be willing to help with this big package. The latest version, uploaded some weeks ago to mentors.d.n, solves some RC bugs and Lintian errors and warnings [2]. MRPT comprises many command-line and GUI applications, plus C++ libraries, for many tasks related to mobile robotics and computer vision, from didactic applications for teaching up to modules for real-time navigation of autonomous robots / vehicles. The project was started in 2005, have been downloaded more than ~80k times and is cited in ~300 scientific papers [3]. Next follows the standard RFS data: * Package name: mrpt Version : 1:1.4.0-1 Upstream Author : Jose-Luis Blanco * URL : http://www.mrpt.org/ * License : BSD Section : science It builds those binary packages: libmrpt-base1.4 - Mobile Robot Programming Toolkit - base library libmrpt-dbg - Mobile Robot Programming Toolkit - Debug libraries libmrpt-detectors1.4 - Mobile Robot Programming Toolkit - detectors library libmrpt-dev - Mobile Robot Programming Toolkit - Development headers libmrpt-gui1.4 - Mobile Robot Programming Toolkit - gui library libmrpt-hmtslam1.4 - Mobile Robot Programming Toolkit - hmtslam library libmrpt-hwdrivers1.4 - Mobile Robot Programming Toolkit - hwdrivers library libmrpt-kinematics1.4 - Mobile Robot Programming Toolkit - kinematics library libmrpt-maps1.4 - Mobile Robot Programming Toolkit - maps library libmrpt-nav1.4 - Mobile Robot Programming Toolkit - nav library libmrpt-obs1.4 - Mobile Robot Programming Toolkit - obs library libmrpt-opengl1.4 - Mobile Robot Programming Toolkit - opengl library libmrpt-slam1.4 - Mobile Robot Programming Toolkit - slam library libmrpt-tfest1.4 - Mobile Robot Programming Toolkit - tfest library libmrpt-topography1.4 - Mobile Robot Programming Toolkit - topography library libmrpt-vision1.4 - Mobile Robot Programming Toolkit - vision library mrpt-apps - Mobile Robot Programming Toolkit - Console and GUI applications mrpt-common - Mobile Robot Programming Toolkit - Example datasets and files mrpt-doc - Mobile Robot Programming Toolkit - Documentation and examples To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mrpt Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mrpt/mrpt_1.4.0-1.dsc Best, Jose Luis [1] http://www.mrpt.org/ [2] https://packages.qa.debian.org/m/mrpt.html [3] https://scholar.google.es/scholar?q=(MRPT+AND+ROBOT)+OR+%22Mobile+Robot+Programming+Toolkit%22 -- ___ Jose Luis Blanco-Claraco CITE-IV 1.05 Universidad de Almería, Departamento de Ingeniería 04120 Almería (Spain) http://www.ual.es/~jlblanco/ ___
