[Pkg-acpi-devel] Bug#653496: Re[02]: Bug#653496: FTBS: Debian 6.0.3 - Security Fix - acpid_2.0.7-1squeeze3

John L. Males jlmales at gmail.com
Thu Dec 29 00:35:17 UTC 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adam,

The issue for the bug report is:

cc1: warnings being treated as errors
libnetlink.c: In function ‘addraw_l’:
libnetlink.c:521: error: comparison between signed and unsigned
integer expressions

I would think a maintainer would know what are the key elements
related to such an issue.  I would suggest you not assume I am
doing things by trial and error.  I have far too much
technical, QA, and systems programming experience to be doing
anything by trial and error.  I think the concise level of
detail and completeness of information would demonstrate
someone doing something by trial and error.  In your response I
cannot see anything to suggest what the likely causes of such a
problem and/or suggested reasons this problem may exist for
what appears to be a purely source code related issue such as
this bug report encountered while still able to compile many
other packages from source other than:

- - "rebuilt the package inside an "amd64 squeeze chroot", and
there were no issues."
- -  Why not "apt-get install build-essential && apt-get
build-dep acpid"? That's the standard and supported way of
ensuring you have the correct packages installed, not repeated
trial and error. 
- - are you suggesting initramfs-tools 0.99~bpo60+1 or
linux-libc-dev 2.6.39-3~bpo60+1 are the cause for the
acpid_2.0.7-1squeeze3 error I encountered
- - Is the "amd64 squeeze chroot" you tried rebuilding the
acpid_2.0.7-1squeeze3 package in an environment that actually
resembles is purely installed Debian 6.0.3?

I would far more interested in what you feel is related to this
bug report that results in the acpid_2.0.7-1squeeze3 source not
building.

- - What is the result of the "dpkg --list" of the 
"amd64 squeeze chroot" system?
- - Did you download the source via the links I provided to try
building acpid_2.0.7-1squeeze3 from source?  You did not state
if you did or not.
- - Have you have provided a complete console session
like I have provided?
- - What differences between your "the "amd64 squeeze chroot" you
tried rebuilding the acpid_2.0.7-1squeeze3" differences can be
compared and root causes suggested?
- - What incorrect packages are installed on my system that you
seem to be suggesting are the cause of the problem?

The fact is you have not listed to the same level of
detail I have for the test you did on the "amd64 squeeze
chroot" system. The fact is fixes and updates should be done on
"the reference" system such I indicated and a "amd64 squeeze
chroot" is not.

Do you actually know what the elements are that would cause
such a compile failure?  I would be interested that the focus
for this issue be about the elements that would be related to
the issue and therefore what is different between my 6.0.3
system and the "amd64 squeeze chroot" system.

I would have concerns if you cannot follow the instructions on
how to recreate this problem based on what I stated.

I did build the 2.6-39 Kernel as there were some important
hardware device support the 2.6.32 Kernel did not have I was
in need of. As an FYI the 2.6.39 Kernel was a disaster and
when I have time and can find a seperate system/laptop hard
drive I will test the 2.6.39 Kernel again and see if I can
find a way to duplicate at will.  Removing of the 2.6.39
Kernel was supposed to be clean, but that is a seperate issue
along with the many hard lockouts the Debian 2.6.39 kernel
had.  I have installed some packages, multimedia related from a
source well known to Debian community and used with trust by
the Debian community.  I suspect these multimedia packages are
not related to the acpid_2.0.7-1squeeze3.

Please do not get me started apt-get, et al.  That is a whole
different discussion and bug reports will follow when I have
time as there are some serious problems with at far too
many .DSC and .DEB packages, not to mention the apt-get data.
Because of the many issues related to the apt-get system/data I
have to fetch and compile files on my own manually at a later
stage of system customization. Right now mostly not other than
mostly security/update fixes.

apt-get has all to often backout changes I have made to my
system and therefore does suit many situations in the real
world. apt-get, and similar, are excellent concepts, but
they have not been thought through in terms of design use
scope/impact. For the current design scope of these tools
they are great, but have serious shortfalls.  I have even
exceeded that scope with something as simple as a apt-get for a
kernel update from the Debian pool, not to mention I have to
take measures due to the assumptions the .DEB packages make.
I will exceed the apt-get scope in a few months such that
apt-get will then become useless as it was with Etch for the
last 3 years.

In essence the reason many use Open Source Software is to have
choice and control over one's system and specific needs.
apt-get, and similar tools other distributions have, simply do
not handle that scope very well or not at all. From my personal
experience these tools tend to make system decisions that break
or remove the customization one has and is supposed to be
allowed to have. I have not had to customize this Debian 6.0.3
much yet as I have only just installed Debian 6.0.3 in the last
few weeks.  My Etch system was and continue work well, all be it
the Etch system is very modified in terms of a mix of Etch,
Lenny, Squeeze packages, but has reached its limits due to the
version of GCC and glibc.

Open Source is abut choice and I choose to uild updates and
security updates from source.  I rebuild from source updates and
security fixes and not just pull the binary.  This is one of
many many examples I have encountered in the past.  In such
cases I have spent alot of time and research finding the cause
of the issue and fixing it.  At this evolution of Debian and
Open Source I should not have to do this.  By not reporting
these issues in the past such problems clearly continue and
clearly people do not want to spend the time reporting and
fighting to have someone think about the issue. This is just
one of many such issues I have already encountered even before
adding in the multimedia packages I did to this 6.0.3 base
install.  I have already had my systems many times in past lock
up, hang, crash, et al when I just pull the pre-built
packages.

When I backtracked what updates were done on the system all of
the system up time and on each boot and shutdown and recompiled
the previous binary updates from source instead the problems
disappeared.  We are talking about problems that would surface
usually a few times a day, sometimes many times to point where
I would not use the software or combinations of software. Since
I started making standard practice to rebuild from source any
updates, new releases, backports, et al I have had a very, very
stable system.

I can also tell you with a number of other packages that
compile, but are in fact not 64 bit safe.  This may not apply
to the acpid source, at least not from what will compile so
far.  The point is I compile from source because there are a
few too many packages built for the amd64 architecture that are
in fact not 64 bit safe.  Again this is not this bug report,
nor am I suggesting acpid has a 64 bit compatibility issue
at source level.

The larger point of view is that there are a number of reasons
I compile from source.

Regards,

John L. Males
Toronto, Ontario
Canada
28 December 2011 19:35


==============================================================
2011-12-28 17:59:33.709175094-0500-EST

28 Dec 17:59:33 ntpdate[591]: ntpdate 4.2.6p2 at 1.2194-o Sun Oct
17 13:35:14 UTC 2010 (1)

28 Dec 17:59:48 ntpdate[596]: step time server 66.96.30.35
offset 0.016656 sec

Linux 2.6.32-5-amd64 #1 SMP Mon Oct 3 03:59:20 UTC 2011

Modified Debian GNU/Linux 6.0.3 (squeeze)
Planning, Upgrade, Modifications, Bug Reporting Work In
Progress from Highly modified Debian 4.x Etch


Message replied to:

Date: Wed, 28 Dec 2011 22:34:41 +0000
From: "Adam D. Barratt" <adam at adam-barratt.org.uk>
To: jlmales at gmail.com, 653496 at bugs.debian.org
Subject: Re: Bug#653496: FTBS: Debian 6.0.3 - Security Fix -
acpid_2.0.7-1squeeze3


> tag 653496 + unreproducible moreinfo
> thanks
> 
> On Wed, 2011-12-28 at 17:01 -0500, John L. Males wrote:
> > The acpid_2.0.7-1squeeze3 source package failed to build
> > for the Debian 6.0.3 amd64 release target and therefore the
> > security fix binary Debian Security issued for Squeeze was
> > not created from the posted acpid_2.0.7-1squeeze3 source
> > package.
> 
> This report is quite hard to follow in places.  fwiw, I've
> just rebuilt the package inside an amd64 squeeze chroot, and
> there were no issues.
> 
> > 1) Install Debian 6.0.3 using the official amd64 DVD
> > images, do not run any updates or security updates after
> > the base 6.0.3 install. This should be a development based
> > install with a DE of your choice.
> > 
> > 2) Download the acpid_2.0.7-1squeeze3 source:
> 
> > 3) Run the following commands from the directory where the
> > source of step (2) was downloaded to:
> [...]
> > 4) If the newly installed system issues messages for build
> > tools, compiler, or package dependencies install what is
> > required only from the base Debian 6.0.3 DVDs.
> 
> Why not "apt-get install build-essential && apt-get build-dep
> acpid"? That's the standard and supported way of ensuring you
> have the correct packages installed, not repeated trial and
> error.
> 
> You also missed "install and possibly part remove packages
> from backports" from the above.  The attachment you included
> lists, amongst others:
> 
> ii  initramfs-tools                   0.99~bpo60
> +1                      tools for generating an initramfs pi
> linux-libc-dev                    2.6.39-3~bpo60
> +1                  Linux support headers for userspace
> development
> 
> There is no way your environment is purely installed from
> Debian 6.0.3 DVDs if it contains the above packages.  Have
> you tried rebuilding the package in an environment that
> actually resembles that you suggest others should build in
> order to validate your report?
> 
> Regards,
> 
> Adam
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk77tcUACgkQ+V/XUtB6aBCTHgCcD3crjjt9tpCLaJqd5fhCbiFN
x6EAoJd2q8qczkRCIovJItR2oYsfBUbg
=DkJ0
-----END PGP SIGNATURE-----





More information about the Pkg-acpi-devel mailing list