-----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@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" <a...@adam-barratt.org.uk> To: jlma...@gmail.com, 653...@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----- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
