[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Attachment: signature.asc
Description: PGP signature


Reply to: