Bug#782654: Bug#838416: Bug#782654: Bug#838416: ITP: bazel -- Fast and correct automated build system by Google
I spent a while working on it off and on, but there is a decent amount of tweaking and other packaging work needed to get policy-compliant bazel packages. (E.G: There are quite a few binary JAR files shipped in the upstream tarball that don't necessarily match the versions in Debian). I just didn't have the spare time, especially now that I have a kid, to sink into one package. (Also, FWIW, if you want to _create_ policy-compliant packages using bazel, there is a lot more work than just getting a policy-compliant bazel package, because bazel needs to understand debian multiarch compilers, standard build flags, etc). Cheers, Kyle Moffett On Fri, May 18, 2018 at 4:56 AM, Chris Lamb <la...@debian.org> wrote: > Chris Lamb wrote: > >> Kyle Moffett wrote: >> >> > > Well, if you could package Bazel… :) >> > >> > Unfortunately, there's more work than just "packaging" Bazel. Just to >> > package Bazel, the open issues are: >> >> […] >> >> Oh! My smiley was meant to represent how packaging Bazel is not a simple >> task and thus imply you were delaying for no obvious reason! Apologies >> that did not come across via email. >> >> > But... even with that, Bazel cannot be used to _build_ a Debian >> > package, because it does not create Debian-policy-compliant binaries >> >> Oh, can you elaborate on this? >> >> > [...] >> >> Thanks so much for clarifying the other issues; very useful for myself >> and for others coming across this bug report. >> >> If your opinionn should, for example, Roughtime try and rewrite the build >> system in the meantime/long-term? > > Gentle ping on this? > > > Best wishes, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org / chris-lamb.co.uk >`-
Bug#782654: Bug#838416: ITP: bazel -- Fast and correct automated build system by Google
On Mon, Oct 3, 2016 at 9:29 AM, Chris Lamb <la...@debian.org> wrote: > > Also, I would be pretty keen on seeing roughtime packaged > > in Debian, so don't hesitate to ping me in you need a > > co-maintainer. > > Well, if you could package Bazel… :) Unfortunately, there's more work than just "packaging" Bazel. Just to package Bazel, the open issues are: (1) Getting Bazel's dependencies packaged in Debian, with acceptable versions. (2) Fixing the Bazel build process to use Debian JAR files, rather than pre-built versions shipped with Bazel. (3) Fixing the Bazel build process to comply with Debian policy around static linking and self-extracting binaries. But... even with that, Bazel cannot be used to _build_ a Debian package, because it does not create Debian-policy-compliant binaries, and it does not support all the Debian cross-compiler flags. In order to fix that, a bunch more integration work is needed, including rewriting the Bazel "architecture specs" to use Debian architecture names or tuples instead, and to fix the built-in rules to properly support fully-dynamic linking and library installation paths. So, yeah, it's a lot of work, and I haven't really had time to make much progress. Cheers, Kyle Moffett
Bug#782654: ITP: bazel -- Fast and correct automated build system by Google
X-Debbugs-Cc: debian-de...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Kyle Moffett k...@moffetthome.net
* Package name: bazel
Version : 0~pre20150410-cc4463-1 (No upstream release yet)
Upstream Author : Google
* URL : http://bazel.io/
* License : Apache License 2.0
Programming Lang: Java and C++
Description : Fast and correct automated build system by Google
{Fast, Correct} - Choose two
Bazel is a build tool that builds code quickly and reliably. It is used to
build the majority of Google's software, and thus it has been designed to
handle build problems present in Google's development environment, including:
* A massive, shared code repository, in which all software is built from
source. Bazel has been built for speed, using both caching and parallelism
to achieve this. Bazel is critical to Google's ability to continue to scale
its software development practices as the company grows.
* An emphasis on automated testing and releases. Bazel has been built for
correctness and reproducibility, meaning that a build performed on a
continuous build machine or in a release pipeline will generate
bitwise-identical outputs to those generated on a developer's machine.
* Language and platform diversity. Bazel's architecture is general enough to
support many different programming languages within Google, and can be used
to build both client and server software targeting multiple architectures
from the same underlying codebase.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782654: ITP: bazel -- Fast and correct automated build system by Google
On Wed, Apr 15, 2015 at 10:33 AM, Kyle Moffett k...@moffetthome.net wrote: * Package name: bazel Version : 0~pre20150410-cc4463-1 (No upstream release yet) Upstream Author : Google * URL : http://bazel.io/ * License : Apache License 2.0 Programming Lang: Java and C++ Description : Fast and correct automated build system by Google From discussions with upstream, some of Bazel's design may need to be tweaked to interoperate well with distro requirements (like Debian). They currently pack everything up into a single self-extracting archive, with most libraries statically linked, which violates Debian Policy, but they are definitely interested in making things compatible with distro packaging: https://groups.google.com/forum/#!topic/bazel-dev/YIp70JgOksI I have some patches and WIP packaging prepared here: https://github.com/kmoffett/bazel Cheers, Kyle Moffett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704964: grub-pc: GRUB-2 does not handle /dev/disk/by-path/*
Package: grub-pc Version: 1.99-27 Severity: important Tags: upstream As far as I can tell, GRUB-2 doesn't support any kind of symlinks to /dev/sd*, such as /dev/disk/by-path/* Specifically, consider the following setup: * GRUB Root: /boot/pci-:07:00.0-sas-0x12210300-lun-0 (AKA: /dev/disk/by-path/pci-:07:00.0-sas-0x1221-lun-0-part1) * Boot partition: /boot (AKA: /dev/disk/by-path/pci-:07:00.0-sas-0x1221-lun-0-part2) * Symlinks: /boot/pci-:07:00.0-sas-0x12210300-lun-0/boot = . /boot/pci-:07:00.0-sas-0x12210300-lun-0/grub = . * Device mapping ($GRUB_ROOT/device.map): (hd0) /dev/disk/by-path/pci-:07:00.0-sas-0x1221-lun-0 (hd1) /dev/disk/by-path/pci-:07:00.0-sas-0x12210100-lun-0 (hd2) /dev/disk/by-path/pci-:07:00.0-sas-0x12210200-lun-0 (hd3) /dev/disk/by-path/pci-:07:00.0-sas-0x12210300-lun-0 * Auto-generated GRUB-2 config file ($GRUB_ROOT/grub.cfg), whose actual contents are irrelevant, but which loads GRUB modules from the first partition and kernels/initrds from the second partition. * Valid device symlinks from udev: /dev/disk/by-path/pci-:07:00.0-sas-0x12210300-lun-0 = ../../sde /dev/disk/by-path/pci-:07:00.0-sas-0x12210300-lun-0-part1 = ../../sde1 /dev/disk/by-path/pci-:07:00.0-sas-0x12210300-lun-0-part2 = ../../sde2 /dev/disk/by-path/pci-:07:00.0-sas-0x12210300-lun-0-part3 = ../../sde3 /dev/disk/by-path/pci-:07:00.0-sas-0x12210300-lun-0-part4 = ../../sde4 Now, with that set up, I run: grub-install --no-floppy \ --root-directory=/boot/pci-:07:00.0-sas-0x12210300-lun-0 \ /dev/disk/by-path/pci-:07:00.0-sas-0x12210300-lun-0 And it dies with an error: /usr/sbin/grub-probe: error: cannot find a GRUB drive for /dev/disk/by-path/pci-:07:00.0-sas-0x12210300-lun-0. Check your device.map. If I edit the device.map file and replace it with /dev/sde (which it is a symlink to, by the way), then run: grub-install --no-floppy \ --root-directory=/boot/pci-:07:00.0-sas-0x12210300-lun-0 \ /dev/disk/by-path/pci-:07:00.0-sas-0x12210300-lun-0 /dev/sde Then it works flawlessly. Unfortunately, this is not useful because those device names change on boot, depending on whether or not I have USB devices attached to the system. Even worse, with my configs: grub-probe -m /boot/pci-\:07\:00.0-sas-0x12210300-lun-0 \ -t drive '(hd3)' Segmentation fault Cheers, Kyle Moffett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704964: Fwd: grub-pc: GRUB-2 does not handle /dev/disk/by-path/*
On Mon, Apr 8, 2013 at 2:24 AM, Kyle Moffett k...@moffetthome.net wrote: If I edit the device.map file and replace it with /dev/sde (which it is a symlink to, by the way), then run: grub-install --no-floppy \ --root-directory=/boot/pci-:07:00.0-sas-0x12210300-lun-0 \ /dev/sde Actually, I don't even have to edit device.map. I just have to give it the non-symlink path on the command-line and it works fine. I guess grub just needs an extra realpath() in there somewhere? Cheers, Kyle Moffett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650318: gcc-4.6: Please apply PR target/50906 patch for powerpcspe
Source: gcc-4.6 Version: 4.6.2-4 Severity: wishlist Tags: patch upstream GCC PR target/50906 causes miscompiled code on powerpcspe when building with -Os. The patch has been tested thoroughly on e500 systems and resolves the issue correctly there, but it unfortunately still needs additional verification that it does not break regular powerpc systems. If possible, it would be very convenient for the Debian package to conditionally apply the pr50906 patch for the powerpcspe package build. Otherwise, it will hopefully be merged into the 4.6 SVN branch soon, after Alan Modra has performed the additional necessary validation, and it should end up in Debian that way. Thanks for your time. Cheers, Kyle Moffett -- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647456: gcc-defaults: Make GCC 4.6 the default on the powerpcspe architecture
Source: gcc-defaults Version: 1.108 Severity: wishlist User: debian-powerpc...@breakpoint.cc Usertags: powerpcspe Please add the unofficial Debian port powerpcspe to the list of GCC-4.6 architectures in the gcc-defaults package. Cheers, Kyle Moffett -- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647288: libffi: Simplify PowerPC assembly and avoid CPU-specific string instructions
Source: libffi
Version: 3.0.10-3
Severity: wishlist
Tags: upstream patch
After upgrading to a new version of GNU ld for PowerPC e500, I started
seeing build errors on e500 systems again. It turns out that the
PowerPC string instructions are unimplemented on PPC440 and most other
embedded cores, and also cause unexpectedly high instruction latencies
and pipeline stalls even on POWER processors.
This historically worked in the past because the unknown string opcodes
are trapped on PPC440 and similar systems and emulated in the kernel,
though that is obviously very inefficient and undesirable.
Since the struct-copy code doesn't really need to be implemented in
assembly, this patch ensures that there is always enough space to store
both r3 and r4 and then uses C to extract the 1-8 byte small struct
into the user-provided memory.
Even with all the big new comments, it's still removes 11 lines of code,
and the ASM is much simpler and easier to understand now.
Please consider applying.
Cheers,
Kyle Moffett
--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/
-- System Information:
Debian Release: 6.0.2
APT prefers stable
APT policy: (1010, 'stable'), (700, 'testing'), (600, 'unstable'), (500,
'stable-updates'), (500, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
diff -ru libffi-3.0.10/src/powerpc/ffi.c libffi-3.0.10.new/src/powerpc/ffi.c
--- libffi-3.0.10/src/powerpc/ffi.c 2011-11-01 11:22:38.0 -0400
+++ libffi-3.0.10.new/src/powerpc/ffi.c 2011-11-01 11:22:27.0 -0400
@@ -46,11 +46,6 @@
FLAG_RETURNS_64BITS = 1 (31-28),
FLAG_RETURNS_128BITS = 1 (31-27), /* cr6 */
- FLAG_SYSV_SMST_R4 = 1 (31-26), /* use r4 for FFI_SYSV 8 byte
- structs. */
- FLAG_SYSV_SMST_R3 = 1 (31-25), /* use r3 for FFI_SYSV 4 byte
- structs. */
- /* Bits (31-24) through (31-19) store shift value for SMST */
FLAG_ARG_NEEDS_COPY = 1 (31- 7),
#ifndef __NO_FPRS__
@@ -688,37 +683,22 @@
break;
case FFI_TYPE_STRUCT:
- if (cif-abi == FFI_SYSV)
- {
- /* The final SYSV ABI says that structures smaller or equal 8 bytes
- are returned in r3/r4. The FFI_GCC_SYSV ABI instead returns them
- in memory. */
+ /*
+ * The final SYSV ABI says that structures smaller or equal 8 bytes
+ * are returned in r3/r4. The FFI_GCC_SYSV ABI instead returns them
+ * in memory.
+ *
+ * NOTE: The assembly code can safely assume that it just needs to
+ * store both r3 and r4 into a 8-byte word-aligned buffer, as
+ * we allocate a temporary buffer in ffi_call() if this flag is
+ * set.
+ */
+ if (cif-abi == FFI_SYSV size = 8)
+ flags |= FLAG_RETURNS_SMST;
- /* Treat structs with size = 8 bytes. */
- if (size = 8)
- {
- flags |= FLAG_RETURNS_SMST;
- /* These structs are returned in r3. We pack the type and the
- precalculated shift value (needed in the sysv.S) into flags.
- The same applies for the structs returned in r3/r4. */
- if (size = 4)
- {
- flags |= FLAG_SYSV_SMST_R3;
- flags |= 8 * (4 - size) 8;
- break;
- }
- /* These structs are returned in r3 and r4. See above. */
- if (size = 8)
- {
- flags |= FLAG_SYSV_SMST_R3 | FLAG_SYSV_SMST_R4;
- flags |= 8 * (8 - size) 8;
- break;
- }
- }
- }
- intarg_count++;
- flags |= FLAG_RETVAL_REFERENCE;
- /* Fall through. */
+ intarg_count++;
+ flags |= FLAG_RETVAL_REFERENCE;
+ /* Fall through. */
case FFI_TYPE_VOID:
flags |= FLAG_RETURNS_NOTHING;
break;
@@ -932,21 +912,30 @@
void
ffi_call(ffi_cif *cif, void (*fn)(void), void *rvalue, void **avalue)
{
+ /*
+ * The final SYSV ABI says that structures smaller or equal 8 bytes
+ * are returned in r3/r4. The FFI_GCC_SYSV ABI instead returns them
+ * in memory.
+ *
+ * Just to keep things simple for the assembly code, we will always
+ * bounce-buffer struct return values less than or equal to 8 bytes.
+ * This allows the ASM to handle SYSV small structures by directly
+ * writing r3 and r4 to memory without worrying about struct size.
+ */
+ unsigned int smst_buffer[2];
extended_cif ecif;
ecif.cif = cif;
ecif.avalue = avalue;
- /* If the return value is a struct and we don't have a return */
- /* value address then we need to make one */
-
- if ((rvalue == NULL) (cif-rtype-type == FFI_TYPE_STRUCT))
-{
- ecif.rvalue = alloca(cif-rtype-size);
-}
- else
-ecif.rvalue = rvalue;
-
+ /* Ensure that we have a valid struct return value */
+ ecif.rvalue = rvalue;
+ if (cif-rtype-type == FFI_TYPE_STRUCT) {
+ if (cif-rtype-size = 8)
+ ecif.rvalue = smst_buffer;
+ else if (!rvalue)
+ ecif.rvalue = alloca(cif-rtype-size);
+ }
switch (cif-abi)
{
@@ -968,6 +957,10
Bug#647324: gcj-4.6: Wrong MULTIARCH_DIRNAME on powerpcspe (is powerpc-linux-gnu)
Source: gcj-4.6
Version: 4.6.2-1
Severity: wishlist
Tags: patch
Building gcj-4.6=4.6.2-1 (using gcc-4.6-source=4.6.2-2) is failing due
to an invalid value of MULTIARCH_DIRNAME on powerpcspe.
I don't have the foggiest idea why GCC itself builds and installs
correctly, but the Java build fails with this error:
dh_movefiles: debian/tmp/usr/lib/powerpc-linux-gnuspe/gcj-4.6-12/libjvm.so
not found (supposed to put it in libgcj12)
dh_movefiles:
debian/tmp/usr/lib/powerpc-linux-gnuspe/gcj-4.6-12/libjavamath.so not found
(supposed to put it in libgcj12)
Inspecting that directory, I see this:
$ ls -l debian/tmp/usr/lib
total 20
drwxr-xr-x 3 kmoffett kmoffett 4096 Nov 1 14:11 gcc
drwxr-xr-x 3 kmoffett kmoffett 4096 Nov 1 14:13 jvm
drwxr-xr-x 3 kmoffett kmoffett 4096 Nov 1 14:13 jvm-exports
drwxr-xr-x 3 kmoffett kmoffett 4096 Nov 1 14:13 powerpc-linux-gnu
drwxr-xr-x 3 kmoffett kmoffett 4096 Nov 1 14:13 powerpc-linux-gnuspe
The powerpc-linux-gnu is obviously wrong, and it contains the files
that are missing from powerpc-linux-gnuspe:
$ ls -l debian/tmp/usr/lib/powerpc-linux-gnu
total 135200
drwxr-xr-x 2 kmoffett kmoffett 4096 Nov 1 14:13 gcj-4.6-12
-rwxr-xr-x 1 kmoffett kmoffett 1637 Nov 1 14:12 libgcj_bc.so
lrwxrwxrwx 1 kmoffett kmoffett18 Nov 1 14:12 libgcj_bc.so.1 -
libgcj_bc.so.1.0.0
-rwxr-xr-x 1 kmoffett kmoffett 1637 Nov 1 14:12 libgcj_bc.so.1.0.0
lrwxrwxrwx 1 kmoffett kmoffett16 Nov 1 14:12 libgcj.so -
libgcj.so.12.0.0
lrwxrwxrwx 1 kmoffett kmoffett16 Nov 1 14:12 libgcj.so.12 -
libgcj.so.12.0.0
-rwxr-xr-x 1 kmoffett kmoffett 127976277 Nov 1 14:12 libgcj.so.12.0.0
lrwxrwxrwx 1 kmoffett kmoffett22 Nov 1 14:12 libgcj-tools.so -
libgcj-tools.so.12.0.0
lrwxrwxrwx 1 kmoffett kmoffett22 Nov 1 14:12 libgcj-tools.so.12 -
libgcj-tools.so.12.0.0
-rwxr-xr-x 1 kmoffett kmoffett 10421495 Nov 1 14:12 libgcj-tools.so.12.0.0
lrwxrwxrwx 1 kmoffett kmoffett16 Nov 1 14:12 libgij.so -
libgij.so.12.0.0
lrwxrwxrwx 1 kmoffett kmoffett16 Nov 1 14:12 libgij.so.12 -
libgij.so.12.0.0
-rwxr-xr-x 1 kmoffett kmoffett 19447 Nov 1 14:12 libgij.so.12.0.0
-rw-r--r-- 1 kmoffett kmoffett 1437 Nov 1 14:12 logging.properties
drwxr-xr-x 2 kmoffett kmoffett 4096 Nov 1 14:12 security
I can disassemble those files with objdump and they clearly contain
valid e500v2 opcode sequences, so the build process seems to be fine
except for the multiarch directory.
I tried to hack up a patch (attached) that looks correct to me, but I
have very little experience with this area of GCC and I haven't tested
it yet. I would really appreciate a second set of eyes.
I'm going to apply it on top of the gcc-4.6 sources (4.6.2-2) and
rebuild GCC and GIJ to see if the problem goes away; I'll let you know
when I have some results.
Cheers,
Kyle Moffett
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500,
'stable-updates'), (500, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--- gcj-4.6-4.6.2/src/gcc/config.gcc.orig 2011-11-01 15:02:10.318248946 -0400
+++ gcj-4.6-4.6.2/src/gcc/config.gcc 2011-11-01 15:03:42.149247963 -0400
@@ -2188,7 +2188,8 @@
powerpc*-*-linux*altivec*)
tm_file=${tm_file} rs6000/linuxaltivec.h ;;
powerpc*-*-linux*spe*)
- tm_file=${tm_file} rs6000/linuxspe.h rs6000/e500.h ;;
+ tm_file=${tm_file} rs6000/linuxspe.h rs6000/e500.h
+ tmake_file=${tmake_file} rs6000/t-linux-spe ;;
powerpc*-*-linux*paired*)
tm_file=${tm_file} rs6000/750cl.h ;;
esac
--- gcj-4.6-4.6.2/src/gcc/config/rs6000/t-linux-spe.orig 1969-12-31 19:00:00.0 -0500
+++ gcj-4.6-4.6.2/src/gcc/config/rs6000/t-linux-spe 2011-11-01 15:04:06.994247615 -0400
@@ -0,0 +1 @@
+MULTIARCH_DIRNAME = powerpc-linux-gnuspe
Bug#645940: libonig: Allow testsuite to be disabled for cross-compile/nocheck
Source: libonig Version: 5.9.1-1 Severity: wishlist Tags: patch User: crossbu...@debian.org Usertags: cross The libonig package tries to run make check even when cross-compiling, resulting in test-suite failures. The attached patch disables the test-suite when cross-compiling or when the DEB_BUILD_OPTIONS=nocheck variable is set (as per Debian Policy). Please consider applying, thanks! Cheers, Kyle Moffett -- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/ -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'stable-updates'), (500, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash diff -ruN libonig-5.9.1/debian/rules libonig-5.9.1.new/debian/rules --- libonig-5.9.1/debian/rules 2011-10-19 16:03:21.0 -0400 +++ libonig-5.9.1.new/debian/rules 2011-10-19 16:03:36.0 -0400 @@ -15,6 +15,14 @@ CFLAGS += -O2 -fno-strict-aliasing endif +MAKE_check = +$(MAKE) check +ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) +MAKE_check = @echo Testsuite disabled due to cross-compilation +endif +ifneq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS))) +MAKE_check = @echo Testsuite disabled due to 'nocheck' in DEB_BUILD_OPTIONS +endif + configure: debian/stamp-configure debian/stamp-configure: dh_testdir @@ -46,7 +54,7 @@ debian/stamp-check: debian/stamp-build dh_testdir - $(MAKE) check + $(MAKE_check) @touch $@
Bug#640457: [openssl] some Verisign certificates fail to verify
reassign 640457 konqueror thanks On Sun, Oct 16, 2011 at 11:54, Maximilian Engelhardt m...@daemonizer.de wrote: On Friday 14 October 2011 07:28:00 Kyle Moffett wrote: So chain-0 can be verified by chain-1 and chain-1 can be verified by the system installed CAs. The problem is that VeriSign_Class_3_Public_Primary_Certification_Authority_-_G5.crt got updated in ca-certificates 20110421. And the last certificated sent by the server (chain-2) is the old version of this same certificate. $ openssl x509 -noout -subject -issuer -in /etc/ssl/certs/VeriSign_Class_3_Public_Primary_Certification_Authority_- _G5.pem subject= /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 issuer= /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 So it seems like openssl first uses the certificate that's send from the server, but then fails to verify it (as it can't find an appropriate root certificate). Instead it should ignore the sent certificate and use the one that is installed on the local system and thus trusted as root certificate. This behaviour is especially a problem for me since konqueror uses openssl to verify the certificates and there are quite some sites that deliver the old certificate in the chain. Also note that gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt -p 443 signin.ebay.de does verify the certificate just fine. This PHP bug-report seems basically identical: https://bugs.php.net/bug.php?id=49419 Based on my understanding of TLS and from that PHP bug-report... I'm actually pretty sure that this is not a bug. According to the TLS standard (RFC2246): certificate_list This is a sequence (chain) of X.509v3 certificates. The sender's certificate must come first in the list. Each following certificate must directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate which specifies the root certificate authority may optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. The certificates passed in the protocol must be a strict sequence. Any server sending out-of-order or bogus certificates in the chain is not complying with the TLS protocol requirements, and cannot reasonably expect to validate correctly. It's entirely possible that some implementations are much more lenient than others, but the standard itself seems very obvious as to the requirement. As far as I can tell, OpenSSL implements a very safe default for SSL certificate chain construction and requires the application to implement a more advanced model if desired. This is basically a server configuration problem, and at best this should be a feature request against konqueror to better handle broken server configurations. Please note that GnuTLS has historically been missing a number of the stricter checks that OpenSSL provides by default, and that those tend to get added to GnuTLS when their absence is identified. For example, OpenSSL has always checked certificate validity times by default, but prior to CVE-2009-1417, the GnuTLS library relied upon the application to perform those checks (and most did not). Let me know if you want me to reassign this bug to konqueror or close it as wontfix. Hello Kyle, thanks for your detailed explanation. So this seems to be a Konqueror bug, perhaps even an upstream KDE bug. On the other hand this might also be a ca-certificates bug, since it doesn't ship the old Verisign root certificate anymore, but without that certificate openssl will fail to verify any chain that uses it (and it seems to be wildly used). No, ca-certificates still ships the old Verisign root certificate. What changed is that the website you were accessing upgraded from their old certificate (issued with the old Verisign root) to a new one (issued by the new Verisign root), but they did not fix their certificate chain file to match. I'm not really sure if it's a Konqueror or a ca-certificates bug, so feel free to reassign it to whatever you think fits best, perhaps Konqueror, as you did suggest in your last mail. I have reassigned this bug to konqueror. I'm wondering how many other programs that use openssl experience the same problem. This is an extremely common error among website operators, as most of the TLS implementations don't actually have very good diagnostics for identifying and fixing the issue. I have had this exact same issue myself with SMTP TLS, and the fix involved a configuration change on the server. In this case, it is very
Bug#645121: libselinux: Packaging cleanup (Fixes cross-compile support)
Source: libselinux Version: 2.1.0-1 Followup-For: Bug #645121 Whoops! I attached the wrong version of the cleanup patch, sorry! The attached incremental diff is also necessary for cross-compiling. Cheers, Kyle Moffett -- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/ -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'stable-updates'), (500, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash diff -ruN libselinux-2.1.0.old/debian/patches/fix-cross-compile.patch libselinux-2.1.0/debian/patches/fix-cross-compile.patch --- libselinux-2.1.0.old/debian/patches/fix-cross-compile.patch 1969-12-31 19:00:00.0 -0500 +++ libselinux-2.1.0/debian/patches/fix-cross-compile.patch 2011-10-13 17:35:37.0 -0400 @@ -0,0 +1,21 @@ +Description: Fix cross-compilation + Don't forcibly -I/usr/include during the build process, the compiler + already knows how to look in that directory. + . +Author: Kyle Moffett kyle.d.moff...@boeing.com + +--- +Forwarded: no +Last-Update: 2011-10-13 + +--- libselinux-2.1.0.orig/src/Makefile libselinux-2.1.0/src/Makefile +@@ -47,7 +47,7 @@ + OBJS= $(patsubst %.c,%.o,$(SRCS)) + LOBJS= $(patsubst %.c,%.lo,$(SRCS)) + CFLAGS ?= -Werror -Wall -W -Wundef -Wshadow -Wmissing-noreturn -Wmissing-format-attribute +-override CFLAGS += -I../include -I$(INCLUDEDIR) -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 $(EMFLAGS) ++override CFLAGS += -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 $(EMFLAGS) + RANLIB=ranlib + + ARCH := $(patsubst i%86,i386,$(shell uname -m)) diff -ruN libselinux-2.1.0.old/debian/patches/series libselinux-2.1.0/debian/patches/series --- libselinux-2.1.0.old/debian/patches/series 2011-10-13 17:36:38.0 -0400 +++ libselinux-2.1.0/debian/patches/series 2011-10-13 17:36:58.0 -0400 @@ -1,3 +1,4 @@ fix-makefile-bugs.patch -p1 fix-manpages.patch -p1 hide-library-destructors.patch -p1 +fix-cross-compile.patch -p1 diff -ruN libselinux-2.1.0.old/debian/rules libselinux-2.1.0/debian/rules --- libselinux-2.1.0.old/debian/rules 2011-10-13 14:47:03.0 -0400 +++ libselinux-2.1.0/debian/rules 2011-10-13 17:46:59.0 -0400 @@ -33,7 +33,7 @@ ## Skip python/ruby packages during stage1 build ifeq ($(DEB_STAGE),stage1) -DH_OPTIONS += -Npython-selinux -Nruby-selinux +DH_OPTIONS += -Npython-selinux -Nruby-selinux -Nlibselinux-ruby1.8 endif ## Set up some variables to be passed to the upstream Makefile
Bug#645274: findutils: Cross-compile fails with gnulib errors (upstream bug 27299)
Source: findutils Version: 4.4.2-1 Severity: wishlist Tags: upstream User: crossbu...@debian.org Usertags: cross When cross-compiling the findutils debian package, the build fails with the obscure gnulib errors documented here: http://savannah.gnu.org/bugs/?27299 If I download the findutils 4.5.10-1 source package from experimental, it works correctly. Cheers, Kyle Moffett -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'stable-updates'), (500, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645278: gpm: Cross-compile fails due to use of native compiler
Source: gpm Version: 1.20.4-4 Severity: wishlist Tags: patch The upstream gpm seems to need a very old version of autoconf which does not properly support cross-compiling. As a result, ./configure only tries gcc unless manually overridden with $CC. The attached patch supplies the necessary CC override to allow a cross-compile to actually work. Please review and apply. Cheers, Kyle Moffett -- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/ -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'stable-updates'), (500, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash diff -ru gpm-1.20.4/debian/rules gpm-1.20.4.new/debian/rules --- gpm-1.20.4/debian/rules 2011-10-13 19:23:40.0 -0400 +++ gpm-1.20.4.new/debian/rules 2011-10-13 19:24:53.0 -0400 @@ -22,11 +22,12 @@ ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE)) confflags += --build $(DEB_HOST_GNU_TYPE) - host_cc = gcc + CC = gcc else confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE) - host_cc = $(DEB_HOST_GNU_TYPE)-gcc + CC = $(DEB_HOST_GNU_TYPE)-gcc endif +export CC configure: patch configure.in autoconf @@ -44,7 +45,7 @@ dh_testdir # for gpm_has_mouse_control - $(MAKE) -C contrib/control CC=$(host_cc) + $(MAKE) -C contrib/control CC=$(CC) $(MAKE) clean: unpatch clean-unpatched
Bug#640457: [openssl] some Verisign certificates fail to verify
So chain-0 can be verified by chain-1 and chain-1 can be verified by the system installed CAs. The problem is that VeriSign_Class_3_Public_Primary_Certification_Authority_-_G5.crt got updated in ca-certificates 20110421. And the last certificated sent by the server (chain-2) is the old version of this same certificate. $ openssl x509 -noout -subject -issuer -in /etc/ssl/certs/VeriSign_Class_3_Public_Primary_Certification_Authority_- _G5.pem subject= /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 issuer= /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 So it seems like openssl first uses the certificate that's send from the server, but then fails to verify it (as it can't find an appropriate root certificate). Instead it should ignore the sent certificate and use the one that is installed on the local system and thus trusted as root certificate. This behaviour is especially a problem for me since konqueror uses openssl to verify the certificates and there are quite some sites that deliver the old certificate in the chain. Also note that gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt -p 443 signin.ebay.de does verify the certificate just fine. This PHP bug-report seems basically identical: https://bugs.php.net/bug.php?id=49419 Based on my understanding of TLS and from that PHP bug-report... I'm actually pretty sure that this is not a bug. According to the TLS standard (RFC2246): certificate_list This is a sequence (chain) of X.509v3 certificates. The sender's certificate must come first in the list. Each following certificate must directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate which specifies the root certificate authority may optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. The certificates passed in the protocol must be a strict sequence. Any server sending out-of-order or bogus certificates in the chain is not complying with the TLS protocol requirements, and cannot reasonably expect to validate correctly. It's entirely possible that some implementations are much more lenient than others, but the standard itself seems very obvious as to the requirement. As far as I can tell, OpenSSL implements a very safe default for SSL certificate chain construction and requires the application to implement a more advanced model if desired. This is basically a server configuration problem, and at best this should be a feature request against konqueror to better handle broken server configurations. Please note that GnuTLS has historically been missing a number of the stricter checks that OpenSSL provides by default, and that those tend to get added to GnuTLS when their absence is identified. For example, OpenSSL has always checked certificate validity times by default, but prior to CVE-2009-1417, the GnuTLS library relied upon the application to perform those checks (and most did not). Let me know if you want me to reassign this bug to konqueror or close it as wontfix. Cheers, Kyle Moffett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645121: libselinux: Support bootstrap DEB_STAGE=stage1 build
Source: libselinux
Version: 2.1.0-1
Severity: wishlist
User: crossbu...@debian.org
Usertags: cross
There are a relatively large number of packages which depend and/or
build-depend on libselinux, including dpkg, coreutils, etc.
Unfortunately, when trying to bootstrap a new architecture, this means
that libselinux is one of a small set of packages which needs to be
cross-compiled for the target when very little is available.
The problems come from the python and ruby bindings, which are not
easily disabled in the Debian packaging, yet are undesired when trying
to do such an architecture bootstrap.
A lot of other packages (especially those using debhelper) can be
patched with a few ./configure or make arguments and fiddling with the
DH_OPTIONS variable to add -Nlibfoo-python -Nlibfoo-ruby, but
unfortunately the libselinux packaging does something terribly
complicated in debian/common/pkgvars.mk with these gems:
DEB_PACKAGES := $(shell perl -e '
\
$$/=;
\
while(){
\
$$p=$$1 if m/^Package:\s*(\S+)/;
\
die duplicate package $$p if $$seen{$$p};
\
$$seen{$$p}++; print $$p if $$p;
\
}' debian/control )
DEB_INDEP_PACKAGES := $(shell perl -e '
\
$$/=;
\
while(){
\
$$p=$$1 if m/^Package:\s*(\S+)/;
\
die duplicate package $$p if $$seen{$$p};
\
$$seen{$$p}++;
\
$$a=$$1 if m/^Architecture:\s*(\S+)/m;
\
next unless ($$a eq all);
\
print $$p if $$p;
\
}' debian/control )
DEB_ARCH_PACKAGES := $(shell perl -e '
\
$$/=;
\
while(){
\
$$p=$$1 if m/^Package:\s*(\S+)/;
\
die duplicate package $$p if $$seen{$$p};
\
$$seen{$$p}++;
\
$$c=;
\
if (/^Architecture:\s*(.*?)\s*$$/sm) {
\
@a = split /\s+/, $$1 };
\
for my $$b (@a) {
\
next unless ($$b eq $(DEB_HOST_ARCH) ||
\
$$b eq any);
\
$$c=$$p;
\
}
\
print $$c if $$c;
\
}' debian/control )
As a tangentially related question, would it be reasonably practical to
convert libselinux over to a more-conventional debhelper-based build?
If not, please consider adding a conditional based on the $DEB_STAGE
environment variable; if it is set to stage1 the python and ruby
bindings should be disabled to allow all the other packages that depend
on libselinux to be bootstrapped.
Cheers,
Kyle Moffett
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500,
'stable-updates'), (500, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645003: libppl-swi: Disable SWI-Prolog support for stage1 architecture bootstrap
Source: ppl Version: 0.11.2-4 Severity: wishlist Tags: patch The most time-consuming part of bootstrapping a new Debian architecture is cross-compiling all of the initial Essential: yes packages and the dependencies of build-essential. Since ppl is now a dependency of GCC, its dependencies are now also a part of that process. Since the libppl-swi is unnecessary for the bootstrap, please consider applying the following package to allow libppl to omit the SWI-Prolog dependency and build for stage1 builds. I tested this with a cross-compile for the powerpcspe architecture: $ sudo apt-get build-dep ppl=0.11.2-4 $ apt-get source ppl=0.11.2-4 $ patch -d ppl-0.11.2 -p1 ppl-stage1-support.patch $ cd ppl-0.11.2 $ DEB_STAGE=stage1 dpkg-buildpackage -apowerpcspe -b -us -uc Additionally, a native build without DEB_STAGE set also still works. Thanks! Cheers, Kyle Moffett -- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/ -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'stable-updates'), (500, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash diff -ru ppl-0.11.2/debian/rules ppl-0.11.2.new/debian/rules --- ppl-0.11.2/debian/rules 2011-07-10 14:00:23.0 -0400 +++ ppl-0.11.2.new/debian/rules 2011-10-11 12:33:06.0 -0400 @@ -29,8 +29,16 @@ # FOR AUTOCONF 2.52 AND NEWER ONLY confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE) -# only build the C,C++,SWI-Prolog interfaces -confflags += --enable-interfaces=c,cxx,swi_prolog --disable-ppl_lpsol --disable-ppl_lcdd +confflags += --disable-ppl_lpsol --disable-ppl_lcdd + +## Disable the SWI-Prolog interface during architecture bootstrap +ifeq ($(DEB_STAGE),stage1) +confflags += --enable-interfaces=c,cxx +DH_OPTIONS += -Nlibppl-swi +export DH_OPTIONS +else +confflags += --enable-interfaces=c,cxx,swi_prolog +endif ifneq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS))) with_check := disabled by DEB_BUILD_OPTIONS.
Bug#645018: gcc-4.6: build error on REVERSE_CROSS (gengtype is wrong arch)
Source: gcc-4.6 Version: 4.6.1-15 Severity: wishlist Tags: patch User: crossbu...@debian.org Usertags: cross When building in REVERSE_CROSS mode (IE: when trying to build a native compiler for another architecture with an existing cross-compiler, the build fails with the following error: $ apt-get source gcc-4.6=4.6.1-15 $ ( cd gcc-4.6-4.6.1 dpkg-buildpackage -apowerpcspe -b -us -uc ) [...] dh_strip -pgcc-4.6-plugin-dev powerpc-linux-gnuspe-strip: Unable to recognise the format of the input file `debian/gcc-4.6-plugin-dev/usr/lib/gcc/powerpc-linux-gnuspe/4.6/gengtype' dh_strip: powerpc-linux-gnuspe-strip --remove-section=.comment --remove-section=.note debian/gcc-4.6-plugin-dev/usr/lib/gcc/powerpc-linux-gnuspe/4.6/gengtype returned exit code 1 make[1]: *** [stamps/08-binary-stamp-gcc-plugindev] Error 29 make[1]: Leaving directory `/srv/stuff/toolchain/CROSS/gcc-4.6/gcc-4.6-4.6.1' make: *** [binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 A brief inspection of the gengtype program shows that it is in fact a binary built for the build system: $ file debian/gcc-4.6-plugin-dev/usr/lib/gcc/powerpc-linux-gnuspe/4.6/gengtype debian/gcc-4.6-plugin-dev/usr/lib/gcc/powerpc-linux-gnuspe/4.6/gengtype: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xfcaf9384cfcf05212c599e6334d7de5bd062c5de, not stripped As far as I can tell, the gcc-plugin support is not supported when building in REVERSE_CROSS mode and should be disabled. Please review and apply the attached patch. Unfortunately, the build still does not complete due to a different error, one which I will be submitting as an additional followup bug. Cheers, Kyle Moffett -- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/ -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'stable-updates'), (500, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash diff -ru gcc-4.6-4.6.1/debian/rules.defs gcc-4.6-4.6.1.new/debian/rules.defs --- gcc-4.6-4.6.1/debian/rules.defs 2011-10-11 14:55:54.0 -0400 +++ gcc-4.6-4.6.1.new/debian/rules.defs 2011-10-11 15:00:43.0 -0400 @@ -827,7 +827,11 @@ endif # plugins +ifeq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE)) with_plugins := yes +else +with_plugins := disabled when cross-compiling +endif endif # ifndef DEB_STAGE
Bug#645021: gcc-4.6: build error on REVERSE_CROSS (files in 4.6.1 dir instead of 4.6)
Source: gcc-4.6 Version: 4.6.1-15 Severity: wishlist When building in REVERSE_CROSS mode (IE: when trying to build a native compiler for another architecture with an existing cross-compiler, the build fails with the following error: $ apt-get gcc-4.6=4.6.1-15 $ ( cd gcc-4.6-4.6.1 dpkg-buildpackage -apowerpcspe -b -us -uc ) [...] dh_movefiles: debian/tmp/usr/lib/gcc/powerpc-linux-gnuspe/4.6/libgcov.a not found (supposed to put it in gcc-4.6) It looks like it is being put in the wrong directory: $ find . -name '*libgcov*' ./gcc-4.6-4.6.1/debian/tmp/usr/lib/gcc/powerpc-linux-gnuspe/4.6.1/libgcov.a ./gcc-4.6-4.6.1/build/powerpc-linux-gnuspe/libgcc/libgcov.a ./gcc-4.6-4.6.1/build/gcc/libgcov.a There seem to have been some similar bugs regarding recent changes to the gcc -print-file-name command, EG: #643891, #644849 Unfortunately I'm not having any luck figuring out what I need to fix to make this build. Any help would be much appreciated. Cheers, Kyle Moffett -- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/ -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'stable-updates'), (500, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644764: FTBFS: asm/errno.h: No such file or directory (due to multiarch)
Source: gcc-4.6 Version: 4.6.1-13 Severity: serious Justification: fails to build from source (but built successfully in the past) When trying to rebuild gcc-4.6 natively from source, I get build failures of the following variety: asm/errno.h: No such file or directory In particular, it seems that recent linux-libc-dev packages have moved the architecture-specific header files from the path /usr/include/asm to /usr/include/x86_64-linux-gnu/asm. In particular, I have linux-libc-dev 3.0.0-3 installed locally. The existing gcc on the system finds files in that search path, but when building libgcc it seems that the temporary built xgcc does not. You can some one example failed command below. Cheers, Kyle Moffett Failed command: /srv/stuff/toolchain/STAGE2/GCC/gcc-4.6-4.6.1/build/./gcc/xgcc \ -B/srv/stuff/toolchain/STAGE2/GCC/gcc-4.6-4.6.1/build/./gcc/ \ -B/usr/x86_64-linux-gnu/bin/ -B/usr/x86_64-linux-gnu/lib/ \ -isystem /usr/x86_64-linux-gnu/include\ -isystem /usr/x86_64-linux-gnu/sys-include\ -g -O2 -m32 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings \ -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes \ -Wold-style-definition -isystem ./include -fPIC -g \ -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED \ -fno-stack-protector -I. -I. -I../../.././gcc \ -I../../../../src/libgcc \ -I../../../../src/libgcc/.\ -I../../../../src/libgcc/../gcc \ -I../../../../src/libgcc/../include \ -I../../../../src/libgcc/config/libbid\ -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS \ -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 \ -c ../../../../src/libgcc/../gcc/libgcc2.c\ -fvisibility=hidden -DHIDE_EXPORTS Error output: In file included from /usr/include/bits/errno.h:25:0, from /usr/include/errno.h:36, from ../../../../src/libgcc/../gcc/tsystem.h:93, from ../../../../src/libgcc/../gcc/libgcc2.c:29: /usr/include/linux/errno.h:4:23: fatal error: asm/errno.h: No such file or directory -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'stable-updates'), (500, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644771: Cross-compile fails due to inability to build locales-all
Source: eglibc Version: 2.13-21 Severity: wishlist Tags: patch While cross-compiling EGLIBC, the package-build fails building the architecture-specific locales-all package as the binaries needed for that task are for a non-native architecture. To resolve the issue, the locales-all package should only be built when compiling natively. The attached patch results in successful cross-builds in my test environment. Cheers, Kyle Moffett -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'stable-updates'), (500, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash diff -ru eglibc-2.13/debian/rules STAGE2/EGLIBC/eglibc-2.13/debian/rules --- eglibc-2.13/debian/rules 2011-10-07 17:40:39.0 -0400 +++ STAGE2/EGLIBC/eglibc-2.13/debian/rules 2011-10-08 17:45:08.0 -0400 @@ -128,10 +128,15 @@ # Which build pass are we on? curpass = $(filter-out %_,$(subst _,_ ,$@)) -DEB_ARCH_REGULAR_PACKAGES = $(libc) $(libc)-dev $(libc)-dbg $(libc)-prof $(libc)-pic libc-bin libc-dev-bin locales-all multiarch-support +DEB_ARCH_REGULAR_PACKAGES = $(libc) $(libc)-dev $(libc)-dbg $(libc)-prof $(libc)-pic libc-bin libc-dev-bin multiarch-support DEB_INDEP_REGULAR_PACKAGES = glibc-doc eglibc-source locales DEB_UDEB_PACKAGES = $(libc)-udeb libnss-dns-udeb libnss-files-udeb +## Locales can only be pre-generated during native compiles +ifeq ($(DEB_HOST_ARCH),$(DEB_BUILD_ARCH)) +DEB_ARCH_REGULAR_PACKAGES += locales-all +endif + # Generic kernel version check define kernel_check (if [ $(CURRENT_KERNEL_VERSION) -lt $(1) ]; then \
Bug#644785: Cross-compile sets -DUNALIGNED_OK based on DEB_BUILD_ARCH
Source: gzip Version: 1.4-1 Severity: wishlist Tags: patch User: crosscomp...@debian.org Usertags: cross When cross-compiling, the DEB_BUILD_ARCH variable describes the system on which the compile is running, while DEB_HOST_ARCH describes the system on which the binaries will be installed. Since CFLAGS is used when building binaries for the target system, the check for -DUNALIGNED_OK should be based on DEB_HOST_ARCH, as per the attached patch. Cheers, Kyle Moffett -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'stable-updates'), (500, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash diff -ruN gzip-1.4.orig/debian/rules gzip-1.4/debian/rules --- gzip-1.4.orig/debian/rules 2011-10-08 21:44:59.0 -0400 +++ gzip-1.4/debian/rules 2011-10-08 21:45:58.0 -0400 @@ -11,8 +11,7 @@ CONFARGS = --host=$(DEB_HOST_GNU_TYPE) endif -buildarch := $(shell dpkg-architecture -qDEB_BUILD_ARCH) -ifeq ($(buildarch),amd64) +ifeq ($(shell dpkg-architecture -qDEB_HOST_ARCH),amd64) CFLAGS=-g -O2 -Wall -DUNALIGNED_OK else CFLAGS=-g -O2 -Wall
Bug#644662: Fails to build if GCC does not have libssp support
Source: eglibc
Version: 2.13-21
Severity: normal
Tags: upstream patch
The attached patch fixes detection of GCC -fstack-protector and libssp.
In order to properly detect whether or not GCC has -fstack-protect
support built in, you actually need to link something. Otherwise
GCC will accept the option and fail during the link due to missing
libssp.
This occurs in particular when trying to bootstrap a cross-compiler for
a new Debian port; the stage2 cross-compiler does not have libssp
support causing undefined reference to `__stack_chk_guard' errors
when building EGLIBC.
The fix is simply to remove the -c from the -fstack-protector test,
so it verifies whether or not GCC can actually link objects built with
that option.
This fix should also be forwarded upstream.
Cheers,
Kyle Moffett
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500,
'stable-updates'), (500, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
diff -ruN eglibc-2.13/debian/patches/any/local-fix-libssp-detection.patch eglibc-2.13.new/debian/patches/any/local-fix-libssp-detection.patch
--- eglibc-2.13/debian/patches/any/local-fix-libssp-detection.patch 1969-12-31 19:00:00.0 -0500
+++ eglibc-2.13.new/debian/patches/any/local-fix-libssp-detection.patch 2011-10-06 19:35:30.0 -0400
@@ -0,0 +1,32 @@
+Fix detection of GCC -fstack-protect and libssp support
+
+In order to properly detect whether or not GCC has -fstack-protect
+support built in, you actually need to link something. Otherwise
+GCC will accept the option and fail during the link due to missing
+libssp.
+Index: eglibc-2.13/configure
+===
+--- eglibc-2.13.orig/configure 2011-10-06 19:31:36.0 -0400
eglibc-2.13/configure 2011-10-06 19:33:13.0 -0400
+@@ -6942,7 +6942,7 @@
+ $as_echo_n (cached) 6
+ else
+ if { ac_try='${CC-cc} $CFLAGS $CPPFLAGS -Werror -fstack-protector
+- -o /dev/null -c -x c /dev/null 15'
++ -o /dev/null -x c /dev/null 15'
+ { (eval echo $as_me:$LINENO: \$ac_try\) 5
+ (eval $ac_try) 25
+ ac_status=$?
+Index: eglibc-2.13/configure.in
+===
+--- eglibc-2.13.orig/configure.in 2011-10-06 19:31:36.0 -0400
eglibc-2.13/configure.in 2011-10-06 19:33:06.0 -0400
+@@ -1792,7 +1792,7 @@
+
+ AC_CACHE_CHECK(for -fstack-protector, libc_cv_ssp, [dnl
+ if AC_TRY_COMMAND([${CC-cc} $CFLAGS $CPPFLAGS -Werror -fstack-protector
+- -o /dev/null -c -x c /dev/null 1AS_MESSAGE_LOG_FD])
++ -o /dev/null -x c /dev/null 1AS_MESSAGE_LOG_FD])
+ then
+ libc_cv_ssp=yes
+ else
diff -ruN eglibc-2.13/debian/patches/series eglibc-2.13.new/debian/patches/series
--- eglibc-2.13/debian/patches/series 2011-10-07 17:40:39.0 -0400
+++ eglibc-2.13.new/debian/patches/series 2011-10-06 19:32:45.0 -0400
@@ -289,3 +289,4 @@
any/cvs-dlopen-tls.diff
any/submitted-glob_h-ifdef.diff
any/cvs-dl_close-scope-handling.diff
+any/local-fix-libssp-detection.patch
Bug#644546: eglibc: Support cross-compiler bootstrap with stage1 build
Source: eglibc Version: 2.13-21 Severity: wishlist Tags: patch In order to support bootstrap of a Debian cross-compiler, it would be extremely helpful if the EGLIBC packaging supported the stage1 steps as described in the eglibc-2.13/EGLIBC.cross-building file. The attached patch allows for such a build, which creates only a single libc-dev package (EG: libc6-dev on my target arch). There was one necessary unrelated change, due to the fact that a stage1 cross-compiler does not include a package setting up the default commands of the form $TRIPLET-gcc, so I added the DEB_GCC_VERSIOn variable to force CC to be a particular compiler version. The specific commands I used to test this patch on my amd64 host: $ sudo apt-get build-dep eglibc=2.13-21 $ apt-get source eglibc=2.13-21 $ patch -d eglibc-2.13 -p1 eglibc-2.13-cross-stage1-support.patch $ ( cd eglibc-2.13 DEB_GCC_VERSION=-4.6 DEB_STAGE=stage1 \ dpkg-buildpackage -apowerpcspe -b -us -uc ) 21 | tee eglibc-stage1.log This produced a single libc6-dev_2.13-21_powerpcspe.deb file, which I installed using the following command: $ sudo dpkg-cross -M -a powerpcspe -X libc6 -X libc-dev-bin \ -i libc6-dev_2.13-21_powerpcspe.deb The only remaining issue is that the libc6-dev package that is built still has dependencies on libc6 and libc-dev-bin. Unfortunately I can't figure out the debian/control file generation well enough to fix that, so I'm hoping that the EGLIBC maintainers can make it work. The result is that I can proceed to building a stage2 GCC using the standard DEB_STAGE=stage2 process in the gcc-4.6 package. I have to say, I'm not exactly proud of the way it works, it sort of forcibly overrides several variables and make pattern rules to build only the single default target-architecture headers it wants. On the other hand the changes are almost entirely self-contained in a single new file: debian/rules.d/stage1.mk. Cheers, Kyle Moffett -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'stable-updates'), (500, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash diff -ruN eglibc-2.13/debian/rules eglibc-2.13.stage1/debian/rules --- eglibc-2.13/debian/rules 2011-10-06 15:45:01.0 -0400 +++ eglibc-2.13.stage1/debian/rules 2011-10-06 14:29:57.0 -0400 @@ -101,11 +101,12 @@ # Set CC and CXX for cross-compiling ifneq ($(DEB_HOST_ARCH),$(DEB_BUILD_ARCH)) -CC = $(DEB_HOST_GNU_TYPE)-gcc -CXX= $(DEB_HOST_GNU_TYPE)-g++ +CC = $(DEB_HOST_GNU_TYPE)-gcc$(DEB_GCC_VERSION) +CXX= $(DEB_HOST_GNU_TYPE)-g++$(DEB_GCC_VERSION) else -CC = gcc-4.4 -CXX= g++-4.4 +DEB_GCC_VERSION ?= -4.4 +CC = gcc$(DEB_GCC_VERSION) +CXX= g++$(DEB_GCC_VERSION) endif BUILD_CFLAGS = -O2 -g diff -ruN eglibc-2.13/debian/rules.d/stage1.mk eglibc-2.13.stage1/debian/rules.d/stage1.mk --- eglibc-2.13/debian/rules.d/stage1.mk 1969-12-31 19:00:00.0 -0500 +++ eglibc-2.13.stage1/debian/rules.d/stage1.mk 2011-10-06 15:40:35.0 -0400 @@ -0,0 +1,71 @@ +## This reuses various macros from the debian/rules.d/build.mk file + +ifeq ($(DEB_STAGE),stage1) + +override EGLIBC_PASSES = libc +override DEB_ARCH_REGULAR_PACKAGES = $(libc)-dev +override DEB_INDEP_REGULAR_PACKAGES = +override DEB_UDEB_PACKAGES = + +## Development libraries we need to fake +stage1_libfake.so := \ + libc.so + +stage1_libfake.a := \ + libanl.a \ + libBrokenLocale.a \ + libbsd-compat.a \ + libc.a \ + libc_nonshared.a \ + libcrypt.a \ + libdl.a \ + libg.a \ + libieee.a \ + libm.a \ + libmcheck.a \ + libnsl.a \ + libpthread.a \ + libpthread_nonshared.a \ + libresolv.a \ + librpcsvc.a \ + librt.a \ + libutil.a \ + +$(stamp)build_libc: $(stamp)configure_libc + @echo Building $(curpass) + @## Build the crtX.o init routines + $(call logme, -a $(log_build), $(MAKE) -C $(DEB_BUILDDIR) $(NJOBS) csu/subdir_lib) + $(call logme, -a $(log_build), $(AR) qcs $(DEB_BUILDDIR)/libfake.a) + $(call logme, -a $(log_build), $(CC) -nostdlib -nostartfiles -shared \ +-o $(DEB_BUILDDIR)/libfake.so $(DEB_BUILDDIR)/libfake.a) + $(call logme, -a $(log_build), echo --- ; echo -n Build ended: ; date --rfc-2822) + touch $@ + +$(stamp)check_libc: $(stamp)build_libc + @echo Nothing to test for $(curpass) + touch $@ + +$(stamp)install_libc: DESTDIR=$(CURDIR)/debian/tmp-$(curpass) +$(stamp)install_libc: $(stamp)check_libc + @echo Installing $(curpass) + rm -rf $(CURDIR)/debian/tmp-$(curpass) + ## These libc/ld-linux binaries are total garbage, but they allow + ## a subsequent stage2 GCC build to succeed. + install -d $(DESTDIR)/usr/lib/$(DEB_HOST_MULTIARCH) + for lib_a in $(stage1_libfake.a); do \ + install -T $(DEB_BUILDDIR)/libfake.a $(DESTDIR)/usr/lib/$(DEB_HOST_MULTIARCH)/$$lib_a; \ + done + for lib_so
Bug#629558: krb5-kdc: kdb_ldap plugin crashes during kinit user@DOMAIn with wrong case for DOMAIn
Ping? This should be a pretty quick one-line bugfix.
Since this appears to be an upstream bug, I've added krb...@mit.edu
to the CC list.
Kyle Moffett wrote:
At src/plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c:108, inside the
function krb5_ldap_get_principal():
If is_principal_in_realm() fails, the code does not properly initialize
the variable st (IE: with KRB5_KDB_NOENTRY or something) before calling
krb5_set_error_message().
This can happen if the realm is EXAMPLE.COM and somebody types:
kinit u...@exmample.com (IE: case is not quite right).
As a result, the krb5_ldap_get_principal() function returns 0 but leaves
the client pointer set to NULL.
When it returns out to src/kdc/do_as_req.c:211, the process_as_req() code
assumes that it succeeded, and promptly dereferences client, causing a
crash.
The fix is to add a single line st = KRB5_KDB_NOENTRY into the file
ldap_principal2.c after this line:
if (is_principal_in_realm(ldap_context, searchfor) != 0) {
Cheers,
Kyle Moffett
P.S: Out of curiosity, is there some reason why there are not packages
for krb5-kdc-dbg and krb5-admin-server-dbg, etc? That would make this
kind of troubleshooting much easier in the future.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (700, 'testing'), (600, 'unstable'), (500, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.38-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages krb5-kdc depends on:
ii debconf [debconf-2.0] 1.5.38 Debian configuration management
sy
ii krb5-config 2.2 Configuration files for Kerberos
V
ii krb5-user 1.9+dfsg-1+debug01 Basic programs to authenticate
usi
ii libc6 2.11.2-11 Embedded GNU C Library: Shared
lib
ii libcomerr2 1.41.12-2 common error description library
ii libgssapi-krb5-2 1.9+dfsg-1+debug01 MIT Kerberos runtime libraries -
k
ii libgssrpc4 1.9+dfsg-1+debug01 MIT Kerberos runtime libraries -
G
ii libk5crypto3 1.9+dfsg-1+debug01 MIT Kerberos runtime libraries -
C
ii libkadm5clnt-mit8 1.9+dfsg-1+debug01 MIT Kerberos runtime libraries -
A
ii libkadm5srv-mit8 1.9+dfsg-1+debug01 MIT Kerberos runtime libraries -
K
ii libkdb5-5 1.9+dfsg-1+debug01 MIT Kerberos runtime libraries -
K
ii libkeyutils1 1.4-4 Linux Key Management Utilities
(li
ii libkrb5-3 1.9+dfsg-1+debug01 MIT Kerberos runtime libraries
ii libkrb5support0 1.9+dfsg-1+debug01 MIT Kerberos runtime libraries -
S
ii lsb-base 3.2-27 Linux Standard Base 3.2 init
scrip
krb5-kdc recommends no packages.
Versions of packages krb5-kdc suggests:
ii krb5-admin-server 1.9+dfsg-1+debug01 MIT Kerberos master server
(kadmin
ii krb5-kdc-ldap 1.9+dfsg-1+debug01 MIT Kerberos key server (KDC)
LDAP
pn openbsd-inetd | inet- none (no description available)
-- debconf information excluded
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500,
'stabl
e-updates'), (500, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644439: Bootstrap stage1 cross-compiler depends on nonexistent libgcc
Source: gcc-4.6 Version: 4.6.1-13 Severity: normal Tags: patch When compiling a GCC stage1 cross-compiler, the generated control file depends on libgcc even when one is not built, making it impossible to install the stage1 compiler to prepare for stage2. The specific commands I used were: $ sudo apt-get build-dep gcc-4.6=4.6.1-13 $ apt-get source gcc-4.6=4.6.1-13 $ cd gcc-4.6-4.6.1 $ DEB_GCC_TARGET=powerpcspe DEB_STAGE=stage1 dpkg-buildpackage -b -us -uc [... successful build output ...] $ cd .. $ sudo dpkg -i cpp-4.6-powerpc-linux-gnuspe_4.6.1-13_amd64.deb Selecting previously unselected package cpp-4.6-powerpc-linux-gnuspe. (Reading database ... 474927 files and directories currently installed.) Unpacking gcc-4.6-powerpc-linux-gnuspe (from gcc-4.6-powerpc-linux-gnuspe_4.6.1-13_amd64.deb) ... Setting up cpp-4.6-powerpc-linux-gnuspe (4.6.1-13) ... Processing triggers for icecc ... $ sudo dpkg -i gcc-4.6-powerpc-linux-gnuspe_4.6.1-13_amd64.deb Selecting previously unselected package gcc-4.6-powerpc-linux-gnuspe. (Reading database ... 474927 files and directories currently installed.) Unpacking gcc-4.6-powerpc-linux-gnuspe (from gcc-4.6-powerpc-linux-gnuspe_4.6.1-13_amd64.deb) ... dpkg: dependency problems prevent configuration of gcc-4.6-powerpc-linux-gnuspe: gcc-4.6-powerpc-linux-gnuspe depends on libgcc1-powerpcspe-cross (= 1:4.6.1-13); however: Package libgcc1-powerpcspe-cross is not installed. dpkg: error processing gcc-4.6-powerpc-linux-gnuspe (--install): dependency problems - leaving unconfigured Processing triggers for icecc ... Errors were encountered while processing: gcc-4.6-powerpc-linux-gnuspe The attached patch disables the libgcc dependency if with_libgcc is unset (specifically during stage1). This seems to resolve the problem and allow me to continue with building a stage2 cross-compiler. Cheers, Kyle Moffett -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'stable-updates'), (500, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash --- rules.conf.orig 2011-10-05 17:07:10.0 -0400 +++ rules.conf 2011-10-05 17:09:19.0 -0400 @@ -483,26 +483,28 @@ DEB_LIBGCC_VERSION := $(DEB_EVERSION) endif -LIBGCC_DEP := libgcc$(GCC_SONAME)$(LS) (= $(DEB_LIBGCC_VERSION)) -LIBGCC_BIARCH_DEP := -ifeq ($(biarch64),yes) - LIBGCC_BIARCH_DEP := lib64gcc$(GCC_SONAME)$(LS) (= $(DEB_LIBGCC_VERSION)) -endif -ifeq ($(biarch32),yes) - LIBGCC_BIARCH_DEP := lib32gcc$(GCC_SONAME)$(LS) (= $(DEB_LIBGCC_VERSION)) -endif -ifeq ($(biarchn32),yes) +ifeq ($(with_libgcc),yes) + LIBGCC_DEP := libgcc$(GCC_SONAME)$(LS) (= $(DEB_LIBGCC_VERSION)) + LIBGCC_BIARCH_DEP := ifeq ($(biarch64),yes) -LIBGCC_BIARCH_DEP := lib64gcc$(GCC_SONAME)$(LS) (= $(DEB_LIBGCC_VERSION)), libn32gcc$(GCC_SONAME)$(LS) (= $(DEB_LIBGCC_VERSION)) - else -LIBGCC_BIARCH_DEP := libn32gcc$(GCC_SONAME)$(LS) (= $(DEB_LIBGCC_VERSION)) +LIBGCC_BIARCH_DEP := lib64gcc$(GCC_SONAME)$(LS) (= $(DEB_LIBGCC_VERSION)) + endif + ifeq ($(biarch32),yes) +LIBGCC_BIARCH_DEP := lib32gcc$(GCC_SONAME)$(LS) (= $(DEB_LIBGCC_VERSION)) + endif + ifeq ($(biarchn32),yes) +ifeq ($(biarch64),yes) + LIBGCC_BIARCH_DEP := lib64gcc$(GCC_SONAME)$(LS) (= $(DEB_LIBGCC_VERSION)), libn32gcc$(GCC_SONAME)$(LS) (= $(DEB_LIBGCC_VERSION)) +else + LIBGCC_BIARCH_DEP := libn32gcc$(GCC_SONAME)$(LS) (= $(DEB_LIBGCC_VERSION)) +endif + endif + ifeq ($(biarchhf),yes) +LIBGCC_BIARCH_DEP := libhfgcc$(GCC_SONAME)$(LS) (= $(DEB_LIBGCC_VERSION)) + endif + ifeq ($(biarchsf),yes) +LIBGCC_BIARCH_DEP := libsfgcc$(GCC_SONAME)$(LS) (= $(DEB_LIBGCC_VERSION)) endif -endif -ifeq ($(biarchhf),yes) - LIBGCC_BIARCH_DEP := libhfgcc$(GCC_SONAME)$(LS) (= $(DEB_LIBGCC_VERSION)) -endif -ifeq ($(biarchsf),yes) - LIBGCC_BIARCH_DEP := libsfgcc$(GCC_SONAME)$(LS) (= $(DEB_LIBGCC_VERSION)) endif GNAT_VERSION := $(BASE_VERSION)
Bug#644439: Bootstrap stage1 cross-compiler depends on nonexistent libgcc
Source: gcc-4.6 Version: 4.6.1-13 Followup-For: Bug #644439 Oops, when I attached the patch I nabbed the wrong one from my directory. The first hunk (rules.conf) of the attached patch is the same as the original except without the whitespace-reindent, as it makes the the patch easier to read. The second hunk (rules.defs) is necessary to prevent with_libgcc from getting unconditionally enabled even when DEB_STAGE=stage1. This makes the with_libgcc part look exactly like all the other with_common_libs shared library conditionals, so it seems obviously correct to me. Please let me know if you have any questions, comments, or critiques. Thanks! Cheers, Kyle Moffett diff -ru gcc-4.6-4.6.1.orig/debian/rules.conf gcc-4.6-4.6.1/debian/rules.conf --- gcc-4.6-4.6.1.orig/debian/rules.conf 2011-10-05 18:21:18.0 -0400 +++ gcc-4.6-4.6.1/debian/rules.conf 2011-10-05 18:26:02.0 -0400 @@ -483,6 +483,7 @@ DEB_LIBGCC_VERSION := $(DEB_EVERSION) endif +ifeq ($(with_libgcc),yes) LIBGCC_DEP := libgcc$(GCC_SONAME)$(LS) (= $(DEB_LIBGCC_VERSION)) LIBGCC_BIARCH_DEP := ifeq ($(biarch64),yes) @@ -504,6 +505,7 @@ ifeq ($(biarchsf),yes) LIBGCC_BIARCH_DEP := libsfgcc$(GCC_SONAME)$(LS) (= $(DEB_LIBGCC_VERSION)) endif +endif GNAT_VERSION := $(BASE_VERSION) diff -ru gcc-4.6-4.6.1.orig/debian/rules.defs gcc-4.6-4.6.1/debian/rules.defs --- gcc-4.6-4.6.1.orig/debian/rules.defs 2011-10-05 18:21:18.0 -0400 +++ gcc-4.6-4.6.1/debian/rules.defs 2011-10-05 18:17:31.0 -0400 @@ -878,6 +878,11 @@ #endif endif + # Shared libgcc + ifeq ($(with_libgcc),$(with_common_libs),yes-yes) +with_shared_libgcc := yes + endif + # fixincludes --- ifneq ($(DEB_CROSS),yes) ifeq ($(with_common_pkgs),yes) @@ -885,12 +890,6 @@ endif endif - # Shared libgcc - ifeq ($(with_common_libs),yes) -with_libgcc := yes -with_shared_libgcc := yes - endif - # libgcc-math with_libgmath := no ifneq (,$(findstring i486,$(DEB_TARGET_ARCH)))
Bug#644338: libffi: Build errors on PowerPC e500, test-suite failures on PowerPC soft-float
Package: libffi
Severity: normal
Tags: patch upstream
User: debian-powerpc...@breakpoint.cc
Usertags: powerpcspe
The Debian-Ports powerpcspe architecture can't currently build the
libffi package for a couple reasons:
(1) The package contains lots of FP assembly instructions even when
built on a soft-float target, resulting in compile errors on the
Debian powerpcspe architecture (totally different FPU ops).
(2) The existing soft-float support code has buggy handling of 128-bit
values and results in testsuite failures on soft-float and e500
(powerpcspe) platforms even when it can be made to compile.
The attached patch resolves both issues.
Cheers,
Kyle Moffett
From 95d80e11f6d14da32c9e117321658c27155e313a Mon Sep 17 00:00:00 2001
From: Kyle Moffett kyle.d.moff...@boeing.com
Date: Tue, 16 Aug 2011 14:46:50 -0400
Subject: [PATCH] PowerPC: Debug and fix soft-floating-point support
There were a wide range of bugs in this code, including long-double
register alignment issues, assignments to global constants (which were
actually stored as non-constant integers).
This passes the testsuite on soft-floating-point PowerPC, and it builds
and passes the testsuite on PowerPC e500 systems which cannot even
assemble the regular floating-point instruction set.
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
---
src/powerpc/ffi.c | 533 -
src/powerpc/ffitarget.h | 14 +-
src/powerpc/ppc_closure.S | 19 ++
src/powerpc/sysv.S|6 +
4 files changed, 310 insertions(+), 262 deletions(-)
diff --git a/src/powerpc/ffi.c b/src/powerpc/ffi.c
index fb2a39f..e5ec1c5 100644
--- a/src/powerpc/ffi.c
+++ b/src/powerpc/ffi.c
@@ -40,7 +40,9 @@ enum {
/* The assembly depends on these exact flags. */
FLAG_RETURNS_SMST= 1 (31-31), /* Used for FFI_SYSV small structs. */
FLAG_RETURNS_NOTHING = 1 (31-30), /* These go in cr7 */
+#ifndef __NO_FPRS__
FLAG_RETURNS_FP = 1 (31-29),
+#endif
FLAG_RETURNS_64BITS = 1 (31-28),
FLAG_RETURNS_128BITS = 1 (31-27), /* cr6 */
@@ -51,21 +53,20 @@ enum {
/* Bits (31-24) through (31-19) store shift value for SMST */
FLAG_ARG_NEEDS_COPY = 1 (31- 7),
+#ifndef __NO_FPRS__
FLAG_FP_ARGUMENTS = 1 (31- 6), /* cr1.eq; specified by ABI */
+#endif
FLAG_4_GPR_ARGUMENTS = 1 (31- 5),
FLAG_RETVAL_REFERENCE = 1 (31- 4)
};
/* About the SYSV ABI. */
-unsigned int NUM_GPR_ARG_REGISTERS = 8;
+#define ASM_NEEDS_REGISTERS 4
+#define NUM_GPR_ARG_REGISTERS 8
#ifndef __NO_FPRS__
-unsigned int NUM_FPR_ARG_REGISTERS = 8;
-#else
-unsigned int NUM_FPR_ARG_REGISTERS = 0;
+# define NUM_FPR_ARG_REGISTERS 8
#endif
-enum { ASM_NEEDS_REGISTERS = 4 };
-
/* ffi_prep_args_SYSV is called by the assembly routine once stack space
has been allocated for the function's arguments.
@@ -114,10 +115,12 @@ ffi_prep_args_SYSV (extended_cif *ecif, unsigned *const
stack)
valp gpr_base;
int intarg_count;
+#ifndef __NO_FPRS__
/* 'fpr_base' points at the space for fpr1, and grows upwards as
we use FPR registers. */
valp fpr_base;
int fparg_count;
+#endif
/* 'copy_space' grows down as we put structures in it. It should
stay 16-byte aligned. */
@@ -126,9 +129,8 @@ ffi_prep_args_SYSV (extended_cif *ecif, unsigned *const
stack)
/* 'next_arg' grows up as we put parameters in it. */
valp next_arg;
- int i, ii MAYBE_UNUSED;
+ int i;
ffi_type **ptr;
- double double_tmp;
union {
void **v;
char **c;
@@ -144,15 +146,16 @@ ffi_prep_args_SYSV (extended_cif *ecif, unsigned *const
stack)
size_t struct_copy_size;
unsigned gprvalue;
- if (ecif-cif-abi == FFI_LINUX_SOFT_FLOAT)
-NUM_FPR_ARG_REGISTERS = 0;
-
stacktop.c = (char *) stack + bytes;
gpr_base.u = stacktop.u - ASM_NEEDS_REGISTERS - NUM_GPR_ARG_REGISTERS;
intarg_count = 0;
+#ifndef __NO_FPRS__
fpr_base.d = gpr_base.d - NUM_FPR_ARG_REGISTERS;
fparg_count = 0;
copy_space.c = ((flags FLAG_FP_ARGUMENTS) ? fpr_base.c : gpr_base.c);
+#else
+ copy_space.c = gpr_base.c;
+#endif
next_arg.u = stack + 2;
/* Check that everything starts aligned properly. */
@@ -175,12 +178,28 @@ ffi_prep_args_SYSV (extended_cif *ecif, unsigned *const
stack)
i 0;
i--, ptr++, p_argv.v++)
{
- switch ((*ptr)-type)
- {
+ unsigned short typenum = (*ptr)-type;
+
+ /* We may need to handle some values depending on ABI */
+ if (ecif-cif-abi == FFI_LINUX_SOFT_FLOAT) {
+ if (typenum == FFI_TYPE_FLOAT)
+ typenum = FFI_TYPE_UINT32;
+ if (typenum == FFI_TYPE_DOUBLE)
+ typenum = FFI_TYPE_UINT64;
+ if (typenum == FFI_TYPE_LONGDOUBLE)
+ typenum = FFI_TYPE_UINT128;
+ } else if (ecif-cif-abi != FFI_LINUX) {
+#if FFI_TYPE_LONGDOUBLE != FFI_TYPE_DOUBLE
+ if (typenum == FFI_TYPE_LONGDOUBLE
Bug#639290: APT resolution issue occurs even without libc6 in the loop
I've been able to reproduce this same issue on my new laptop with only perl and modules in the dependency chain. I just installed it with squeeze, then decided I wanted to upgrade since my graphics card isn't well supported under 2.6.32. Initially the failing package set was much larger, but I was able to install a bunch of stuff by hand and get it down to just this list. I almost wonder if the issue could be related to the virtual perlapi-5.10.1 versus perlapi-5.12.4 packages? The odd-looking libsnmp15 is because it apparently includes perl modules or embeds perl or something. Cheers, Kyle Moffett Upgrading: perl perl-base perl-modules libcairo-perl libdigest-sha1-perl libfont-freetype-perl libglib-perl libgnome2-canvas-perl libgnome2-perl libgnome2-vfs-perl libgtk2-perl libhtml-parser-perl liblocale-gettext-perl libnet-dbus-perl libpango-perl libsnmp15 libsub-name-perl libtext-charwidth-perl libtext-iconv-perl libuuid-perl libxml-parser-perl Removing: libperl5.10 Installing: libclass-isa-perl libperl5.12 libpod-plainer-perl libswitch-perl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639290: APT resolution issue occurs even without libc6 in the loop
On Wed, Sep 21, 2011 at 22:47, Kyle Moffett k...@moffetthome.net wrote: I've been able to reproduce this same issue on my new laptop with only perl and modules in the dependency chain. I just installed it with squeeze, then decided I wanted to upgrade since my graphics card isn't well supported under 2.6.32. Initially the failing package set was much larger, but I was able to install a bunch of stuff by hand and get it down to just this list. Ok, by removing some leaf packages that depended on other things in the list, I was able to work it down to this smaller list that still fails due to inability to immediately configure perl. Unfortunately gnome-desktop-environment depends on libgnome2-perl, which depends on a lot of other modules, so I doubt I will be able to shrink it appreciably from here. For a point of reference, this system was literally installed from scratch very recently with the squeeze installer, using the bog-standard tasksel for Laptop + Standard System + Desktop Environment. Cheers, Kyle Moffett Upgrade: libcairo-perl libglib-perl libgnome2-canvas-perl libgnome2-perl libgtk2-perl libhtml-parser-perl liblocale-gettext-perl libnet-dbus-perl libpango-perl libtext-charwidth-perl libtext-iconv-perl libuuid-perl libxml-parser-perl perl perl-base perl-modules -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592550: Provide support for SSH-Key authentication (Supports Eucalyptus and Amazon EC2)
On Sep 10, 2011, at 09:30, Charles Plessy wrote: Le Tue, Aug 10, 2010 at 04:49:51PM -0400, Kyle Moffett a écrit : The Ubuntu guys seem to have a patch for this that never got merged: https://bugs.launchpad.net/ubuntu/+source/network-console/+bug/184108 I think that it would wonderful if Ubuntu's patch were applied in Debian. Here is a slimmed down version of it, where I removed the Ubuntu-specific parts changing debian/control, the changelog and .gitignore files, … http://patches.ubuntu.com/n/network-console/network-console_1.28ubuntu1.patch [... patch snipped ...] Please let me know how I can help to make this happen. Charles, My latest patch (attached) provides a bunch more features for installing in virtualized environments. You can also download it at this URL: http://opensource.exmeritus.com/debian-ami/network-console-1.29+euca01.patch Specifically, my patch allows you enable both password and public-key auth, by preseeding both a password and the authorized_keys URL. If you don't want to enable password authentication, you can preseed password-disabled instead. Additionally, I add a publi-ip-url key which causes the IP value in the network-console message to be obtained from the virtualized hosting system. Finally, I rewrite the post-base-installer hook to automatically copy the authorized_keys file to the newly created user on the target system. If a non-root user was created during the installation then the key is copied to that user, otherwise it is copied to root. Cheers, Kyle Moffett network-console-1.29+euca01-1.patch Description: Binary data
Bug#639957: Dediprog SF100 support is disabled (CONFIG_DEDIPROG)
Package: flashrom Version: 0.9.3+r1323-1 Severity: normal Tags: upstream I've been using a locally-built flashrom (v0.9.3+r1257) with the config option CONFIG_DEDIPROG enabled to program AT25DF321 SPI EEPROMS on some custom hardware. The programming process is dramatically slower than with the MS Windows programming tool that comes with the Dediprog SF100, but during several months of using the tool I have had a 100% success rate on all of the program-verify cycles I have performed. I believe that the SF100 support is stable enough for general use, so Debian (and upstream) should set the CONFIG_DEDIPROG=yes build option by default. Additionally, the AT25DF321 is listed as untested for write, but as before it seems to work very well at multiple block sizes, so it too should be listed as tested. Cheers, Kyle Moffett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639324: Hook isc-dhcp-client to generate a BIND forwarders.conf file
Package: bind9
Version: 1:9.7.3.dfsg-1+b1
Severity: wishlist
Tags: patch
In certain environments (especially virtualized ones) it is necessary to
run a local recursive BIND9 server which is authoritative for some
internal domains and forwards others to an external DNS server obtained
from DHCP.
For example, in Amazon's EC2 virtual hosting environment, the .internal
and .amazonaws.com domains should be forwarded to some Amazon DNS
server passed in via DHCP, but that DNS server's address is not strictly
fixed (172.16.0.23 right now, I think).
I have attached an ISC dhclient exit hook script which makes it possible
to configure a BIND9 server for that scenario. The script should be
installed as:
/etc/dhcp/dhclient-exit-hooks.d/bind9
Each time the DHCP client updates its current DHCP lease, it will
automatically write out a new /var/run/bind/forwarders_*.conf file named
for the network interface on which the lease was obtaned. This config
file will contain the list of recursive DNS servers specified via DHCP.
For example, here is my /var/run/bind/forwarders_eth0.conf from EC2:
forwarders {
172.16.0.23;
};
I then include the appropriate file in my BIND9 config file:
zone amazonaws.com IN {
type forward;
forward only;
include /var/run/bind/forwarders_eth0.conf;
};
zone internal IN {
type forward;
forward only;
include /var/run/bind/forwarders_eth0.conf;
};
zone 10.in-addr.arpa IN {
type forward;
forward only;
include /var/run/bind/forwarders_eth0.conf;
};
Please consider including this script into the BIND9 package.
Cheers,
Kyle Moffett
#! /bin/bash
#
# Script fragment to pass DHCP-obtained resolvers off to BIND9
#
# Licensed under the GNU GPL. See /usr/share/common-licenses/GPL.
#
# Tips:
# * Be careful about changing the environment since this is sourced
# * This script fragment uses bash features
## Only handle certain operations, and only if it's a successful one
case $1:$reason in
(0:BOUND|0:RENEW|0:REBIND|0:REBOOT|0:TIMEOUT)
: ;;
(*)
return 0;
esac
bind_fwd_conf=/var/run/bind/forwarders_${interface}.conf
## Generate a new forwarders file and fix permissions
mkdir -p --mode=0755 '/var/run/bind'
bind_fwd_temp=$(mktemp ${bind_fwd_conf}.XX)
chown 0:0 ${bind_fwd_temp}
chmod 644 ${bind_fwd_temp}
## Populate it from DHCP data
echo 'forwarders {' ${bind_fwd_temp}
for nameserver in ${new_domain_name_servers}; do
echo ${nameserver}; ${bind_fwd_temp}
done
echo '};'${bind_fwd_temp}
## Don't do anything unless the DHCP data changed. If this runs before /usr
## is mounted then the /usr/bin/cmp command might fail, but it's perfectly
## OK to
if /usr/bin/cmp -q ${bind_fwd_conf} ${bind_fwd_temp} 2/dev/null; then\
rm -f ${bind_fwd_temp}
return 0
fi
## The forwarders list has changed, so we should replace the file
mv -f ${bind_fwd_temp} ${bind_fwd_conf}
## We're done unless we can reload BIND
[ -x /usr/sbin/named ] || return 0
[ -x /etc/init.d/bind9 ] || return 0
## Reload BIND9 and finish
/etc/init.d/bind9 reload || true
return 0
Bug#592550: support for SSH-Key authentication (Supports Eucalyptus and Amazon EC2)
On Jul 19, 2011, at 19:22, Charles Plessy wrote: Le Wed, Aug 11, 2010 at 07:58:04PM -0400, Kyle Moffett a écrit : The modified installer now retrieves a public-ip-url and displays that address in the console output instead of the IP found on the network interface. This correctly interoperates with Eucalyptus and Amazon EC2. In those environments you would use the following bit of preseed: d-i network-console/password-disabled boolean true d-i network-console/public-ip-url string \ http://169.254.169.254/2007-01-19/meta-data/public-ipv4 d-i network-console/public-key-url string \ http://169.254.169.254/2007-01-19/meta-data/public-keys/0/openssh-key I'm also in the process of working on a small Debian-Installer patch to automatically prepare a partially-preseeded D-I image following those conventions. I've built a modified network-console with this patch into a slightly patched Debian-Installer and successfully used it to begin a network install on an Amazon EC2 instance. Dear Kyle and Debian Installer team, this would be a very interesting feature. Since the Amazon EC2 can boot on custom kernels, it looks like that with this patch (or using Petter's workaround), it would be possible to prepare an Amazon Machine Image (AMI) of Debian-Installer itself, boot it from GRUB (through Amazon's kernels using PVGRUB and preseed it via initrd, in order to install Debian on an Amazon Elastic Block. Is that what you have tried ? That is exactly what I have done. The actual construction of the AMI containing the Debian-Installer is a bit of a pain; I have a shell-script wrapper around the Amazon EC2 tools in order to do marshall it into the official EC2 format, but the patches necessary to make the SSH Console and Debian-Installer play nicely were surprisingly small. Basically, I created a new Debian-Installer image variant with a built-in preseed file containing references to the standard Amazon EC2 infrastructure for loading SSH keys and downloading additional preseed from EC2 user-data. I will see if I don't have 15 minutes some time soon to dust off those patches to update and resubmit them. Cheers, Kyle Moffett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615998: linux-image-2.6.32-5-xen-amd64: Repeatable kernel BUG at fs/jbd2/commit.c:534 from Postfix on ext4
On Jun 24, 2011, at 16:02, Jan Kara wrote: On Fri 24-06-11 11:03:52, Moffett, Kyle D wrote: On Jun 24, 2011, at 09:46, Jan Kara wrote: On Thu 23-06-11 16:19:08, Moffett, Kyle D wrote: Besides which, line 534 in the Debian 2.6.32 kernel I am using is this one: J_ASSERT(commit_transaction-t_nr_buffers = commit_transaction-t_outstanding_credits); Hmm, OK, so we've used more metadata buffers than we told JBD2 to reserve. I suppose you are not using data=journal mode and the filesystem was created as ext4 (i.e. not converted from ext3), right? Are you using quotas? The filesystem *is* using data=journal mode. If I switch to data=ordered or data=writeback, the problem goes away. Ah, OK. Then bug https://bugzilla.kernel.org/show_bug.cgi?id=34642 is probably ext3 incarnation of the same problem and it seems it's still present even in the current kernel - that ext3 assertion triggered even with 2.6.39 kernel. Frankly data=journal mode is far less tested than the other two modes especially with ext4, so I'm not sure how good idea is to use it in production. Hm... ugh... I really would *like* data=journal mode to work reliably, especially for specific read-mostly databases and other such things... I suppose the solution is for me to load-test it and help get the bugs fixed!!! :-D The trouble is that the problem is likely in some journal list shuffling code because if just some operation wrongly estimated the number of needed buffers, we'd fail the assertion in jbd2_journal_dirty_metadata(): J_ASSERT_JH(jh, handle-h_buffer_credits 0); Hmm, ok... I'm also going to turn that failing J_ASSERT() into a WARN_ON() just to see how much further it gets. I have an easy script to recreate this data volume even if it gets totally hosed anyways, so... OK, we'll see what happens. Ok, status update here: I applied a modified version of your patch that prints out the values of both t_outstanding_credits and t_nr_buffers when the assertion triggers. I replaced the J_ASSERT() that was failing with the exact same WARN_ON() trigger too. The end result is that postfix successfully finished delivering all the emails. Afterwards I unmounted both filesystems and ran fsck -fy on them, it reported no errors at all. Looking through the log, the filesystem with the issues is the 32MB one mounted on /var/lib/postfix: total 61 drwxr-x--- 3 postfix postfix 1024 Jun 16 21:02 . drwxr-xr-x 46 rootroot 4096 Jun 20 17:19 .. d- 2 rootroot12288 Jun 16 18:35 lost+found -rw--- 1 postfix postfix33 Jun 24 16:34 master.lock -rw--- 1 postfix postfix 1024 Jun 24 16:44 prng_exch -rw--- 1 postfix postfix 2048 Jun 24 16:34 smtpd_scache.db -rw--- 1 postfix postfix 41984 Jun 24 16:36 smtp_scache.db In particular, it's the tlsmgr program accessing the smtp_scache file when it dies. Full log below. Cheers, Kyle Moffett Jun 24 16:36:05 i-38020f57 kernel: [5369326.385234] transaction-t_outstanding_credits = 8 Jun 24 16:36:05 i-38020f57 kernel: [5369326.385247] transaction-t_nr_buffers = 9 Jun 24 16:36:05 i-38020f57 kernel: [5369326.385251] [ cut here ] Jun 24 16:36:05 i-38020f57 kernel: [5369326.385278] WARNING: at /tmp/kdm-deb-kernel/linux-2.6-2.6.32/debian/build/source_amd64_xen/fs/jbd2/transaction.c:1329 jbd2_journal_stop+0x189/0x25d [jbd2]() Jun 24 16:36:05 i-38020f57 kernel: [5369326.385287] Modules linked in: ip6table_filter ip6_tables act_police cls_flow cls_fw cls_u32 sch_htb sch_hfsc sch_ingress sch_sfq xt_time xt_connlimit xt_realm iptable_raw xt_comment xt_recent xt_policy ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_TPROXY nf_tproxy_core xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport xt_MARK xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_conntrack xt_CONNMARK xt_connmark xt_CLASSIFY ipt_LOG xt_tcpudp xt_state iptable_nat nf_nat nf_conntrac Jun 24 16:36:05 i-38020f57 kernel: k_ipv4 nf_defrag_ipv4 nf_conntrack iptable_mangle nfnetlink iptable_filter ip_tables x_tables ext3 jbd loop snd_pcm snd_timer snd soundcore snd_page_alloc pcspkr evdev ext4 mbcache jbd2 crc16 dm_mod xen_netfront xen_blkfront Jun 24 16:36:05 i-38020f57 kernel: [5369326.385440] Pid: 3817, comm: tlsmgr Not tainted 2.6.32-5-xen-amd64 #1 Jun 24 16:36:05 i-38020f57 kernel: [5369326.385445] Call Trace: Jun 24 16:36:05 i-38020f57 kernel: [5369326.385458] [a0032c81] ? jbd2_journal_stop+0x189/0x25d [jbd2
Bug#629558: blarg
Package: krb5-kdc-ldap
Severity: normal
Tags: patch
Subject: krb5-kdc: kdb_ldap plugin crashes during kinit user@DOMAIn with
wrong case for DOMAIn
Package: krb5-kdc
Version: 1.9+dfsg-1+debug01
Severity: normal
At src/plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c:108, inside the
function krb5_ldap_get_principal():
If is_principal_in_realm() fails, the code does not properly initialize
the variable st (IE: with KRB5_KDB_NOENTRY or something) before calling
krb5_set_error_message().
This can happen if the realm is EXAMPLE.COM and somebody types:
kinit u...@exmample.com (IE: case is not quite right).
As a result, the krb5_ldap_get_principal() function returns 0 but leaves
the client pointer set to NULL.
When it returns out to src/kdc/do_as_req.c:211, the process_as_req() code
assumes that it succeeded, and promptly dereferences client, causing a
crash.
The fix is to add a single line st = KRB5_KDB_NOENTRY into the file
ldap_principal2.c after this line:
if (is_principal_in_realm(ldap_context, searchfor) != 0) {
Cheers,
Kyle Moffett
P.S: Out of curiousity, is there some reason why there are not packages
for krb5-kdc-dbg and krb5-admin-server-dbg, etc? That would make this
kind of troubleshooting much easier in the future.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (700, 'testing'), (600, 'unstable'), (500, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.38-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages krb5-kdc depends on:
ii debconf [debconf-2.0] 1.5.38 Debian configuration management sy
ii krb5-config 2.2Configuration files for Kerberos V
ii krb5-user 1.9+dfsg-1+debug01 Basic programs to authenticate usi
ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib
ii libcomerr21.41.12-2 common error description library
ii libgssapi-krb5-2 1.9+dfsg-1+debug01 MIT Kerberos runtime libraries - k
ii libgssrpc41.9+dfsg-1+debug01 MIT Kerberos runtime libraries - G
ii libk5crypto3 1.9+dfsg-1+debug01 MIT Kerberos runtime libraries - C
ii libkadm5clnt-mit8 1.9+dfsg-1+debug01 MIT Kerberos runtime libraries - A
ii libkadm5srv-mit8 1.9+dfsg-1+debug01 MIT Kerberos runtime libraries - K
ii libkdb5-5 1.9+dfsg-1+debug01 MIT Kerberos runtime libraries - K
ii libkeyutils1 1.4-4 Linux Key Management Utilities (li
ii libkrb5-3 1.9+dfsg-1+debug01 MIT Kerberos runtime libraries
ii libkrb5support0 1.9+dfsg-1+debug01 MIT Kerberos runtime libraries - S
ii lsb-base 3.2-27 Linux Standard Base 3.2 init scrip
krb5-kdc recommends no packages.
Versions of packages krb5-kdc suggests:
ii krb5-admin-server 1.9+dfsg-1+debug01 MIT Kerberos master server (kadmin
ii krb5-kdc-ldap 1.9+dfsg-1+debug01 MIT Kerberos key server (KDC) LDAP
pn openbsd-inetd | inet- none (no description available)
-- debconf information excluded
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500,
'stable-updates'), (500, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615998: linux-image-2.6.32-5-xen-amd64: Repeatable kernel BUG at fs/jbd2/commit.c:534 from Postfix on ext4
Package: linux-2.6 Version: 2.6.32-30 Severity: important I'm getting a repeatable BUG from ext4, which seems to be caused by Postfix processing its mail queue. The specific filesystem block device that has the problem seems to be dm-13, which on this boot is the logical volume containing the /var/spool/postfix chroot. This is a completely standard Debian installation running on an Amazon EC2 instance (x86_64). The filesystem is mounted in data=journal mode. This crash is *very* repeatable. It occurs almost every reboot when there are more than 1 or 2 queued emails. I will try re-mounting the filesystem in data=ordered mode momentarily. The relevant filesystems are: /dev/mapper/system-root / ext4 rw,noatime,barrier=1,data=ordered 0 0 /dev/mapper/system-var /var ext4 rw,noatime,barrier=1,nodelalloc,data=journal 0 0 /dev/mapper/system-log /var/log ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered 0 0 /dev/xvda1 /boot ext3 rw,noatime,user_xattr,acl,data=journal 0 0 /dev/mapper/db-mail /var/mail ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered 0 0 /dev/mapper/db-postfix /var/spool/postfix ext4 rw,nosuid,nodev,noatime,barrier=1,nodelalloc,data=journal 0 0 /dev/mapper/db-smtp /var/lib/postfix ext4 rw,nosuid,nodev,noatime,barrier=1,nodelalloc,data=journal 0 0 /dev/mapper/db-smtpcfg /etc/postfix ext4 rw,nosuid,nodev,noatime,barrier=1,nodelalloc,data=journal 0 0 In particular, I note that there was a previous report of a BUG at fs/jbd2/commit.c:533 which never seemed to get isolated: http://www.kerneltrap.com/mailarchive/linux-ext4/2009/9/2/6373283 I need to get this system operational again right now, but I'm going to take a consistent snapshot of it so I can debug it later. NOTE: For followers on the linux-ext4 mailing list, this particular system is running the Debian squeeze kernel (based on 2.6.32), so it's theoretically possible this bug has been fixed upstream since then. I didn't have any luck finding such a fix on Google, though. -- Package-specific info: ** Version: Linux version 2.6.32-5-xen-amd64 (Debian 2.6.32-30) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed Jan 12 05:46:49 UTC 2011 ** Command line: root=/dev/mapper/system-root ro ** Tainted: D (128) * Kernel has oopsed before. ** Kernel log: [ 118.525038] alloc irq_desc for 526 on node -1 [ 118.525040] alloc kstat_irqs on node -1 [ 118.700415] device-mapper: uevent: version 1.0.3 [ 118.700890] device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-de...@redhat.com [ 118.925563] EXT4-fs (dm-0): INFO: recovery required on readonly filesystem [ 118.925580] EXT4-fs (dm-0): write access will be enabled during recovery [ 118.968700] EXT4-fs (dm-0): orphan cleanup on readonly fs [ 118.968716] EXT4-fs (dm-0): ext4_orphan_cleanup: deleting unreferenced inode 790044 [ 118.968761] EXT4-fs (dm-0): ext4_orphan_cleanup: deleting unreferenced inode 790012 [ 118.968768] EXT4-fs (dm-0): ext4_orphan_cleanup: deleting unreferenced inode 790011 [ 118.968775] EXT4-fs (dm-0): ext4_orphan_cleanup: deleting unreferenced inode 790010 [ 118.968782] EXT4-fs (dm-0): ext4_orphan_cleanup: deleting unreferenced inode 790009 [ 118.968788] EXT4-fs (dm-0): 5 orphan inodes deleted [ 118.968794] EXT4-fs (dm-0): recovery complete [ 118.979150] EXT4-fs (dm-0): mounted filesystem with ordered data mode [ 119.293543] udev[204]: starting version 164 [ 119.366778] input: PC Speaker as /devices/platform/pcspkr/input/input1 [ 119.436417] Error: Driver 'pcspkr' is already registered, aborting... [ 124.153241] Adding 4194296k swap on /dev/xvdb1. Priority:-1 extents:1 across:4194296k SS [ 125.156599] loop: module loaded [ 138.650657] EXT4-fs (dm-21): Ignoring delalloc option - requested data journaling mode [ 138.650959] EXT4-fs (dm-21): mounted filesystem with journalled data mode [ 138.660092] EXT4-fs (dm-22): mounted filesystem with ordered data mode [ 138.674436] kjournald starting. Commit interval 5 seconds [ 138.675145] EXT3 FS on xvda1, internal journal [ 138.675155] EXT3-fs: mounted filesystem with journal data mode. [ 138.728462] EXT4-fs (xvdc): mounted filesystem without journal [ 138.745406] EXT4-fs (dm-17): mounted filesystem with ordered data mode [ 138.748531] EXT4-fs (dm-18): mounted filesystem with ordered data mode [ 138.774667] EXT4-fs (dm-19): mounted filesystem with ordered data mode [ 138.780834] EXT4-fs (dm-2): Ignoring delalloc option - requested data journaling mode [ 138.781400] EXT4-fs (dm-2): mounted filesystem with journalled data mode [ 138.784700] EXT4-fs (dm-1): Ignoring delalloc option - requested data journaling mode [ 138.784773] EXT4-fs (dm-1): mounted filesystem with journalled data mode [ 138.790320] EXT4-fs (dm-4): Ignoring delalloc option - requested data journaling mode [ 138.790871] EXT4-fs (dm-4): mounted filesystem with journalled data mode [ 138.794955] EXT4-fs (dm-3): Ignoring delalloc option - requested data
Bug#592550: support for SSH-Key authentication (Supports Eucalyptus and Amazon EC2)
Package: network-console
Severity: normal
Tags: patch
I've spent some time fiddling with this feature, and I've prepared a
modified patch that makes the feature more secure and easier to use.
The modified installer now retrieves a public-ip-url and displays that
address in the console output instead of the IP found on the network
interface. This correctly interoperates with Eucalyptus and Amazon EC2.
In those environments you would use the following bit of preseed:
d-i network-console/password-disabled boolean true
d-i network-console/public-ip-url string \
http://169.254.169.254/2007-01-19/meta-data/public-ipv4
d-i network-console/public-key-url string \
http://169.254.169.254/2007-01-19/meta-data/public-keys/0/openssh-key
I'm also in the process of working on a small Debian-Installer patch to
automatically prepare a partially-preseeded D-I image following those
conventions.
I've built a modified network-console with this patch into a slightly
patched Debian-Installer and successfully used it to begin a network
install on an Amazon EC2 instance.
There are still several partitioning and bootloader-related things which
don't work yet, but this part seems to be fully functional.
Cheers,
Kyle Moffett
diff -ruN a/debian/network-console.postinst b/debian/network-console.postinst
--- a/debian/network-console.postinst 2010-02-15 00:11:01.0 -0500
+++ b/debian/network-console.postinst 2010-08-11 16:27:24.0 -0400
@@ -26,6 +26,41 @@
;;
esac
+## Helper function
+download_ssh_keys()
+{
+ ## Don't do anything if no URL was specified or there are
+ ## preexisting SSH keys already in the initramfs
+ [ -n $1 -a ! -f /.ssh/authorized_keys ] || return 0
+
+ ## First make sure the directory is OK
+ [ -d /.ssh ] || mkdir /.ssh
+ chmod 700 /.ssh
+
+ ## Next, download the file
+ if wget -q -O /.ssh/authorized_keys $1; then
+ chmod 0644 /.ssh/authorized_keys || true
+ return 0
+ fi
+
+ ## Handle errors appropriately
+ db_subst $TEMPLATE_ROOT/public-key-fetch-failure LOCATION $1
+ db_input critical $TEMPLATE_ROOT/public-key-fetch-failure || true
+ db_go
+ exit 1
+}
+
+db_get $TEMPLATE_ROOT/public-key-url
+download_ssh_keys ${RET}
+
+db_get $TEMPLATE_ROOT/password-disabled
+if [ x${RET} = xtrue ]; then
+ CRYPT_PASSWORD='*'
+ PASSWORD='*DISABLED*'
+else
+ PASSWORD=''
+fi
+
while [ -z $PASSWORD ]; do
db_input critical $TEMPLATE_ROOT/password || true
COMPARE_PW=''
@@ -44,6 +79,7 @@
continue
fi
PASSWORD=$INST_PW
+ CRYPT_PASSWORD=$(gen-crypt $PASSWORD)
db_set $TEMPLATE_ROOT/password
db_set $TEMPLATE_ROOT/password-again
@@ -51,7 +87,7 @@
db_fset $TEMPLATE_ROOT/password-again seen false
done
-echo installer:$(gen-crypt $PASSWORD):1:0:9:7::: /etc/shadow
+echo installer:${CRYPT_PASSWORD}:1:0:9:7::: /etc/shadow
KEY_FINGERPRINT=$(ssh-keygen -l -f $KEY_FILE | cut -f2 -d ' ')
@@ -62,6 +98,15 @@
IPADDR=$(ip addr | grep '^[[:space:]]*inet ' | grep -v 127\.0\. | \
head -n 1 | sed 's/.*inet \([0-9.]*\).*/\1/')
+
+## If executed in a virtual hosting environment we might have a NAT'ed
+## public IP address. If so, we should figure out what it is.
+db_get $TEMPLATE_ROOT/public-ip-url
+if [ -n ${RET} ]; then
+ publicip=$(wget -q -O - ${RET} || true)
+ [ -z ${publicip} ] || IPADDR=${publicip}
+fi
+
db_subst $TEMPLATE_ROOT/start ip $IPADDR
db_subst $TEMPLATE_ROOT/start fingerprint $KEY_FINGERPRINT
case $ARCHDETECT in
diff -ruN a/debian/network-console.templates b/debian/network-console.templates
--- a/debian/network-console.templates 2009-07-21 01:55:09.0 -0400
+++ b/debian/network-console.templates 2010-08-11 16:33:01.0 -0400
@@ -60,6 +60,13 @@
The two passwords you entered were not the same. Please enter a password
again.
+Template: network-console/password-disable
+Type: boolean
+Description: for internal use; can be preseeded
+ Disable password-based SSH login, require the use of public-keys.
+ .
+ See also network-console/public-key-url
+
Template: network-console/start
Type: note
# :sl2:
@@ -75,3 +82,27 @@
.
Please check this carefully against the fingerprint reported by
your SSH client.
+
+Template: network-console/public-key-url
+Type: string
+Description: for internal use; can be preseeded
+ What URL contains a list of authorized SSH public keys?
+ .
+ The file at the given URL should be of the same form as a standard OpenSSH
+ authorized_keys file.
+
+Template: network-console/public-key-fetch-failure
+Type: error
+# :sl2:
+_Description: Could not fetch OpenSSH authorized keys
+ An error occurred while fetching OpenSSH authorized keys from ${LOCATION}.
+ .
+ Check /var/log/syslog or see virtual console 4 for the details.
+
+Template: network-console/public-ip-url
+Type: string
+Description: for internal use; can be preseeded
+ What URL contains the public IP address to be displayed on the console?
+ .
+ The file at the given URL should be a simple plain-text IP address.
+
Bug#592550: Provide support for SSH-Key authentication (Supports Eucalyptus and Amazon EC2)
Package: network-console Severity: wishlist When performing partially-automated virtual-server installations (using services such as Eucalyptus or Amazon EC2, for example), it's not really practical or secure to use password-based authentication for the installer. Furthermore, such virtual server environments provide an automatic method of provisioning public SSH keys during the installation process via an HTTP URL. The Ubuntu guys seem to have a patch for this that never got merged: https://bugs.launchpad.net/ubuntu/+source/network-console/+bug/184108 For example, access to the following URL from an Amazon EC2 instance will retrieve the SSH public key assigned during instance creation. With the Ubuntu patch above I can just directly preseed this URL: http://169.254.169.254/2010-06-15//meta-data/public-keys/0/openssh-key Cheers, Kyle Moffett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592428: Fix 2.6.32 XEN guest on old buggy RHEL5/EC2 hypervisor (XSAVE)
Package: linux-2.6
Severity: normal
Tags: patch
Would it be possible to apply the attached Fedora/Ubuntu kernel patch
to Debian as well? The Fedora link is:
http://cvs.fedoraproject.org/viewvc/F-13/kernel/fix_xen_guest_on_old_EC2.patch
And the Ubuntu link:
http://kernel.ubuntu.com/git?p=rtg/ubuntu-maverick.git;a=commit;h=1a30f99
As far as I can tell, no released version of Xen currently supports
XSAVE, so this change is effectively a NOP on all newer hypervisors, but
it allows functionality on older hypervisors (such as RHEL5, or when
running on Amazon's EC2 service).
In particular, I'm trying to write a script that packages up a vmlinuz
and initrd.gz from the Debian-Installer to allow them to be easily run
unmodified in an Amazon EC2 VM (now that Amazon supports using your own
custom kernel).
Cheers,
Kyle Moffett
Legacy hypervisors (RHEL 5.0 and RHEL 5.1) do not handle guest writes to
cr4 gracefully. If a guest attempts to write a bit of cr4 that is
unsupported, then the HV is so offended it crashes the domain. While
later guest kernels (such as RHEL6) don't assume the HV supports all
features, they do expect nicer responses. That assumption introduced
code that probes whether or not xsave is supported early in the boot. So
now when attempting to boot a RHEL6 guest on RHEL5.0 or RHEL5.1 an early
crash will occur.
This patch is quite obviously an undesirable hack. The real fix for this
problem should be in the HV, and is, in later HVs. However, to support
running on old HVs, RHEL6 can take this small change. No impact will
occur for running on any RHEL HV (not even RHEL 5.5 supports xsave).
There is only potential for guest performance loss on upstream Xen.
---
arch/x86/xen/enlighten.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 52f8e19..6db3d67 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -802,6 +802,7 @@ static void xen_write_cr4(unsigned long cr4)
{
cr4 = ~X86_CR4_PGE;
cr4 = ~X86_CR4_PSE;
+ cr4 = ~X86_CR4_OSXSAVE;
native_write_cr4(cr4);
}
--
1.6.6.1
Bug#591408: Package ignores system libffi in /usr/include/x86_64-linux-gnu/
Package: python2.6 Version: 2.6.5+20100630-2 Severity: serious The python2.6 package passes the configure argument --with-system-ffi to try to force the build to ignore its builtin _ctypes module and instead link to the installed libffi on the system. Unfortunately due to some deficiencies in the python2.6 configure scripts it fails to detect libffi (even though it would work perfectly if compiled), and therefore builds its own embedded copy anyways. This violates Debian Policy section 4.13 (Convenience copies of code): http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles The exact failure is caused by the location of the libffi header files: /usr/include/$(gcc -dumpmachine)/ffi.h /usr/include/$(gcc -dumpmachine)/ffitarget.h These paths follow the MultiArch specification [0] and are automatically searched by GCC, so a simple #include ffi.h works automatically. Unfortunately the python2.6 package seems to search by hand for ffi.h in /usr/include and /usr/local/include, and when it does not find it in either of those locations it assumes it is not present. This also causes problems for new Debian ports which have successfully patched libffi to work under their architecture, as Python will ignore the functional system libffi and also quietly fail to build the _ctypes module, resulting in a partially-dysfunctional Python installation. Additional testing reveals that python2.5 also has this problem, although it appears to be fixed in python3.1. Cheers, Kyle Moffett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585893: FTBFS: /usr/bin/ld: cannot find -lz
Package: clp Version: 1.11.1-2 Severity: serious Your package fails to build in a minimal unstable build chroot because it attempts to link against -lz but does not build-depend on zlib1g-dev. The relevant portions of the log: Checking for already installed source dependencies... cdbs: missing debhelper: missing Using default version 7.4.20 doxygen: missing graphviz: missing coinor-libcoinutils-dev: missing Using default version 2.6.4-2 liblapack-dev: missing Checking for source dependency conflicts... Installing positive dependencies: cdbs debhelper doxygen graphviz coinor-libcoinutils-dev liblapack-dev Reading package lists... Building dependency tree... The following extra packages will be installed: bsdmainutils coinor-libcoinutils0 defoma file fontconfig fontconfig-config gettext gettext-base groff-base html2text intltool-debian libatlas-base-dev libatlas-dev libatlas3gf-base libblas-dev libblas3gf libcairo2 libcdt4 libcgraph5 libcroco3 libdatrie1 libexpat1 libfontconfig1 libfreetype6 libgd2-noxpm libgfortran3 libglib2.0-0 libgraph4 libgvc5 libgvpr1 libice6 libjpeg62 liblapack3gf libmagic1 libnewt0.52 libpango1.0-0 libpango1.0-common libpathplan4 libpcre3 libpixman-1-0 libpng12-0 libpopt0 libsm6 libthai-data libthai0 libunistring0 libx11-6 libx11-data libxau6 libxaw7 libxcb-render-util0 libxcb-render0 libxcb1 libxdmcp6 libxdot4 libxext6 libxft2 libxml2 libxmu6 libxpm4 libxrender1 libxt6 man-db po-debconf ttf-dejavu-core ucf whiptail x11-common Suggested packages: wamerican wordlist whois vacation devscripts doc-base dh-make defoma-doc psfontmgr x-ttcidfont-conf dfontmgr doxygen-doc doxygen-gui gettext-doc gsfonts graphviz-doc groff libblas-doc liblapack-doc libgd-tools ttf-japanese-gothic ttf-japanese-mincho ttf-thryomanes ttf-baekmuk ttf-arphic-gbsn00lp ttf-arphic-bsmi00lp ttf-arphic-gkai00mp ttf-arphic-bkai00mp less www-browser libmail-box-perl Recommended packages: autotools-dev libfont-freetype-perl texlive-extra-utils curl wget lynx autopoint ttf-liberation libglib2.0-data shared-mime-info libfribidi0 xml-core libmail-sendmail-perl The following NEW packages will be installed: bsdmainutils cdbs coinor-libcoinutils-dev coinor-libcoinutils0 debhelper defoma doxygen file fontconfig fontconfig-config gettext gettext-base graphviz groff-base html2text intltool-debian libatlas-base-dev libatlas-dev libatlas3gf-base libblas-dev libblas3gf libcairo2 libcdt4 libcgraph5 libcroco3 libdatrie1 libexpat1 libfontconfig1 libfreetype6 libgd2-noxpm libgfortran3 libglib2.0-0 libgraph4 libgvc5 libgvpr1 libice6 libjpeg62 liblapack-dev liblapack3gf libmagic1 libnewt0.52 libpango1.0-0 libpango1.0-common libpathplan4 libpcre3 libpixman-1-0 libpng12-0 libpopt0 libsm6 libthai-data libthai0 libunistring0 libx11-6 libx11-data libxau6 libxaw7 libxcb-render-util0 libxcb-render0 libxcb1 libxdmcp6 libxdot4 libxext6 libxft2 libxml2 libxmu6 libxpm4 libxrender1 libxt6 man-db po-debconf ttf-dejavu-core ucf whiptail x11-common [...snip...] g++ -DHAVE_CONFIG_H -I. -I`echo .` -I../inc -I`echo /src` -I`echo /inc` -I/usr/include/coin -g -O2 -g -Wall -O2 -c -o MyMessageHandler.o MyMessageHandler.cpp g++ -DHAVE_CONFIG_H -I. -I`echo .` -I../inc -I`echo /src` -I`echo /inc` -I/usr/include/coin -g -O2 -g -Wall -O2 -c -o unitTest.o unitTest.cpp /bin/bash ../../libtool --tag=CXX --mode=link g++ -g -O2 -g -Wall -O2 -lCoinUtils -o clp ClpMain.o CbcOrClpParam.o MyEventHandler.o MyMessageHandler.o unitTest.o libClp.la -lm g++ -g -O2 -g -Wall -O2 -o .libs/clp ClpMain.o CbcOrClpParam.o MyEventHandler.o MyMessageHandler.o unitTest.o ./.libs/libClp.so /usr/lib/libCoinUtils.so -llapack -lz -lbz2 -lm /usr/bin/ld: cannot find -lz collect2: ld returned 1 exit status make[3]: *** [clp] Error 1 make[3]: Leaving directory `/build/buildd-clp_1.11.1-2-powerpc-MkVGBH/clp-1.11.1/Clp/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/buildd-clp_1.11.1-2-powerpc-MkVGBH/clp-1.11.1/Clp' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/build/buildd-clp_1.11.1-2-powerpc-MkVGBH/clp-1.11.1' make: *** [debian/stamp-makefile-build] Error 2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585904: FTBFS: pkg-config: command not found
Source: sip-tester Version: 1:3.1-2 Severity: serious Tags: sid Your package fails to build inside of a minimal buildd chroot environment as pkg-config is not in Build-Depends: gcc \ -o sipp xp_parser.o message.o scenario.o screen.o call.o comp.o sipp.o stat.o actions.o variables.o infile.o deadcall.o task.o socketowner.o listener.o -ldl -lpthread -lncurses -lstdc++ -lm -L /usr/local/lib -L /usr/lib -L /usr/lib64 `pkg-config --libs gsl` /bin/sh: pkg-config: not found Cheers, Kyle Moffett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585767: Dependencies on linux-gnu or not+linux-gnu do not match armel or powerpcspe correctly
Package: dpkg Version: 1.15.7.2 Severity: important User: debian-powerpc...@breakpoint.cc Usertags: powerpcspe I'm actually a little unsure if this is a dpkg bug or a package bug, but I have had build failures from several packages which have Build-Depends like the following: (trimmed example from the gvfs-1.6.2-1 source package) libudev-dev (= 0.139) | not+linux-gnu, libfuse-dev | hurd, libhal-dev (= 0.5.10) | linux-gnu, libgdu-dev (= 2.29.0) | not+linux-gnu, libgudev-1.0-dev (= 001) | not+linux-gnu, libbluetooth-dev (= 4.0) | not+linux-gnu, libimobiledevice-dev (= 0.9.7) | hurd Unfortunately it seems like the powerpcspe and armel architectures do not provide the virtual packages linux-gnu and they do provide the virtual package not+linux-gnu, although if I change those deps to linux and not+linux then they behave as expected. This seems to be related to the fact that the triplettable entries for those architectures map them as linux-gnuspe and linux-gnueabi respectively, instead of linux-gnu. On the other hand, I'm not entirely certain those package dependencies are compliant with current Debian Policy. I believe those package dependencies should be written as follows: libudev-dev (= 0.139) [linux-any], libfuse-dev [!hurd-any], libhal-dev (= 0.5.10) [!linux-any], libgdu-dev (= 2.29.0) [linux-any], libgudev-1.0-dev (= 001) [linux-any], libbluetooth-dev (= 4.0) [linux-any], libimobiledevice-dev (= 0.97) [!hurd-any] So I guess the question is whether the linux-gnu vs. not+linux-gnu behavior is correct, or alternatively whether or not it violates policy. If the latter, perhaps dpkg-buildpackage should be patched to issue very loud warnings when those dependencies are detected as they are known to have incorrect behaviour on some platforms. Cheers, Kyle Moffett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585678: Performing a binNMU of perl causes a silently broken build
Package: perl Version: 5.10.1-13 Severity: serious When a buildd performs a binNMU of perl, the Config.pm settings are not correctly adjusted to remove references to the build directory. This causes other packages to fail to build (or sometimes silently produce bad binary packages). When performing an automated buildd-driven binNMU of Perl, the sbuild process appends +b and a number to the package version and extracts the source in a directory named like the following: /build/buildd-perl-5.10.1-13+b1-amd64-yp6DXg/perl-5.10.1/ Later, during the build process, debian/rules uses it as a regex: ./perl.static -i -pe 's!$(srcdir)/$(tmp)/!/! if /install/;' \ -e 's/^(man1ext=).*/$$1'\''1p'\''/;' \ -e 's/^(man3ext=).*/$$1'\''3pm'\''/;' \ $(lib)/Config.pm $(lib)/Config_heavy.pl Unfortunately, the + in the path is misinterpreted by perl as a regex special character, and so the regex does not match and the paths remain uncorrected. A sample build-log showing the problem may be found on the Debian-Ports unofficial site [0], however please note that the bug affects the official ports in exactly the same way. [0] http://buildd.debian-ports.org/fetch.php?pkg=perlver=5.10.1-13%2B101arch=powerpcspestamp=1276371376file=logas=raw Cheers, Kyle Moffett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579844: Missing patch
Sebastian, Sorry if I'm just blind, but I don't actually see the patch supposed to be attached to this bug; did it get omitted? Cheers, Kyle Moffett
Bug#579843: Looks good, but maybe invert the arch list?
Hmm, most of the other packages (dpkg, etc) invert that arch list, so instead of this: libselinux1-dev (= 1.28-4) [alpha amd64 arm armeb armel hppa i386 ia64 m68k mips mipsel powerpc powerpcspe ppc64 s390 sh4 sparc] They have this: libselinux1-dev (= 1.28-4) [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64] Admittedly long-term if Debian ends up supporting many non-linux platforms dpkg may need to support a better syntax, but for now mimicing dpkg WRT the selinux build-dep is probably the right way to go. Cheers, Kyle Moffett
Bug#579778: powerpcspe: Preliminary architecture port
Package: eglibc Version: 2.10.2-6 Severity: normal Tags: patch sid The 'powerpcspe' architecture is a binary-incompatible variant of PowerPC/POWER designed and supported by FreeScale and IBM. It is also known under the trade names e500/MPC8500 and e200/MPC5xx. This architecture was added to dpkg in commit feb5792 on 2010/04/30: http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=feb5792 Additional information can be found at: http://en.wikipedia.org/wiki/PowerPC_e500 http://en.wikipedia.org/wiki/PowerPC_e200 In particular, the 'powerpcspe' architecture lacks the classic FPU with dedicated FPRs found on most other PowerPC systems. It is replaced with a set of SPE instructions which perform floating-point operations on the integer registers. In an unfortunate choice of architecture design, the instructions used for the SPE operations overlap with those for the AltiVec unit on most other modern PowerPC cores. The e500v2-series chips have 64-bit GPRs, where the high 32-bits are accesible only via the special SPE instructions, allowing them to make efficient use of the double datatype. The relative rare e500v1-series chips have only 32-bit GPRs, and require software traps and emulation to support native double. The e200z3 and e200z6 chips have no support for floating point at all, but with software traps and emulation are binary-compatible with the e500-series chips. The Debian port to this architecture specifically chooses to optimize for the higher-end chips (e500v2), as most of the others are targeted at automotive applications or no longer in production. EGLIBC almost builds correctly by default for 'powerpcspe', assuming that your Debian-provided GCC was patched to install the necessary headers. The only changes necessary are to add 'powerpcspe' as a supported architecture and to enable the ports addon, which contains necessary support for the SPE floating point instructions. At this time the 'powerpcspe' architecture port is still very much an unofficial port. While we hope that will change in the future, it is entirely possible that the embedded niche of the processor will make such an official Debian port problematic. Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com --- debian/rules.d/control.mk|2 +- debian/sysdeps/powerpcspe.mk |1 + 2 files changed, 2 insertions(+), 1 deletions(-) create mode 100644 debian/sysdeps/powerpcspe.mk diff --git a/debian/rules.d/control.mk b/debian/rules.d/control.mk index b604935..6992194 100644 --- a/debian/rules.d/control.mk +++ b/debian/rules.d/control.mk @@ -2,7 +2,7 @@ control_deps := $(addprefix debian/control.in/, libc6 libc6.1 libc0.1 libc0.3 sp debian/control.in/libc6: debian/control.in/libc debian/rules.d/control.mk sed -e 's...@libc@%libc6%g' \ - -e 's...@archs@%amd64 arm armeb armel i386 m32r m68k mips mipsel powerpc ppc64 sparc sparc64 s390 hppa sh3 sh4 sh3eb sh4eb%g' $ $@ + -e 's...@archs@%amd64 arm armeb armel i386 m32r m68k mips mipsel powerpc powerpcspe ppc64 sparc sparc64 s390 hppa sh3 sh4 sh3eb sh4eb%g' $ $@ debian/control.in/libc6.1: debian/control.in/libc debian/rules.d/control.mk sed -e 's...@libc@%libc6.1%g;s...@archs@%alpha ia64%g' $ $@ diff --git a/debian/sysdeps/powerpcspe.mk b/debian/sysdeps/powerpcspe.mk new file mode 100644 index 000..567f0a7 --- /dev/null +++ b/debian/sysdeps/powerpcspe.mk @@ -0,0 +1 @@ +libc_add-ons = ports nptl $(add-ons) -- 1.7.0 ---BeginMessage--- The 'powerpcspe' architecture is a binary-incompatible variant of PowerPC/POWER designed and supported by FreeScale and IBM. It is also known under the trade names e500/MPC8500 and e200/MPC5xx. This architecture was added to dpkg in commit feb5792 on 2010/04/30: http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=feb5792 Additional information can be found at: http://en.wikipedia.org/wiki/PowerPC_e500 http://en.wikipedia.org/wiki/PowerPC_e200 In particular, the 'powerpcspe' architecture lacks the classic FPU with dedicated FPRs found on most other PowerPC systems. It is replaced with a set of SPE instructions which perform floating-point operations on the integer registers. In an unfortunate choice of architecture design, the instructions used for the SPE operations overlap with those for the AltiVec unit on most other modern PowerPC cores. The e500v2-series chips have 64-bit GPRs, where the high 32-bits are accesible only via the special SPE instructions, allowing them to make efficient use of the double datatype. The relative rare e500v1-series chips have only 32-bit GPRs, and require software traps and emulation to support native double. The e200z3 and e200z6 chips have no support for floating point at all, but with software traps and emulation are binary-compatible with the e500-series chips. The Debian port to this architecture specifically chooses to optimize for the higher-end chips (e500v2), as most of the others are targeted at automotive applications
Bug#579779: debian/rules2: Fix REVERSE_CROSS build (host == target, host != build)
Package: gcc-4.4 Version: 4.4.2-9 Severity: normal Tags: patch sid If CC is left unset, it defaults to cc and causes the compiler to be built to run on the build system instead of on the host. Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com --- debian/rules2 |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/debian/rules2 b/debian/rules2 index 623eefb..252c671 100644 --- a/debian/rules2 +++ b/debian/rules2 @@ -82,6 +82,8 @@ $(foreach v, CPPFLAGS CFLAGS CXXFLAGS FFLAGS LDFLAGS, $(if $(filter environment, ifneq ($(REVERSE_CROSS),yes) CC = $(if $(filter yes,$(with_ada)),gnatgcc,gcc) +else + CC= endif ifneq ($(distribution),Ubuntu) -- 1.7.0 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash From 759d752322be243ad06e0aef7568ae65252f4dda Mon Sep 17 00:00:00 2001 From: Kyle Moffett kyle.d.moff...@boeing.com Date: Mon, 26 Apr 2010 13:41:58 -0400 Subject: [PATCH 1/2] rules2: Fix REVERSE_CROSS build (host == target, host != build) Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com --- debian/rules2 |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/debian/rules2 b/debian/rules2 index 623eefb..252c671 100644 --- a/debian/rules2 +++ b/debian/rules2 @@ -82,6 +82,8 @@ $(foreach v, CPPFLAGS CFLAGS CXXFLAGS FFLAGS LDFLAGS, $(if $(filter environment, ifneq ($(REVERSE_CROSS),yes) CC = $(if $(filter yes,$(with_ada)),gnatgcc,gcc) +else + CC= endif ifneq ($(distribution),Ubuntu) -- 1.7.0
Bug#579780: powerpcspe: Preliminary architecture port and minor bugfix
Package: gcc-4.4
Version: 4.4.2-9
Severity: normal
Tags: sid patch
The 'powerpcspe' architecture is a binary-incompatible variant of
PowerPC/POWER designed and supported by FreeScale and IBM. It is also
known under the trade names e500/MPC8500 and e200/MPC5xx.
This architecture was added to dpkg in commit feb5792 on 2010/04/30:
http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=feb5792
Additional information can be found at:
http://en.wikipedia.org/wiki/PowerPC_e500
http://en.wikipedia.org/wiki/PowerPC_e200
In particular, the 'powerpcspe' architecture lacks the classic FPU with
dedicated FPRs found on most other PowerPC systems. It is replaced with
a set of SPE instructions which perform floating-point operations on
the integer registers.
In an unfortunate choice of architecture design, the instructions used
for the SPE operations overlap with those for the AltiVec unit on most
other modern PowerPC cores.
The e500v2-series chips have 64-bit GPRs, where the high 32-bits are
accesible only via the special SPE instructions, allowing them to make
efficient use of the double datatype.
The relative rare e500v1-series chips have only 32-bit GPRs, and
require software traps and emulation to support native double.
The e200z3 and e200z6 chips have no support for floating point at
all, but with software traps and emulation are binary-compatible with
the e500-series chips.
The Debian port to this architecture specifically chooses to optimize
for the higher-end chips (e500v2), as most of the others are targeted at
automotive applications or no longer in production.
GCC by default builds correctly with full support for the e500v2 as long
as the following options are passed to configure:
--with-cpu=8548
--enable-e500_double
--with-long-double-128
The only changes needed are to extend a few matches on powerpc ppc64
to also match powerpcspe to ensure that we include essential headers.
One of those headers in particular (spe.h) is necessary to successfully
build EGLIBC's floating-point support.
At this time the 'powerpcspe' architecture port is still very much an
unofficial port. While we hope that will change in the future, it is
entirely possible that the embedded niche of the processor will make
such an official Debian port problematic.
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
---
debian/rules.d/binary-gcc-cross.mk |4 ++--
debian/rules.d/binary-gcc.mk |2 +-
debian/rules.d/binary-java.mk |2 +-
debian/rules2 |4
4 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/debian/rules.d/binary-gcc-cross.mk
b/debian/rules.d/binary-gcc-cross.mk
index a39e84f..b642ba2 100644
--- a/debian/rules.d/binary-gcc-cross.mk
+++ b/debian/rules.d/binary-gcc-cross.mk
@@ -71,8 +71,8 @@ ifeq ($(DEB_TARGET_ARCH),m68k)
files_gcc += $(gcc_lib_dir)/include/math-68881.h
endif
-ifeq ($(DEB_TARGET_ARCH),$(findstring $(DEB_TARGET_ARCH),powerpc ppc64))
-files_gcc += $(gcc_lib_dir)/include/{altivec.h,ppc-asm.h}
+ifeq ($(DEB_TARGET_ARCH),$(findstring $(DEB_TARGET_ARCH),powerpc ppc64
powerpcspe))
+files_gcc += $(gcc_lib_dir)/include/{altivec.h,ppc-asm.h,spe.h}
endif
usr_doc_files = debian/README.Bugs \
diff --git a/debian/rules.d/binary-gcc.mk b/debian/rules.d/binary-gcc.mk
index 55af73b..20e36ff 100644
--- a/debian/rules.d/binary-gcc.mk
+++ b/debian/rules.d/binary-gcc.mk
@@ -74,7 +74,7 @@ ifeq ($(DEB_HOST_ARCH),m68k)
files_gcc += $(gcc_lib_dir)/include/math-68881.h
endif
-ifeq ($(DEB_TARGET_ARCH),$(findstring $(DEB_TARGET_ARCH),powerpc ppc64))
+ifeq ($(DEB_TARGET_ARCH),$(findstring $(DEB_TARGET_ARCH),powerpc ppc64
powerpcspe))
files_gcc += $(gcc_lib_dir)/include/{altivec.h,ppc-asm.h,spe.h}
endif
diff --git a/debian/rules.d/binary-java.mk b/debian/rules.d/binary-java.mk
index 7f0249a..f2b9f94 100644
--- a/debian/rules.d/binary-java.mk
+++ b/debian/rules.d/binary-java.mk
@@ -236,7 +236,7 @@ ifeq ($(with_standalone_gcj),yes)
files_gcj += $(gcc_lib_dir)/include/math-68881.h
endif
- ifeq ($(DEB_TARGET_ARCH),$(findstring $(DEB_TARGET_ARCH),powerpc ppc64))
+ ifeq ($(DEB_TARGET_ARCH),$(findstring $(DEB_TARGET_ARCH),powerpc ppc64
powerpcspe))
files_gcj += $(gcc_lib_dir)/include/{altivec.h,ppc-asm.h,spe.h}
endif
diff --git a/debian/rules2 b/debian/rules2
index 252c671..01bbbca 100644
--- a/debian/rules2
+++ b/debian/rules2
@@ -260,6 +260,10 @@ ifneq (,$(findstring powerpc-linux,$(DEB_TARGET_GNU_TYPE)))
endif
endif
+ifeq ($(findstring powerpcspe,$(DEB_TARGET_ARCH)),powerpcspe)
+ CONFARGS += --with-cpu=8548 --enable-e500_double --with-long-double-128
+endif
+
ifneq (,$(findstring softfloat,$(DEB_TARGET_GNU_CPU)))
CONFARGS += --with-float=soft
endif
--
1.7.0
---BeginMessage---
The 'powerpcspe' architecture is a binary-incompatible variant of
PowerPC/POWER designed and supported by FreeScale and IBM. It is also
known under the trade names e500/MPC8500 and e200/MPC5xx
Bug#579802: debian/rules: Allow cross-compilation and add nocheck
Package: openssl Version: 0.9.8m-2 Severity: wishlist Tags: patch sid -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In order to cross-compile OpenSSL, we need to override the CC environment variable with the target compiler. We also need to make sure we disable the testsuite in that case. As an added bonus, this adds support for DEB_BUILD_OPTIONS=nocheck. Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com - --- debian/rules | 19 +++ 1 files changed, 15 insertions(+), 4 deletions(-) diff --git a/debian/rules b/debian/rules index 35c883b..5319d3c 100755 - --- a/debian/rules +++ b/debian/rules @@ -15,8 +15,19 @@ package=openssl # For generating the manpages export VERSION=$(shell dpkg-parsechangelog | grep '^Version:' | sed -e 's/^.*://' -e 's/-.*//') +MAKE_TEST := make test +ifneq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS))) +MAKE_TEST := : +endif + # The binary architeture - -DEB_HOST_ARCH = $(shell dpkg-architecture -qDEB_HOST_ARCH) +export DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) +export DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) +export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) +export CC=$(DEB_HOST_GNU_TYPE)-gcc +ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE)) +MAKE_TEST := : +endif CONFARGS = --prefix=/usr --openssldir=/usr/lib/ssl no-idea no-mdc2 no-rc5 zlib enable-tlsext OPT_alpha = ev4 ev5 @@ -33,7 +44,7 @@ build-stamp: # chmod +x debian/libtool ./Configure no-shared $(CONFARGS) debian-$(DEB_HOST_ARCH) make -f Makefile all - - make test + $(MAKE_TEST) mv libcrypto.a libcrypto.static mv libssl.a libssl.static make -f Makefile clean @@ -42,7 +53,7 @@ build-stamp: set -xe; \ ./Configure shared $(CONFARGS) debian-$(DEB_HOST_ARCH)-$$opt; \ make -f Makefile all; \ - - make test; \ + $(MAKE_TEST); \ mkdir -p $$opt; \ mv libcrypto.so* libssl.so* $$opt/; \ make -f Makefile clean; \ @@ -52,7 +63,7 @@ build-stamp: ln -sf apps/openssl.pod crypto/crypto.pod ssl/ssl.pod doc/ # make -f Makefile linux-shared make -f Makefile all - - make test + $(MAKE_TEST) # strip apps/openssl # make -f Makefile clean # ./Configure --prefix=/usr --openssldir=/usr/lib/ssl no-idea no-mdc2 no-rc5 debian-$(DEB_HOST_ARCH) - -- 1.7.0 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJL207YAAoJECdZ3NOoPg7ffAsP/Ajfxm7A+YQ50HonFikxWpor pFIBAmGBRyzz/hDTNjOhF22QnfZ1I9vBfCzCY0aGzR3fIt8FrGpz3ilR31Bxd8lm PpltL0t1HFPv8w2JSJ7r3Mr9k2Le5RrgA0SkqGM6sgKSKBeJ5K22S5DIcETI3ve+ yVhkJk1QA2zOdIrUVffEuUSaNn0IvGahkAOkpTDiqNzaxijMewVcSkKcAldCrsk+ /v2SDxMLf5CCQZ3fvQun8hYhFGWgYdMbMltW2UbZr30Sju5gLMePObjk16oYiphV Y5nuU9S9LivcwhCmHWorLclAh4R0FwN4JSJ3sSYML6WWNTDHRJjIFeojtTZDtXQ7 sRA97DEK7ZEunrnFp/EoYqi/VvtV905uAxX+ooxaQDfwu3T+SiAaFZHas9EzcX7e mQAhsIl0MhtdLAtRlw8WsUnNVLJlhdTITNtojFp87IA3O6s+/3EJ5Iz8KgoRz4WF DDAGz6LHARUGA5JH5Udfy0qnoKu5EybkpxSrkM6yghB9dUMSwMTWKxfaQBxY4CUb h01dqrYp8DbvTjPxVFCzQoSLBoSgRgbZr+/08p+JWl1T+DskW1BVwllvNest0/v2 96e66ZuccU5ZI5pftYKkQU/H+8Zo3Kinttstd4GyIR1LviRd8J6O7jzSNPFQjg0p lJuMm3/xEWPvagQuab7p =zLjA -END PGP SIGNATURE- From a662747a40dd38ad7916bb541a0a1125e946d4c8 Mon Sep 17 00:00:00 2001 From: Kyle Moffett kyle.d.moff...@boeing.com Date: Wed, 28 Apr 2010 15:44:50 -0400 Subject: [PATCH 1/2] debian/rules: Allow cross-compilation (and add nocheck support) In order to cross-compile OpenSSL, we need to override the CC environment variable with the target compiler. We also need to make sure we disable the testsuite in that case. As an added bonus, this adds support for DEB_BUILD_OPTIONS=nocheck. Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com --- debian/rules | 19 +++ 1 files changed, 15 insertions(+), 4 deletions(-) diff --git a/debian/rules b/debian/rules index 35c883b..5319d3c 100755 --- a/debian/rules +++ b/debian/rules @@ -15,8 +15,19 @@ package=openssl # For generating the manpages export VERSION=$(shell dpkg-parsechangelog | grep '^Version:' | sed -e 's/^.*://' -e 's/-.*//') +MAKE_TEST := make test +ifneq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS))) +MAKE_TEST := : +endif + # The binary architeture -DEB_HOST_ARCH = $(shell dpkg-architecture -qDEB_HOST_ARCH) +export DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) +export DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) +export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) +export CC=$(DEB_HOST_GNU_TYPE)-gcc +ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE)) +MAKE_TEST := : +endif CONFARGS = --prefix=/usr --openssldir=/usr/lib/ssl no-idea no-mdc2 no-rc5 zlib enable-tlsext OPT_alpha = ev4 ev5 @@ -33,7 +44,7 @@ build-stamp: # chmod +x debian/libtool ./Configure no-shared $(CONFARGS
Bug#579805: powerpcspe: Preliminary architecture port
Package: openssl
Version: 0.9.8m-2
Severity: wishlist
Tags: patch sid
User: debian-powerpc...@breakpoint.cc
Usertags: powerpcspe
User: debian-powerpc...@breakpoint.cc
Usertags: powerpcspe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is basically identical to the PowerPC target. Additional info
about the differences between powerpc/powerpcspe can be found at the
following Debian Wiki page:
http://wiki.debian.org/PowerPCSPEPort
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
- ---
debian/patches/debian-targets.patch |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/debian/patches/debian-targets.patch
b/debian/patches/debian-targets.patch
index c350982..017fd5a 100644
- --- a/debian/patches/debian-targets.patch
+++ b/debian/patches/debian-targets.patch
@@ -1,8 +1,8 @@
- -Index: openssl-0.9.8k/Configure
+Index: openssl/Configure
===
- openssl-0.9.8k.orig/Configure2009-02-16 09:44:22.0 +0100
- -+++ openssl-0.9.8k/Configure 2009-07-19 11:37:38.0 +0200
- -@@ -320,6 +320,48 @@
+--- openssl.orig/Configure 2010-04-08 18:17:36.501004540 -0400
openssl/Configure 2010-04-08 18:18:47.957004524 -0400
+@@ -326,6 +326,49 @@
osf1-alpha-cc, cc:-std1 -tune host -O4
-readonly_strings::(unknown):::SIXTY_FOUR_BIT_LONG
RC4_CHUNK:${no_asm}:dlfcn:alpha-osf1-shared:::.so,
tru64-alpha-cc, cc:-std1 -tune host -fast
-readonly_strings::-pthread:::SIXTY_FOUR_BIT_LONG
RC4_CHUNK:${no_asm}:dlfcn:alpha-osf1-shared::-msym:.so,
@@ -37,6 +37,7 @@ Index: openssl-0.9.8k/Configure
+debian-openbsd-i386, gcc:-DL_ENDIAN -DTERMIOS -O3 -Wa,--noexecstack -g
-m486::(unknown):::BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_out_asm}:dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
+debian-openbsd-mips,gcc:-O2 -Wa,--noexecstack -g
-DL_ENDIAN::(unknown)::BN_LLONG MD2_CHAR RC4_INDEX RC4_CHAR DES_UNROLL
DES_RISC2 DES_PTR
BF_PTR:dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
+debian-powerpc,gcc:-DB_ENDIAN -DTERMIO -O3 -Wa,--noexecstack -g
-Wall::-D_REENTRANT::-ldl:BN_LLONG DES_UNROLL DES_RISC2 DES_PTR MD2_CHAR
RC4_INDEX::linux_ppc32.o::dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
++debian-powerpcspe,gcc:-DB_ENDIAN -DTERMIO -O3 -Wa,--noexecstack -g
-Wall::-D_REENTRANT::-ldl:BN_LLONG DES_UNROLL DES_RISC2 DES_PTR MD2_CHAR
RC4_INDEX::linux_ppc32.o::dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
+debian-ppc64,gcc:-m64 -DB_ENDIAN -DTERMIO -O3 -Wa,--noexecstack -g
-Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_RISC1
DES_UNROLL::linux_ppc64.o::dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
+debian-s390,gcc:-DB_ENDIAN -DTERMIO -O3 -Wa,--noexecstack -g
-Wall::-D_REENTRANT::-ldl:BN_LLONGdlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
+debian-sh3, gcc:-DL_ENDIAN -DTERMIO -O3 -Wa,--noexecstack -g
-Wall::-D_REENTRANT::-ldl:BN_LLONGdlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
- --
1.7.0
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJL21BLAAoJECdZ3NOoPg7fBdkP/ill7xWJhWuKfJAf7axULyHM
3X1Q9ELVUWO89RsqAVTdqH8SsB8U5dL1+046sBJWjFLcgIV3MGBGFX5Jm3lvy0ak
Tv9pXvrZQPpBspfGIfkFb/9g2d14ic6j4E4jE9jTUQgB+YMgNYuV/a5zdXJfzAn3
xUREjxwYKfMXmdrnjkbBmTEYao04jY7ky6rB6TDa5aBSdmeIByGdjdCenHE7x8xe
rm7ljkemcjpGKfSwC7yXx84j3c1RGkLC66b0JXCLVQdWcNdbKoa4Zcu9yVeQ7pkp
AqJHbVnhCPW6sIUUZpbLSO3M4wbuVWjAK7hPCtfIMfGSm5f3aW6CuddXXVAh9PLA
1m6ZndwGGc+mxzRuzyMg4OmVSxxDWptlnHZ8uxhxJphn5bo1Rl/IJa0RAUFI/2WZ
ez5z0/N15+y5fl1QOndCovG+7zXYxj9JNZfCnOwHjvhjyFM8qRJqGXMVFLwzuGQV
QtLgmp06EMaXDn805dZHX+3z2mXLBF0+JQ/KDXhAu1scbGQzt2zAJhLddbCGEFXC
R+LfesD5yKBrqbUkk9MaHFjC+JWZjrerekH+YoHzWC1dkrmodROZ7ONMlRJLy4fG
qjkQ2fcPuupCV2JVFk4/KMyjbjHuViniVQHvbZe/Fb1L2mpPJwSCt72bbr+OoVok
t6+7YtksfJjwtadw4vwC
=w3It
-END PGP SIGNATURE-
From 7485892a3bce2f977e9e3986895e4d5952c6a538 Mon Sep 17 00:00:00 2001
From: Kyle Moffett kyle.d.moff...@boeing.com
Date: Thu, 8 Apr 2010 18:23:27 -0400
Subject: [PATCH 2/2] powerpcspe: Preliminary architecture port
This is basically identical to the PowerPC target. Additional info
about the differences between powerpc/powerpcspe can be found at the
following Debian Wiki page:
http://wiki.debian.org/PowerPCSPEPort
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
---
debian/patches/debian-targets.patch |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/debian/patches/debian-targets.patch
b/debian/patches/debian-targets.patch
index c350982..017fd5a 100644
--- a/debian/patches/debian-targets.patch
+++ b/debian/patches/debian-targets.patch
@@ -1,8 +1,8 @@
-Index: openssl-0.9.8k/Configure
+Index: openssl/Configure
===
openssl-0.9.8k.orig/Configure 2009-02-16 09:44:22.0
Bug#575158: dpkg: Add new 'e500' architecture to triplettable and ostable
Package: dpkg Version: 1.15.5.6 Severity: wishlist Tags: patch At this time, we have the Debian binutils, gcc, and eglibc packages building cross-compilers for e500 correctly with just a few minor patches. A few other packages (libmpfr, libgmp) needed to be crossbuilt (with minor patches only to enable cross-compilation). We do not yet have a full self-hosting e500 environment constructed, but we are actively working to complete one on our development boards. I've included inline the exported git patch from our internal dpkg source tree: From: Kyle Moffett kyle.d.moff...@boeing.com Date: Tue, 23 Mar 2010 14:45:12 -0400 Subject: [PATCH] Add new 'e500' architecture to triplettable and ostable The 'e500' architecture (also called MPC85xx) is a binary-incompatible variant of PowerPC/POWER designed and supported by FreeScale and IBM. Additional information can be found at: http://en.wikipedia.org/wiki/PowerPC_e500 It has the unfortunate GNU arch triplet of powerpc-linux-gnuspe, when it should have been powerpcspe-linux-gnu or e500-linux-gnu. This causes much the same problem and has the same solution as the lpia architecture's triplet: arm-linux-gnulp. The result is a few extra entries in the ostable file to deal with the quirk. At this time the 'e500' architecture port is still very much an unofficial port. While we hope that will change in the future, it is entirely possible that the embedded niche of the processor will make such an official Debian port problematic. Signed-off-by: Kyle D Moffett kyle.d.moff...@boeing.com --- ostable |2 ++ triplettable |2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/ostable b/ostable index 2ef2cdd..989c220 100644 --- a/ostable +++ b/ostable @@ -15,8 +15,10 @@ # # Debian nameGNU name config.guess regex uclibceabi-linux linux-uclibceabilinux[^-]*-uclibceabi +uclibcspe-linuxlinux-uclibcspe linux[^-]*-uclibcspe uclibc-linux linux-uclibclinux[^-]*-uclibc gnueabi-linux linux-gnueabi linux[^-]*-gnueabi +gnuspe-linux linux-gnuspelinux[^-]*-gnuspe gnulp-linuxlinux-gnulp linux[^-]*-gnulp gnu-linux linux-gnu linux[^-]*(-gnu.*)? gnu-kfreebsd kfreebsd-gnukfreebsd[^-]*(-gnu.*)? diff --git a/triplettable b/triplettable index 1a2c666..d1eeadf 100644 --- a/triplettable +++ b/triplettable @@ -4,8 +4,10 @@ # # Debian triplet Debian arch uclibceabi-linux-arm uclibc-linux-armel +uclibcspe-linux-powerpcuclibc-linux-e500 uclibc-linux-cpu uclibc-linux-cpu gnueabi-linux-arm armel +gnuspe-linux-powerpc e500 gnulp-linux-i386 lpia gnu-linux-cpucpu gnu-kfreebsd-cpu kfreebsd-cpu -- 1.7.0 -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (990, 'stable'), (700, 'testing'), (600, 'unstable'), (500, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg depends on: ii coreutils 6.10-6 The GNU core utilities ii libc6 2.10.2-2 GNU C Library: Shared libraries ii lzma 4.43-14Compression method of 7z format in dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 0.7.25.3 Advanced front-end for dpkg -- no debconf information From 9a567d5146c6a0a25365a20a1eee0a6f77f522f2 Mon Sep 17 00:00:00 2001 From: Kyle Moffett kyle.d.moff...@boeing.com Date: Tue, 23 Mar 2010 14:45:12 -0400 Subject: [PATCH] Add new 'e500' architecture to triplettable and ostable The 'e500' architecture (also called MPC85xx) is a binary-incompatible variant of PowerPC/POWER designed and supported by FreeScale and IBM. Additional information can be found at: http://en.wikipedia.org/wiki/PowerPC_e500 It has the unfortunate GNU arch triplet of powerpc-linux-gnuspe, when it should have been powerpcspe-linux-gnu or e500-linux-gnu. This causes much the same problem and has the same solution as the lpia architecture's triplet: arm-linux-gnulp. The result is a few extra entries in the ostable file to deal with the quirk. At this time the 'e500' architecture port is still very much an unofficial port. While we hope that will change in the future, it is entirely possible that the embedded niche of the processor will make such an official Debian port problematic. Signed-off-by: Kyle D Moffett kyle.d.moff...@boeing.com --- ostable |2 ++ triplettable |2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/ostable b/ostable index 2ef2cdd..989c220 100644 --- a/ostable +++ b/ostable @@ -15,8 +15,10 @@ # # Debian nameGNU name config.guess regex
Bug#570425: rebuildd and rebuildd-job silently fail for many errors
Package: rebuildd Version: 0.3.4 Severity: important When using rebuildd-job, it will completely silently fail for many different kinds of syntax or data errors. For example, if an architecture is specified which is not enabled in the config file, it will accept the input and exit without doing anything. Connecting over the telnet interface is not much better; the error message that is returned is completely generic. I had to manually add debug messages to the python scripts to figure out where the error was. The rebuildd tool itself also has several silent failures, one of which will cause a Job object to get stuck in the BUILDING state. In the Job-run() function, for the code block that looks like this: try: proc = subprocess.Popen(cmd.split(), [.]) except Exception, error: state = 1 break state = proc.poll() If an exception occurs, such as No such file or directory, the Job will silently fail and get stuck in the BUILDING state. To fix this, I inserted code so that it looked like this: try: proc = subprocess.Popen(cmd.split(), [.]) except Exception, error: build_log.write(Unable to execute command \%s\: %s % (cmd, error)) with self.status_lock: self.status = failed_status state = 1 break state = proc.poll() -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (800, 'stable'), (700, 'testing'), (600, 'unstable'), (500, 'experimental') Architecture: powerpc (ppc64) Kernel: Linux 2.6.26-2-powerpc64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages rebuildd depends on: ii lsb-base3.2-20 Linux Standard Base 3.2 init scrip ii python 2.5.2-3 An interactive high-level object-o ii python-apt 0.7.7.1+nmu1 Python interface to libapt-pkg ii python-sqlobject0.10.2-3 Python module for SQLObject ii python-support 0.8.4lenny1 automated rebuilding support for P Versions of packages rebuildd recommends: pn pbuilder none (no description available) ii python-gdchart2 0.beta1-3.4 Python OO interface to GDChart ii python-webpy 0.230-1 Web API for Python applications Versions of packages rebuildd suggests: pn cowdancer none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570426: rebuildd unconditionally tries to send mail through localhost
Package: rebuildd Version: 0.3.4 Severity: important My rebuildd build server does not run an SMTP daemon. For sending email it uses the nullmailer package to contact an external email smarthost on the SMTP port. Locally it provides a sendmail emulation interface for compatibility. Unfortunately this means that rebuildd is unable to send emails. It unconditionally connects to localhost:25 and gets Connection Refused. Ideally it would be possible to configure rebuildd to use the local sendmail command to send email, that would ensure that it gets to the right outgoing server. Another option would be a simple configuration value for specifying an outgoing SMTP server and port. Cheers, Kyle Moffett -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (800, 'stable'), (700, 'testing'), (600, 'unstable'), (500, 'experimental') Architecture: powerpc (ppc64) Kernel: Linux 2.6.26-2-powerpc64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages rebuildd depends on: ii lsb-base3.2-20 Linux Standard Base 3.2 init scrip ii python 2.5.2-3 An interactive high-level object-o ii python-apt 0.7.7.1+nmu1 Python interface to libapt-pkg ii python-sqlobject0.10.2-3 Python module for SQLObject ii python-support 0.8.4lenny1 automated rebuilding support for P Versions of packages rebuildd recommends: pn pbuilder none (no description available) ii python-gdchart2 0.beta1-3.4 Python OO interface to GDChart ii python-webpy 0.230-1 Web API for Python applications Versions of packages rebuildd suggests: pn cowdancer none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#462588: [Pkg-openldap-devel] Bug#462588: (ITS#5341) Invalid TLSCipherSuite causes hang
On Jan 29, 2008 2:55 PM, Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Jan 29, 2008 at 11:31:43AM -0800, Quanah Gibson-Mount wrote: --On Tuesday, January 29, 2008 11:09 AM -0800 Steve Langasek [EMAIL PROTECTED] wrote: Anyway, the documented syntax for TLSCipherSuite is $cipher1:$cipher2, not $cipher1 $cipher2; but setting such values gives me a hang on startup (which should be investigated). Filed upstream: http://www.OpenLDAP.org/its/index.cgi?findid=5341 Sorry, the description of this ITS is inverted. It's *valid* ciphersuite values (i.e., cipher1:cipher2) that cause the hang; invalid space-separated values are merely truncated after the first cipher in the list, which doesn't cause a hang, it just prevents the cipher list from being useful. Steve, would you mind testing the patch I posted there? It fixed the problem for me when I wrote it a month or two ago, hopefully it will fix the problem for you too. Cheers, Kyle Moffett -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321442: kernel-source-2.6.8: fails to compile on powerpc (drivers/ide/ppc/pmac.c)
On Aug 13, 2005, at 18:54:30, LT-P wrote: Le lun 08 aoû 2005 17:57:04 CEST, Horms [EMAIL PROTECTED] a écrit: Can you please enable BLK_DEV_IDEDMA_PCI and see if that resolves your problem. If it does, then the following patch should fix Kconfig so that BLK_DEV_IDEDMA_PCI needs to be enabled for BLK_DEV_IDE_PMAC to be enabled. It should patch cleanly against Debian's 2.6.8 and Linus' current Git tree. It seems to solve the problem, thanks. Sometimes, I feel like I am the only person in the world to compile the kernel on powerpc... :) Actually, I ran into this same bug a day or so ago when updating to 2.6.13-rc6, it's just I noticed the error, fixed my config, then recompiled and forgot about it completely until now :-D. Thanks for the bug report, though! Cheers, Kyle Moffett -- I have yet to see any problem, however complicated, which, when you looked at it in the right way, did not become still more complicated. -- Poul Anderson
Bug#257079: Upstream patch for this bug
Package: make Version: 3.80-9 Followup-For: Bug #257079 I've just discovered this bug in a few of my makefiles, and in searching for a solution I discovered Debian bugs #257079 and #296482, as well as the fixed-upstream bug #1516. Here is the URL for the upstream bugreport (and patch). https://savannah.gnu.org/bugs/index.php?func=detailitemitem_id=1516 Thank you for your efforts! Cheers, Kyle Moffett -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages make depends on: ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
