On Sat, Apr 21, 2001 at 06:47:08PM -0400, Itai Zukerman wrote:
> On Sat, 21 Apr 2001 13:36:36 -0700, Sean 'Shaleh' Perry <[EMAIL PROTECTED]>
> wrote:
> > I was recently mailed about lintian failing on UPX compressed binaries in
> > packages.
>
> How does it fail? (In what way do the compressed b
On Sun, Apr 22, 2001 at 12:11:12AM +0300, Richard Braakman wrote:
>
> Rules files rarely call strip directly, and when they do it
> is uncomfortable to add the long options for stripping those
> two sections. It doesn't makes much difference whether 99%
> or 100% of the binaries strip them, becau
On Sat, 21 Apr 2001 13:36:36 -0700, Sean 'Shaleh' Perry <[EMAIL PROTECTED]>
wrote:
> I was recently mailed about lintian failing on UPX compressed binaries in
> packages.
How does it fail? (In what way do the compressed binaries not conform
to policy?)
-itai
Hi,
this is the remains of a discussion taken on debian-devel (Packages vs
Sources), which did not provoke any reply in the last couple of days.
I plan to develop this into a policy proposal, but as I feel the issue might
be contentious, I think it wouldn't be bad to announce it so discussion can
On Sat, Apr 21, 2001 at 04:44:24PM -0400, Bob Hilliard wrote:
> gcc apparently creates sections `.note' and `.comment' when compiling
> binaries. Running either `strip' or the -s option to install does not
> remove these redundant sections. Lintian issues a warning
> `binary-has-unneeded-sec
On Sat, Apr 21, 2001 at 04:44:24PM -0400, Bob Hilliard wrote:
> gcc apparently creates sections `.note' and `.comment' when compiling
> binaries. Running either `strip' or the -s option to install does not
> remove these redundant sections. Lintian issues a warning
> `binary-has-unneeded-sec
On Sat, Apr 21, 2001 at 01:36:36PM -0700, Sean 'Shaleh' Perry wrote:
>
> So, I informed the fellow that if he wants UPX to pass lintian he has to get
> policy to support it first. The consensus on #debian-devel was that
> compressed
> binaries is a bad idea for Debian to ship and that this shoul
gcc apparently creates sections `.note' and `.comment' when compiling
binaries. Running either `strip' or the -s option to install does not
remove these redundant sections. Lintian issues a warning
`binary-has-unneeded-section' when it detects these sections in a
binary.
I don't think
Bob Hilliard <[EMAIL PROTECTED]> wrote:
> The following makefile snippet is suggested to implement this
>recommendation:
>
>ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
>CFLAGS += -g
>endif
>ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
I was recently mailed about lintian failing on UPX compressed binaries in
packages. UPX is a way to compress binaries on x86 machines in such a way that
they are self decompressing -- i.e. it is transparent to the user.
However, compressed binaries have their own issues. The binary will not be
s
Policy version 3.5.3.0, Section 11.1. Binaries, includes the
following recommendation:
If the environment variable `DEB_BUILD_OPTIONS'
contains the string `debug', compile the software with debugging
information (usually this involves adding the `-g' flag t
On Sat, 21 Apr 2001 at 15:01:37 -0500, Chris Waters wrote:
> I'll double check with the standards documents I have around here to
> see if I find any other problems, but for now, I think this is
> probably ok.
Thanks, I appreciate the sanity-check.
Cheers,
--
Colin Watson
On Sat, Apr 21, 2001 at 08:38:07PM +0100, Colin Watson wrote:
> I'm confused about what you're referring to. I'm not talking about the
> .so feature, which is fine and will stay - I'm talking about putting
> several names in the .SH NAME section without also putting them in the
> filesystem as sym
On Sat, 21 Apr 2001 at 13:45:09 -0500, Chris Waters wrote:
> On Sat, Apr 21, 2001 at 06:57:48PM +0100, Colin Watson wrote:
> > A recent discussion on debian-mentors brought it to my attention
> > that packages frequently rely on an implementation detail of man:
> > that it holds a database of whati
On Sat, Apr 21, 2001 at 06:57:48PM +0100, Colin Watson wrote:
> A recent discussion on debian-mentors brought it to my attention
> that packages frequently rely on an implementation detail of man:
> that it holds a database of whatis entries and happens to be able to
> find pages even if the file
A recent discussion on debian-mentors brought it to my attention that
packages frequently rely on an implementation detail of man: that it
holds a database of whatis entries and happens to be able to find pages
even if the file containing the man page has a different name. For
instance, look at xli
16 matches
Mail list logo
