Bug#1068969: csound-utils installs /usr/bin/extractor which has no manual page.
Package: csound-utils Version: 1:6.18.1+dfsg-1 Severity: normal X-Debbugs-Cc: martinw...@gmail.com extractor --help says --Csound version 6.18 (double samples) 2022-11-24 [commit: none] libsndfile-1.2.0 util extractor: Usage: extractor [-flags] soundfile Legal flags are: -o fnamesound output filename -N notify (ring the bell) when done -S integer sample number at which to start file -Z integer sample number at which to end file -Q integer number of samples to read -T fpnumtime in secs at which to start file -E fpnumtime in secs at which to end file -D fpnumduration in secs of extract -R Rewrite header -H Heartbeat -v verbose mode for debugging -- fnameLog output to file flag defaults: extractor -otest -S 0 extractor: error: unknown flag -- end of score. overall amps: 0.0 overall samples out of range:0 0 errors in performance Elapsed time at end of performance: real: 0.001s, CPU: 0.000s so I guess it's some kind of sound convertor. A manual page saying what it is and what it does and how to use it would be nice. -- System Information: Debian Release: 12.5 APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 6.1.0-15-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages csound-utils depends on: ii csound 1:6.18.1+dfsg-1 ii libc62.36-9+deb12u4 ii libcsound64-6.0 1:6.18.1+dfsg-1 ii libsamplerate0 0.2.2-3 ii libsndfile1 1.2.0-1 csound-utils recommends no packages. csound-utils suggests no packages. -- no debconf information
Bug#927337: uzbl: Please update to a to current upstream version
On 18/04/2019, Martin Guy wrote: > The v0.9.1 branch "make install"s for me, however, and that is from > October 2016. Ah. It seemed to work when I tested it, but stopped doing so when I removed the stable Debian package. Now it gives a blank screen because uzbl-event-manager fails to start. Sorry for the noise M
Bug#927337: uzbl: Please update to a to current upstream version
On Thu, 11 Apr 2019 18:35:04 +0200 Nicolas Schier wrote: > On https://github.com/uzbl/uzbl there is a tag 'v0.9.1' available, but > probably the 'master' or 'next' branch could also make sense... The master branch doesn't build on current Debian stable - "git bisect run make" thinks that the last commit that made out of the box is commit d0f0d from January 2013. The v0.9.1 branch "make install"s for me, however, and that is from October 2016. Blessings M
Bug#690568:
The help message also needs changing: # ddclient FATAL:Error loading the Perl module Digest::SHA1 needed for freedns update. FATAL: On Debian, the package libdigest-sha1-perl must be installed. # to libdigest-sha-perl cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672818: mediawiki 1.15 is very old
Package: mediawiki Version: 1:1.15.5-8 Severity: Wishlist Mediawiki 1.15 was released in 2009/10, while the current stable version is 2.19 and most non-Debianized extensions on mediawiki.org are tested with 2.18. An update would make more of these usable. Many thanks for packaging mediawiki -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#520411: Help to test libsdl1.2 bug #520411 on armel?
On 19 March 2012 14:36, Manuel A. Fernandez Montecelo wrote: >>> On Thu, Feb 16, 2012 at 09:58:33PM +, Manuel A. Fernandez Montecelo >>> wrote: Can somebody please help to check if this bug from SDL libraries is still present on armel? I don't have access to any ARM box, and the submitter cannot test it either. > Any update on this, or an estimation on when it will happen? Hi I just tried this under armel-sid on an ARM v4t card with a sound chip. It mooOOs as it should. M -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#479163: Bug is still in 1.5.8
Hi Three years on, this bug is still in the Debian package and in the upstream source for ginac-1.5.8. I've mailed the upstream list too. M -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#573712: gem: FTBFS on armel (assembler erorrs)
On 3/16/10, Adam D. Barratt wrote: > > gem fails to build on armel with assembler errors. From the build log: > > > > g++ -c-I/usr/include/lqt -fopenmp -I/usr/include/ImageMagick > -I/usr/include/lqt -I/usr/include/avifile-0.7 -I/usr/include/FTGL > -I/usr/include/freetype2 -I.. -I/usr/include/FTGL -I/usr/include/freetype2 > -g -O2 -fPIC -freg-struct-return -O3 -falign-loops=32 -falign-functions=32 > -falign-jumps=32 -funroll-loops -ffast-math -g -O2 glew.cpp -o > ../Objects/glew.o > > /tmp/ccGNAhDI.s: Assembler messages: > > /tmp/ccGNAhDI.s:1194: Error: bad immediate value for offset (4148) > > /tmp/ccGNAhDI.s:27942: Error: bad immediate value for offset (4112) Try dropping the apparently pointlessly picky options =32? M -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#513746: Same on nv driver1680x1050 but bit depth dependent?
Same here, using nv X server on nVidia RIVA-TNT with 1680x1050 screen resolution, but the same effect appears when running it in 1024x768 or 800x600, all with bit depth 16. The splash image is skewed identically to the one shown in the original attachment. Back at the origila 1650x1050, at bit depth 24 the splash image appears correctly, while at bit depth 8 it comes out flipped upside down (attached). Hope this helps you reproduce the effect M <>
Bug#547503: git-core: "git clone" fails on armel
Hi folks > >> git clone fails on my Debian armel system: Just to say, there's a 500MHz 512MB armel-sid box here n2100.martinwguy.co.uk that you can use for compilation and over ssh if that's useful - just suggest a username by private email. Good luck! M -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#548842: Apt alignment trap.
A patch has turned up for glibc-2.9. I'm trying it on eglibc-2.10...
See http://sourceware.org/ml/crossgcc/2009-11/msg8.html
--- glibc-ports-2.9/sysdeps/arm/dl-machine.h.orig 2009-11-03
22:03:57.0 +0100
+++ glibc-ports-2.9/sysdeps/arm/dl-machine.h2009-11-03 22:11:45.0
+0100
@@ -568,13 +568,22 @@
}
# endif
+union arm_unaligned_data {
+ Elf32_Addr l_addr;
+} __attribute__ ((packed));
+
auto inline void
__attribute__ ((always_inline))
elf_machine_rel_relative (Elf32_Addr l_addr, const Elf32_Rel *reloc,
void *const reloc_addr_arg)
{
- Elf32_Addr *const reloc_addr = reloc_addr_arg;
- *reloc_addr += l_addr;
+ if (((long)reloc_addr_arg) & 0x3) {
+union arm_unaligned_data *const lpdata = reloc_addr_arg;
+lpdata->l_addr += l_addr;
+ } else {
+Elf32_Addr *const reloc_addr = reloc_addr_arg;
+*reloc_addr += l_addr;
+ }
}
# ifndef RTLD_BOOTSTRAP
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#553182: libesd0 needs /dev/dsp, provided by oss-compat
Package: libesd0 Version: 0.2.41-5 libesd0 needs /dev/dsp to work, and that device is provided by the oss-compat package, so libesd0 should require oss-compat. Example: madplay requires libesd0 (>= 0.2.35) | libesd-alsa0 (>= 0.2.35) but if libesd0 is installed (and oss-compat isn't) it dies saying: audio: /dev/dsp: No such file or directory -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#548842: Apt alignment trap.
reassign 548842 gcc-4.3 4.3.4-2 thanks On 10/9/09, John Reiser wrote: > Some shared library has been built with an initialized pointer, where the > storage > for the pointer itself is not aligned on a 4-byte boundary. The problem is > not > in glibc(ld-linux); the problem lies in some shared library that the app > requires. > > Debug this via > setenv LD_DEBUG reloc > ./my_app args... Thanks! It seems to affect any C++ program on armel, including hello.cc mar...@n2100:~$ LD_DEBUG=reloc ./a.out 6836: 6836: relocation processing: /lib/libc.so.6 (lazy) 6836: 6836: relocation processing: /lib/libgcc_s.so.1 (lazy) 6836: 6836: relocation processing: /lib/libm.so.6 (lazy) 6836: 6836: relocation processing: /usr/lib/libstdc++.so.6 (lazy) Bus error and libstdc++.so.6 seems to be provided by gcc-4.3, so I'm reassigning the bug... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546823: __thread usage in libcap-ng0 broken on armel
On 9/28/09, Pierre Chifflier wrote: > On Sat, Sep 26, 2009 at 04:28:36PM +0100, Simon McVittie wrote: > > ARM porters: can you shed any light on this? > As I have no armel platform here (and no knowledge specific to the > architecture), some help would be appreciated. There is a big fast armel box here you can use over ssh. Just suggest a username by private email. It is also set to give Bus Error on misaligned data accesses instead of the default behaviour of returning garbage values, which often helps catch mysterious bugs. M -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547525: FTBFS on armel: 'OV_CALLBACKS_STREAMONLY' undeclared
On 9/21/09, Martin Guy wrote: > I just tried this, and it's doing a misaligned word access: Sorry, my mistake. It's pumping misaligned half-word (16-bit) accesses, which again returns some form of garbage, probably either the correct value if it's from the middle of a 4-byte word or some combination of the word's top and bottom bytes if the halfword straddles a 4-byte boundary. The fixup trap is incredibly slow, so the whole test will take 3 hours but the first 65536 bytes of output are identical to the i386 output, which suggests that this is it M -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547525: FTBFS on armel: 'OV_CALLBACKS_STREAMONLY' undeclared
On 9/21/09, Daniel Kahn Gillmor wrote: > I should note that i have some concerns about tremor on armel in general > that haven't been addressed by upstream (and i haven't been able to sort > out): > > http://lists.xiph.org/pipermail/tremor/2009-April/001564.html > > Maybe this update will cover those changes as well. I just tried this, and it's doing a misaligned word access: $ gdb ./ivorbisfile_example.armel (gdb) run < *ogg > armel Starting program: /home/martin/cluster/arm/libvorbisidec-debug-2009-04-24/ivorbisfile_example.armel < *ogg > armel Bitstream is 2 channel, 44100Hz Decoded length: 324300 samples Encoded by: Xiph.Org libVorbis I 20070622 Program received signal SIGBUS, Bus error. 0x4004eaa0 in ov_read () from /usr/lib/libvorbisidec.so.1 (gdb) To get the bus error you need to have # echo 5 > /proc/cpu/alignment the default setting (0) silently returns junk, specifically, the word from addr&~3 rotated by (addr&3)*8 bits, which is less than useful. Another setting, 3, catches the alignment trap, fakes "the right thing" in the kernel and returns what you would get on a byte-aligned machine; that would quickly tell you whether fixing the alignment error will fix the problem. M -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547525: FTBFS on armel: 'OV_CALLBACKS_STREAMONLY' undeclared
On 9/20/09, Luk Claes wrote: > Maybe it's an option to revert using libvorbisidec-dev and use > libvorbis-dev again on armel to fix the FTBFS of mpd? > > debian-arm and Joey Cc-ed so they can give input as I'm unsure if > current ARM hardware does have floating point support to make this > reasonable. armel is soft-float so yes, being able to use tremor would give a huge speed increase. M -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#540522: Patch to enable fixed-point on arm*
Here's a patch to enable fixed point on arm*, tested for correct operation on arm, armel and i386. --- libgsm-1.0.12/debian/rules.old 2009-08-12 10:21:37.0 +0100 +++ libgsm-1.0.12/debian/rules 2009-08-12 10:33:46.0 +0100 @@ -4,7 +4,7 @@ .PHONY: build clean binary binary-indep binary-arch -ifeq ($(DEB_HOST_ARCH),arm) +ifneq (,$(filter arm%,$(DEB_HOST_ARCH))) MULTYPE='' else MULTYPE='-DUSE_FLOAT_MUL' -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#540522: Please use integer multiply on new armel arch too
Package: libgsm Version: 1.0.12-1 Severity: wishlist debian/rules has ifeq ($(DEB_HOST_ARCH),arm) MULTYPE='' else MULTYPE='-DUSE_FLOAT_MUL' endif and that should include "armel" to use integer code there also. The resulting encoder is 6.6 times faster than the softfloat it is currently using. cheers M -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#518592: comment from llvm-dev list
On the llvm-dev mailing list in message http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/024629.html Anton Korobeynikov says: > 518592: Sounds like compiler / linker problem, it's not LLVM related at all -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511721: comment from llvm-dev list
On the llvm-dev mailing list in message http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/024629.html Anton Korobeynikov says: > 511721: I believe it should be fixed on ToT. (Top of Tree). They expect to release 2.6 in about a month and a half from now. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539496: see 520351
This story continues in #520351 (2.5 FTBFS on armel) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539496: comment from llvm-dev list
On the llvm-dev mailing list in message http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/024629.html Anton Korobeynikov says: > 539496: There are no plans to support ARMv4 in LLVM. As for ToT ARM > builds of llvm-gcc (both for bare-metal arm-elf and normal > arm-none-linux-gnueabi triples) is broken due to two PRs: 4680, 4681 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#478535: comment from llvm-dev list
On the llvm-dev mailing list in message http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/024629.html Anton Korobeynikov says: > 478535: there are no plans to support of legacy IBM S390 platform, > only 64 bit one (that's s390x in tartget triple). The current plans > are to use clang only, not llvm-gcc, however I might be able to find > few hours to give llvm-gcc a try. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#520351: llvm-gcc-4.2-2.5 fails to build from source on arm: MACHO_DYNAMIC_NO_PIC_P undeclared
This patch get past message#15's error. Now it goes on to build stage2 gcc and dies running genmodes: build/genmodes -h > tmp-modes.h /bin/sh: line 1: 15618 Floating point exception make[4]: *** [s-modes-h] Error 136 make[4]: Leaving directory `/home/martin/arm/llvm-gcc-4.2-2.5/build-gcc/gcc' The failing program under gdb: ~/arm/llvm-gcc-4.2-2.5/build-gcc/gcc$ gdb build/genmodes GNU gdb 6.8-debian ... This GDB was configured as "arm-linux-gnueabi"... Breakpoint 1 at 0xa58c Breakpoint 2 at 0xa528 Breakpoint 3 at 0x87ec Breakpoint 4 at 0x86cc (gdb) run -h Starting program: /home/martin/arm/llvm-gcc-4.2-2.5/build-gcc/gcc/build/genmodes -h Program received signal SIGFPE, Arithmetic exception. 0x4006f3e8 in raise () from /lib/libc.so.6 (gdb) bt #0 0x4006f3e8 in raise () from /lib/libc.so.6 #1 0xc1c8 in __div0 () at ../../llvm-gcc-4.2-2.5/gcc/config/arm/lib1funcs.asm:1145 #2 0xb874 in L12 () at ../../llvm-gcc-4.2-2.5/gcc/config/arm/lib1funcs.asm:885 #3 0x8c54 in main () (gdb) I quit at this point. On the llvm-devmailing list, Anton Korobeynikov writes today: > both ppc and arm were broken at the time for 2.5 release. > > Hopefully things will be much better with the coming 2.6 release, at > least one might expect arm and ppc to be more or less ok. ia64 support > was completely dropped and sparc should be brokens as of time of 2.5. > > You might want to stick with next 2.6 release, which is scheduled to > be out within next 1.5 months FTBFS bug fix for llvm-gcc-4.2-2.5. While linking cc1-dummy: libbackend.a(arm.o): In function `current_file_function_operand': /home/martin/arm/llvm-gcc-4.2-2.5/build-gcc/gcc/../../llvm-gcc-4.2-2.5/gcc/config/arm/arm.c:3506: undefined reference to `ENCODED_SHORT_CALL_ATTR_P' libbackend.a(arm.o): In function `arm_is_longcall_p': /home/martin/arm/llvm-gcc-4.2-2.5/build-gcc/gcc/../../llvm-gcc-4.2-2.5/gcc/config/arm/arm.c:3581: undefined reference to `ENCODED_LONG_CALL_ATTR_P' collect2: ld returned 1 exit status Definitions fished out of the 2.2 release. Martin Guy 4 August 2009 --- a/llvm-gcc-4.2-2.5/gcc/config/arm/arm.h 2009-08-02 22:43:26.0 +0100 +++ b/llvm-gcc-4.2-2.5/gcc/config/arm/arm.h 2009-08-04 12:31:24.0 +0100 @@ -1867,9 +1867,15 @@ #define SHORT_CALL_FLAG_CHAR '^' #define LONG_CALL_FLAG_CHAR '#' +#define ENCODED_SHORT_CALL_ATTR_P(SYMBOL_NAME) \ + (*(SYMBOL_NAME) == SHORT_CALL_FLAG_CHAR) + #define SYMBOL_SHORT_CALL_ATTR_P(SYMBOL) \ (SYMBOL_REF_FLAGS (SYMBOL) & SYMBOL_SHORT_CALL) +#define ENCODED_LONG_CALL_ATTR_P(SYMBOL_NAME) \ + (*(SYMBOL_NAME) == LONG_CALL_FLAG_CHAR) + #define SYMBOL_LONG_CALL_ATTR_P(SYMBOL) \ (SYMBOL_REF_FLAGS (SYMBOL) & SYMBOL_LONG_CALL)
Bug#539496: armel build still fails
Still doesn't succeed. With the last patch included, it carries on only to fail a few hours later when linking cc1-dummy, saying: libbackend.a(arm.o): In function `current_file_function_operand': /home/martin/arm/llvm-gcc-4.2-2.5/build-gcc/gcc/../../llvm-gcc-4.2-2.5/gcc/config/arm/arm.c:3506: undefined reference to `ENCODED_SHORT_CALL_ATTR_P' libbackend.a(arm.o): In function `arm_is_longcall_p': /home/martin/arm/llvm-gcc-4.2-2.5/build-gcc/gcc/../../llvm-gcc-4.2-2.5/gcc/config/arm/arm.c:3581: undefined reference to `ENCODED_LONG_CALL_ATTR_P' M -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#520351: llvm-gcc-4.2-2.5 fails to build from source on arm: MACHO_DYNAMIC_NO_PIC_P undeclared
Hi The fix is very simple: the defaulting of this macro to 0 in gcc/config/arm/arm.h, present in 2.2 has been omitted in 2.5. The attached patch puts the defaulting clause back, the same as it was in 2.2 M --- a/llvm-gcc-4.2-2.5/gcc/config/arm/arm.h 2008-11-03 01:44:11.0 + +++ b/llvm-gcc-4.2-2.5/gcc/config/arm/arm.h 2009-08-02 22:43:26.0 +0100 @@ -31,6 +31,9 @@ #ifndef TARGET_MACHO #define TARGET_MACHO 0 #endif +#ifndef MACHO_DYNAMIC_NO_PIC_P +#define MACHO_DYNAMIC_NO_PIC_P 0 +#endif /* APPLE LOCAL end ARM darwin target */ /* APPLE LOCAL ARM interworking */
Bug#539496: Acknowledgement (armel llvm-gcc-4.2-generated executables give illegal instruction on armv4t CPUs)
Yes, changing the default cpu in its copy of the gcc source fixed the issue. Here is the extra patch file to add into llvm-gcc-4.2-2.5/debian/patches I've built and tested this with llvm-gcc-4.2-2.2 but the issue is the same in 2.5 (and the attached patch file is modified to apply to -2.5) FWIW, a fixed deb package of llvm-gcc-4.2-2.2 for armel (and a similar patch for the -2.2 source tree) can be found under http://simplemachines.it/debian/armel-lenny M Debian armel's minimum CPU is armv4t but standard GCC for EABI sets a default arch of armv5t, which causes llvm-gcc's libgcc.a to contain illegal "clz" instructions. This fixes that, the same way as the Debian GCC package. Adapted from the gcc-4.3 dpatch file by Martin Guy , 1 August 2009 --- a/llvm-gcc-4.2-2.5/gcc/config/arm/linux-eabi.h 2007-11-24 12:37:38.0 + +++ b/llvm-gcc-4.2-2.5/gcc/config/arm/linux-eabi.h 2007-11-24 12:39:41.0 + @@ -45,7 +45,7 @@ The ARM10TDMI core is the default for armv5t, so set SUBTARGET_CPU_DEFAULT to achieve this. */ #undef SUBTARGET_CPU_DEFAULT -#define SUBTARGET_CPU_DEFAULT TARGET_CPU_arm10tdmi +#define SUBTARGET_CPU_DEFAULT TARGET_CPU_arm9tdmi #undef SUBTARGET_EXTRA_LINK_SPEC #define SUBTARGET_EXTRA_LINK_SPEC " -m armelf_linux_eabi"
Bug#539496: armel llvm-gcc-4.2-generated executables give illegal instruction on armv4t CPUs
Package: llvm-gcc-4.2
Version: 2.2-1
Hi, and thanks for packaging a great compiler!
I just found one fairly simple portability problem on armel architecture:
The minimum ARM ISA that Debian armel runs on is armv4t, and Debian
armel gcc by default generates armv4t output but executables created
with llvm-gcc die on armv4t CPUs with "Illegal instruction",
specifically "clz" (which is armv5t and above).
Although llvm itself seems to be correctly generating armv4t code by
default (checked by seeing the default arch setting in the llvm source
and by scanning all .o's in a LAME build), the version of libgcc.a
that it links against has been compiled for armv5t, and contains "clz"
instructions in the libgcc integer div(/mod) and softfloat support
functions:
__aeabi_{uidiv,uidivmod,idiv,idivmod,l2f}
__umodsi3 __modsi3 __adddf3 __addsf3
Repeat-by (on an armv4t host):
cat > c.c << EOF
main() {return foo(2);}
foo(int a) { return(12/a);}
EOF
llvm-gcc c.c
./a.out
Illegal instruction
To identify all affected libraries installed on an armel system:
find /usr/lib/llvm -name '*.a' | while read a
do
objdump -d $a | egrep -q '\' && echo $a
done
/usr/lib/llvm/gcc-4.2/lib/gcc/arm-linux-gnueabi/4.2.1/kext/libgcc.a
/usr/lib/llvm/gcc-4.2/lib/gcc/arm-linux-gnueabi/4.2.1/static/libgcc.a
/usr/lib/llvm/gcc-4.2/lib/gcc/arm-linux-gnueabi/4.2.1/libgcc.a
/usr/lib/llvm/gcc-4.2/lib/libstdc++.a
It looks from the llvm scripts that it is building a native GCC and
using that to compile the gcc libraries. If so, the following may be
relevant:
I know that the GCC source as supplied defaults to armv5t for ARM-EABI
and that Debian gcc has a patch to fix this (attached).
If the llvm-gcc build script builds a native version of gcc and builds
the GCC libraries using that, then adding a version of this to the
llvm-gcc debian patches should sort it out.
I'm assuming 2.5 has the same problem as 2.2, since the debian
changelog says nothing about this.
There is a 600MHz 512MB armv5t Debian armel box here that can be used
for compiling and a 200MHz 64MB armv4t board for testing, both on 24/7
and accessible via ssh. If that would be useful, please write
privately suggesting a username.
Cheers
M
arm-unbreak-eabi-armv4t.dpatch
Description: Binary data
Bug#536485: mkimage has no manual page
Package: uboot-mkimage Version: 0.4 the mkimage program has no manual page or documentation other than the terse --help output. Isn't provision of a man page debian policy? cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#443052: Galeon goes into an infinite loop saving a page that contains …
On 7/9/09, Fabio Bonelli wrote: > Can't reproduce this with galeon 2.0.7-1. Is it fixed for you as well? Confirmed. It is also fixed in the version in lenny, 2.0.6 cheers M -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#453009: closed by Filippo Giunchedi (Bug#453009: fixed in varkon 1.18B-1)
Confirmed now builds fine on armel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531188: iconvconfig has a misaligned pointer access on arm
Package: libc6 Version: 2.7-18 Severity: minor While apt-get upgrading an arm-lenny system I see the following: - Checking init scripts... /var/lib/dpkg/info/libc6.postinst: line 343: 2254 Bus error iconvconfig - This occurs because I have detection of misaligned word accesses enabled on my arm box (echo 5 > /proc/cpu/alignment) whereas such accesses normally give garbage results, returning the word from *(addr & ~3) rotated so that the byte at *(char *)addr is in the least significant position. The offending instruction is (gdb) x/i 0x989c 0x989c : ldr r2, [r5] where r5 0x5875e 362334 (should be a multiple of 4). With libc6-dbg installed: Program received signal SIGBUS, Bus error. 0x989c in write_output () (gdb) bt #0 0x989c in write_output () #1 0xa7dc in main () which suggests that on most Debian ARM machines some piece(s) of 4-byte data are being written to somewhere half-word-swapped. Strangely enough, the same symptom does not occur with the same version of libc6 on armel-lenny (only arm-lenny) on the same machine. Repeat-by: # iconvconfig Bus error # -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#525261: use of FPU_SETCW or FPU_GETCW causes illegal instruction on armel
Package: glibc
Version: 2.9-7
/usr/include/fpu_control.h on armel defines FPU_[SG]ETCW as VFP
coprocessor instructions, whereas armel is soft-float.
#define _FPU_GETCW(cw) \
__asm__ __volatile__ ("mrc p10, 7, %0, cr1, cr0, 0" : "=r" (cw))
/* This is fmxr fpscr, %0. */
#define _FPU_SETCW(cw) \
__asm__ __volatile__ ("mcr p10, 7, %0, cr1, cr0, 0" : : "r" (cw))
Packages that use these cause an illegal instruction trap on hardware
that does not have a VFP unit (and misleadingly set the FPU control
word on those that do, while softfloat remains unaffected).
This was highlighted by build failure of gerris - see Drew Parsons' messages in
http://lists.debian.org/debian-arm/2009/04/msg00018.html
He suggests that the right thing for fpu_control.h may be simply not
to define these macros but I don't know if that's right.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#515949: libvorbis patch for armel
Of the flags that -ffast-math sets, turning -ffinite-math-only off again avoids the erroneous optimization. With the attached patch, libvorbis's examples/encoder_example produces the same (correct) output as on arm-oldabi and it makes oggenc work on armel too. M On armel, oggenc creates short output files that decode to the correct amount of silence. This is caused by an optimization bug present in gcc 4.[123] that miscompiles the MAX(x,y) macro, optimizing it away completely. Fixes: http://bugs.debian.org/515949 Analysis: https://trac.xiph.org/ticket/1526 Martin Guy March 2009 --- libvorbis-1.2.0.dfsg/configure.in.old 2007-07-25 17:27:00.0 +0100 +++ libvorbis-1.2.0.dfsg/configure.in 2009-03-19 07:44:38.0 + @@ -168,6 +168,12 @@ CFLAGS="-O20 -D__NO_MATH_INLINES -fsigned-char" PROFILE="-O20 -g -pg -D__NO_MATH_INLINES -fsigned-char" ;; esac + + # Avoid an optimization bug in gcc-4.[123] + case $host in + arm*-*-linux-gnueabi) + CFLAGS+=" -fno-finite-math-only" ;; + esac fi CFLAGS="$CFLAGS $cflags_save" --- libvorbis-1.2.0.dfsg/configure.old 2007-07-25 17:46:37.0 +0100 +++ libvorbis-1.2.0.dfsg/configure 2009-03-19 07:45:54.0 + @@ -19484,6 +19484,12 @@ CFLAGS="-O20 -D__NO_MATH_INLINES -fsigned-char" PROFILE="-O20 -g -pg -D__NO_MATH_INLINES -fsigned-char" ;; esac + + # Avoid an optimization bug in gcc-4.[123] + case $host in + arm*-*-linux-gnueabi) + CFLAGS+=" -fno-finite-math-only" ;; + esac fi CFLAGS="$CFLAGS $cflags_save"
Bug#460084: New info in #460084
On 3/18/09, Adrian Knoth wrote: > By the way: jackd's architecture list is "any", and I see packages for > armel in both, lenny and sid. > > Am I missing the point or what do you want us to change? It is built for any architecture but in its build dependencies for libasound2-dev libcap-dev libraw1394-dev libfreebob0-dev it specified [i386 ia64 alpha amd64 armeb arm hppa m32r m68k mips mipsel powerpc ppc64 s390 s390x sh3 sh3eb sh4 sh4eb sparc] which doesn't include armel, so the package on armel builds without these facilities, thatnks to "configure". These packages are available in armel, so either armel needs adding to those four long lists or, if the intention is to exclude the freebsd- and hurd- variants Architecture: [linux-any] will work (and is what is meant) Cheers M -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519275: purging gkrellmd does recursive descent of entire file tree
On 3/17/09, Sandro Tosi wrote: > On Tue, Mar 17, 2009 at 20:50, Martin Guy wrote: > >> > deluser --remove-all-files gkrellmd > >> > >> Since the package version above, the script uses "--system". > > > > why? Does gkrellmd crap random files all over the root filesystem? > > It seems excessive, unnecessary and dangerous. > > > err, what?? Sorry, I misunderstood, thinking you had added --system to the --remove-all-files option. I have now downloaded the source package for sid and see that --remove-all-files has indeed gone. My apologies M -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#460084: New info in #460084
Thanks. No, on Debian armel: mar...@n2100:~$ cc c.c /tmp/cc3HLk7a.o: In function `main': c.c:(.text+0x18): undefined reference to `__sync_bool_compare_and_swap_4' collect2: ld returned 1 exit status mar...@n2100:~$ gcc --version gcc (Debian 4.3.2-1.1) 4.3.2 In Debian, the arch setting is automatically armv4t, and using a higher -march setting doesn't seem to help (but I guess that's a libgcc issue) I just tried building the lenny package and it does build OK on armel. M -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#515949: vorbis encoder is broken on armel
Upstream bug report is https://trac.xiph.org/ticket/1526 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#515949: vorbis encoder is broken on armel
This is bizarre. If I run oggenc on an ep9312 (armv4t) chip, I get an .ogg file that reproduces the sound correctly, but is significantly different (75% of the size) from the same encoding performed on x86, while on an Xscale (armv5te) and Cortex-a8 (armv7) I get different results again, and the ogg files are full of junk and decode to silence.. These are all up-to-date debian-armel-lenny installations with the same versions of vorbis-tools (1.2.0-5), libogg (1.1.3-4) and libvorbis0a libvorbisenc2 libvorbisfile3 (1.2.0.dfsg-3.1) installed. -rw-r--r-- 1 martin martin 346624 Mar 12 13:29 Happy-x86.ogg -rw-r--r-- 1 martin martin 262144 Mar 12 14:19 Happy-ep9312.ogg -rw-r--r-- 1 martin martin 186510 Mar 12 14:50 Happy-xscale.ogg -rw-r--r-- 1 martin martin 186510 Mar 12 14:55 Happy-cortex.ogg The ep9312, xscale and cortex boards are all using softfloat, which is 100% IEEE compliant, while the x86 performs intermediate calculations to 80 bits' precision instead of 64. Another difference is that the machines are running different versions of the linux kernel ep9312: 2.6.25 (custom compilation for TS7250 board) xscale: 2.6.26-1-iop32x (Michlmayr Debian kernel for n2100) cortex-a8: 2.6.27.15-omap (custom compilation from mainline + mainline omap patches) and "ldd /usr/bin/oggenc" loads the library components to different virtual addresses, presumably due to the kernel version differences. Building the original libvorbisenc tarball from xiph.org, the example_encoder fails similarly on all the ARM boards, producing different silent ogg files of the same length on the different systems, while a build on gentoo-arm-eabi-feroceon produces a shorter file. Since this is not a Debian-only problem, I am reporting this upstream at xiph.org, citing this bug report for info. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#497165:
> That is something I could try, but I might prefer to list all arches > manually. After all, the arches should not change every other day? -1 The most time-consuming, error-prone and tedious part of the armel port was identifying all the packages that had [long-list-of-arches-except-one-or-two] and contacting the maintainers to make a trivial fix, as well as having a latency of months. The -N suggestion is a good thing for all future ports (as well as being a case of saying what you mean, rather than not saying what you don't mean :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519275: purging gkrellmd does recursive descent of entire file tree
Package: gkrellmd Version: 2.3.1-8 Severity: minor gkrellmd's postrm script calls deluser --remove-all-files gkrellmd which performs a recursive descent of the file tree, into all users home directories and all mounted NFS volumes. This became apparent because some (large and deep!) NFS volumes were exported with the root_squash option, so provoked Purging configuration files for gkrellmd ... Looking for files to backup/remove ... Can't opendir(/home/martin/cluster/arm/doc): Permission denied at /usr/sbin/deluser line 304 Can't opendir(/home/martin/cluster/doc/Scritti): Permission denied at /usr/sbin/deluser line 304 ... I guess this is unintentional, since I don't think gkrellmd owns any files. It doesn't even own /etc/gkrellmd.conf (and rightly so). However, it is very slow, quite alarming for users and could conceivable silently delete files at random throughout the filesystem, for example if the gkrellm UID happened to correspond to some other system user on a mounted NFS volume. I'm not sure why the gkrellm user needs a home directory /home/gkrellm either... maybe this could be tweaked too. Cheers. Great utility -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#515949: vorbis encoder is broken on armel
Package: libvorbis
Version: 1.2.0.dfsg
User: debian-...@lists.debian.org
Usertags: eabi
oggenc and libvorbis' example_encoder do not seem to work at all on armel.
$ oggenc Happy.wav
works fine on x86 and arm, but on armel creates an output just over
half the length it should be, which is mostly full of garbage.
{Happy is a 30-second stereo 44.1 kHz wave file with a 44-byte header,
nothing special)
An extract from "od -c Happy.ogg" after the initial header:
0007600 \0 \0 \0 \0 \0 002 \0 \0 \0 004 004 O g g S \0
0007620 \0 \0 177 \0 \0 \0 \0 \0 \0 262 005 U + 002 \0 \0
0007640 \0 > 353 225 346 377 001 001 001 001 001 001 001 001 001 001
0007660 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001
*
0010040 001 001 001 001 001 001 001 001 001 021 021 021 021 021 021 021
0010060 021 021 021 021 021 021 021 021 021 021 021 021 021 021 021 021
*
0010240 021 021 021 021 021 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0010260 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0010440 \0 \0 \0 \0 \0 \0 \0 \0 244 i \0 \0 322 4 \0 \0
0010460 \0 \0 \0 \0 \0 \0 \0 \0 \0 244 i \0 \0 322 4 \0
0010500 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 244 i \0 \0 322 4
0010520 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 244 i \0 \0 322
0010540 4 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 244 i \0 \0
0010560 322 4 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 244 i \0
0010600 \0 322 4 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 244 i
0010620 \0 \0 322 4 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 244
0010640 i \0 \0 322 4 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
(this 17-byte pattern of garbage repeats for most of the body of the file)
Decoding such a file produces a WAV of the correct size with nothing
but zero bytes in the audio data section.
Other wav files of various provenance are similarly unsuccessful.
It looks like libvorbis, rather than oggenc, libao or libogg, bcos its
example encoder in the build directory
obj-arm-linux-gnueabi/examples/example_encoder
uses stdio to read the WAV file and fails similarly
while speexenc, which also uses libogg to write files, works fine.
FWIW this wave file is visible at
http://martinwguy.co.uk/martin/test/Happy.wav but oggenc's giving the
same kind of output from any wav file I supply it with.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#478558: [xjove] xjove does not die immediately on i386 here
On 11/17/08, Ansgar Burchardt <[EMAIL PROTECTED]> wrote: > xjove does not die on my i386 system. I tried editing a small file > and it works fine. > > Can you still reproduce this bug? yes, on etch (4.16.0.70-3) and lenny (4.16.0.70-3.1) Sometimes a large white window (about 3/4 screen size) flashes up for one screen frame, so I guess it may be some unhealthy interaction with the X server or some library, however I've tried it on thre different systems, with X servers ati, cirrus and i82810 and get the same result on all of them. All systems are recently updated. If I can be of further assistance, or if ssh access to an example machine would be useful, please write again M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501957: libsb680lr is oo-core
On 10/30/08, Rene Engelhard <[EMAIL PROTECTED]> wrote: > Martin Guy wrote: > > Well, libsb680lr is in openoffice.org-core. > > And what do you want to say with that? > (Note #501957 *is* assigned against -core) Nothing, just thinkng aloud before reading up thoroughly. Can't find arm5vte in the source... must be picked up at compile time... M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501957: libsb680lr is oo-core
On 10/30/08, Rene Engelhard <[EMAIL PROTECTED]> wrote: > It is in the source. > > [EMAIL PROTECTED]:~/OpenOffice.org/OOH680_m18/solenv$ grep -r armv5 * > inc/unxlngr.mk:CFLAGS+=-march=armv5te -fno-omit-frame-pointer [EMAIL PROTECTED]:~/arm/openoffice.org-2.4.1$ grep -r armv5 * [EMAIL PROTECTED]:~/arm/openoffice.org-2.4.1$ I must be missing something. Are we talking about the Debian sid sources for openoffice.org? M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501957: libsb680lr is oo-core
Well, libsb680lr is in openoffice.org-core. M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501970: perl: FTBFS on arm: ext/threads/shared/t/stress.t failure
On 10/17/08, Stephen Gran <[EMAIL PROTECTED]> wrote: > This may just be too > much for arm - running 50 simultaneous threads doing a million loops > may take more than the 30 seconds allowed on some of the older boxes. It failed on a 600MHz armel-sid box, but when I upped the timeout from 30 to 120 seconds it succeeded. The same results hold for the old arm port (under an EABI kerne). $ perl stress.t 1..1 ok 1 (actually took 1m49 real, 58s user cpu) $ perl --version This is perl, v5.10.0 built for arm-linux-gnueabi-thread-multi M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501596: Der, geddit right
On 10/8/08, Martin Guy <[EMAIL PROTECTED]> wrote:
> Er, hold that - the patch is duff because modifies Makefile, not
> Makefile.in so gets overwritten in a new extract/build cycle
Ok - here's the version that makes the same patch to Makefile.in
instead, assiduously rebuild from scratch on arm-sid armel-sid and
even arm-etch for good measure. A, a working netwatch everywhere
:)
> There's also an alignment bug in showtraf - put that on hold...
There was an alignment bug in etch but that has already gone in lenny.
It was segfaulting in my lenny build because it was getting linked
with slcurses instead of ncurses. slcurses.h presence overrider
ncurses presence during configure, and using slcurses gives a trafshow
that segfaults.You might also like to add
Build-Conflicts: libslang2-dev
to debian/control to save other suckers like me from getting a duff
build by mistake (libslang2-dev is pulled in by libaa-dev and ohers,
so is not uncommon on development systems)
Cheers
M
--- netdiag-1.0-orig/netwatch-1.0c/Makefile.in 2008-10-08 18:33:22.0 +0100
+++ netdiag-1.0/netwatch-1.0c/Makefile.in 2008-10-08 19:42:46.0 +0100
@@ -34,6 +34,10 @@
clean:
rm -f *~ *.o $(EXEC) config.h config.cache config.log config.status
+# work round ARM GCC bug: builtin memcpy gets alignment wrong.
+netwatch.o: netwatch.c
+ $(CC) $(XCFLAGS) -c $(OLDLINUX) -fno-builtin-memcpy $<
+
.c.o:
$(CC) $(XCFLAGS) -c $(OLDLINUX) $<
--- netdiag-1.0-orig/netwatch-1.0c/netwatch.c 2008-10-08 18:33:22.0 +0100
+++ netdiag-1.0/netwatch-1.0c/netwatch.c 2008-10-08 18:19:08.0 +0100
@@ -2483,7 +2483,7 @@
int
tlocal (u_int32_t * addr)
{
- static unsigned char lhost[] = { 127, 0, 0, 1 };
+ static unsigned char __attribute__((aligned(32))) lhost[] = { 127, 0, 0, 1 };
u_int32_t *k = (u_int32_t *) netmask;
u_int32_t reslocal, restest;
if (*addr == *(u_int32_t *) lhost)
Bug#501596: Der, geddit right
Er, hold that - the patch is duff because modifies Makefile, not Makefile.in so gets overwritten in a new extract/build cycle There's also an alignment bug in showtraf - put that on hold... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501596: netwatch alignment errors on ARM garble IP addresses or give bus errors
Package: netdiag
Version: 1.0-8
User: [EMAIL PROTECTED]
Usertags: eabi
Hi!
Since etch at least, netwatch has not worked on arm: it reports
lots of phantom accesses in the remote IP addresses composed of the
high-order bytes of the local IP address in the low-order bytes and 16
bytes of garbage in the high-order bytes. This turns out to be
entirely due to misaligned 32-bit memory accesses, which are easy to
detect ehre as I have /proc/cpu/alignment set to cause bus errors.
The attached patches fix the two issues.
One is not really netwatch's fault: GCC spots a 16-byte memcpy of
what looks to it from the type casts to be properly-aligned source and
target structures, and uses 4-byte register copies to do a 16-byte
copy - at runtime it turns out that one of the params is an array of
shorts, so the nonaligned accesses do the usual ARM thing of rotating
the words by (addr & 03) bytes. (Or giving bus error if you set ethe
system that way) The easy workaround is to compile that file without
using the builtin memcpy "optimisation".
The other is the constructions of a 4-byte network-endian integer
in a 4-char array and then accessing it as a longword, fixed in the
source with __attribute__((aligned(32)))
I dunno if the other programs in the suite have similar issues, but
this definitely affects and fixes netwatch on both arm and armel sid.
It also works on arm-etch.
Attached:
- screen dump of garbage output (the machines' own IP address is
88.96.6.156 and the network is quiet)
- patch -p1 file to ficx the two alignment issues in netwatch.
M
<>--- netdiag-1.0-orig/netwatch-1.0c/Makefile 2008-10-08 18:33:22.0 +0100
+++ netdiag-1.0/netwatch-1.0c/Makefile 2008-10-08 18:31:42.0 +0100
@@ -35,6 +35,10 @@
clean:
rm -f *~ *.o $(EXEC) config.h config.cache config.log config.status
+# work round ARM GCC bug: builtin memcpy gets alignment wrong.
+netwatch.o: netwatch.c
+ $(CC) $(XCFLAGS) -c $(OLDLINUX) -fno-builtin-memcpy $<
+
.c.o:
$(CC) $(XCFLAGS) -c $(OLDLINUX) $<
--- netdiag-1.0-orig/netwatch-1.0c/netwatch.c 2008-10-08 18:33:22.0 +0100
+++ netdiag-1.0/netwatch-1.0c/netwatch.c 2008-10-08 18:19:08.0 +0100
@@ -2483,7 +2483,7 @@
int
tlocal (u_int32_t * addr)
{
- static unsigned char lhost[] = { 127, 0, 0, 1 };
+ static unsigned char __attribute__((aligned(32))) lhost[] = { 127, 0, 0, 1 };
u_int32_t *k = (u_int32_t *) netmask;
u_int32_t reslocal, restest;
if (*addr == *(u_int32_t *) lhost)
Bug#443322: Yes, maintain the original behaviour
Hi Yes, this is a security problem. Letting people probe usernames compromises Unix security - the behaviour must be identical, including the time taken, whether the username is valid or not (There was once a hole introduced when someone decided not to bother hashing the supplied password if the username was invalid, thereby informing attackers of username validity by the time it took to reject them on an idle machine) Unix is used in many contexts that you cannot begin to imagine - something as generic as Debian even more, so arguments of the form "I can't think of a circumstance where this would be a problem any more" are just display sleepwalking naivety. Just to knock the specific example of this kind of thinking, if someone steals my laptop, I don't want them having an easy life by being able to probe for usernames and then just having the passwords to guess. Another example: we run a service is a squat in Sicily, providing email to hundreds of people, but we can't afford a guard to sit by the server 24 hours a day... Please maintain regular Unix security on *all* entry points, not just the bare minumum that applies in your own particular circumstance! Don't change what ain't broke... Thanks M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#497050: confirmed
Yup, me too since today. When the boot succeeds, the "Cleaning up ifupdown" message is not printed. The system here is Debian lenny, with kernel 2.6.25-2-686. If it hangs again I'll copy the boot output. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495351: Fwd: ARM sigill
The upstream maintainer suggests the following fix in ecl to work around this problem -- Forwarded message -- From: Juan Jose Garcia-Ripoll <[EMAIL PROTECTED]> Date: Sep 5, 2008 11:23 PM Subject: ARM sigill To: Martin Guy <[EMAIL PROTECTED]> Seems I found the problem. His system does not like the calls to fedisableexcept and feenableexcept which are used to control the behavior of the soft-FPU unit. Apparently, after these calls the processor begins to believe it has a real FPU. [...] Well, I have found the problem. The mathematical routines in the C library which are used for controlling the behavior of floating point computations is broken. ECL breaks right after booting because in __sigsetjmp() the system queries an internal register for the capabilities of the CPU and it finds that it has a coprocessor. However, this same query happened before and it returned false. I tracked it down to the lines in src/c/unixint.c that activate the detection of floating point overflow. These are lines which make calls to fedisableexcept/feenableexcept and these are the ones that seem to drive the system crazy. So, all in all, it seems it is a bogus C library. But there is a simple solution. Delete the line "si_trap_fpe(Ct, Ct);" in src/c/unixint.d Could you report these findings in the Debian system? I am too tired right now :-) - Duly reported... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#497172: Please add armel to architecture list for lua-gtk - or maybe use "any"
The word-alignment bugs are now fixed in lua-gtk CVS
Upstream's diffs to the source are attached, but it doesn't apply
cleanly to the 0.8 - among other things, there are new source files,
and unrelated extra "const" declarations.
lua-gtk version 0.9 was released on 25 August 2008 - is that in time
for lenny or should I derive and test an alignment patch for 0.8-2008*
?
diff -ru lua-gtk-0.9/src/boxed.c /home/luagnome/build/lua-gtk-0.9/src/boxed.c
--- lua-gtk-0.9/src/boxed.c 2008-07-22 16:28:11.0 +0100
+++ /home/luagnome/build/lua-gtk-0.9/src/boxed.c 2008-09-01 12:48:07.0 +0100
@@ -171,7 +171,7 @@
* A boxed value should now be used to fill a gtk_arg_types.
*/
void luagtk_boxed_to_ffi(lua_State *L, int index, union gtk_arg_types *dest,
-ffi_type **argtype)
+const ffi_type **argtype)
{
struct boxed_lua_value *b = (struct boxed_lua_value*)
lua_topointer(L, index);
diff -ru lua-gtk-0.9/src/call.c /home/luagnome/build/lua-gtk-0.9/src/call.c
--- lua-gtk-0.9/src/call.c 2008-07-23 12:16:44.0 +0100
+++ /home/luagnome/build/lua-gtk-0.9/src/call.c 2008-09-01 12:50:21.0 +0100
@@ -24,7 +24,7 @@
#include // memset, strcmp, memcpy
#include // va_start etc.
-#include "luagtk_ffi.h" // LUAGTK_FFI_TYPE() macro
+// #include "luagtk_ffi.h" // LUAGTK_FFI_TYPE() macro
/* extra arguments that have to be allocated are kept in this list. */
@@ -203,7 +203,7 @@
#define ALLOC_MORE(p, type) p = (type*) g_realloc(p, n * sizeof(*p)); \
memset(p + old_n, 0, sizeof(*p) * (n - old_n))
ALLOC_MORE(ci->args, struct call_arg);
-ALLOC_MORE(ci->argtypes, ffi_type*);
+ALLOC_MORE(ci->argtypes, const ffi_type*);
ALLOC_MORE(ci->argvalues, void*);
#undef ALLOC_MORE
@@ -496,7 +496,8 @@
/* call the function */
if (_call_build_parameters(L, index, ci)) {
if (ffi_prep_cif(&cif, FFI_DEFAULT_ABI, ci->arg_count,
- ci->argtypes[0], ci->argtypes + 1) == FFI_OK) {
+ (ffi_type*) ci->argtypes[0],
+ (ffi_type**) ci->argtypes + 1) == FFI_OK) {
// A trace function displaying the argument values could be called
// from here. This doesn't exist yet.
diff -ru lua-gtk-0.9/src/closure.c /home/luagnome/build/lua-gtk-0.9/src/closure.c
--- lua-gtk-0.9/src/closure.c 2008-07-23 12:18:58.0 +0100
+++ /home/luagnome/build/lua-gtk-0.9/src/closure.c 2008-09-01 12:50:06.0 +0100
@@ -13,7 +13,7 @@
#include "luagtk.h"
#include // luaL_check*, luaL_ref/unref
-#include "luagtk_ffi.h"
+// #include "luagtk_ffi.h"
#include // memset
#include // exit
@@ -29,7 +29,7 @@
void *code;// points to somewhere in closure
ffi_closure *closure; // closure allocated by FFI
ffi_cif *cif; // cif - spec of retval/args types
-ffi_type **arg_types; // allocated array
+const ffi_type **arg_types; // allocated array
int is_automatic; // true if allocated automatically
};
@@ -39,7 +39,7 @@
struct closure_keeper *next;
ffi_closure *closure;
ffi_cif *cif;
-ffi_type **arg_types;
+const ffi_type **arg_types;
};
static struct closure_keeper *unused = NULL;
@@ -254,7 +254,7 @@
*
* The first byte is the length of the following data.
*/
-static int set_ffi_types(const unsigned char *sig, ffi_type **arg_types)
+static int set_ffi_types(const unsigned char *sig, const ffi_type **arg_types)
{
int type_idx, arg_nr=0;
const unsigned char *sig_end = sig + 1 + *sig;
@@ -275,7 +275,7 @@
// really free all memory of the closure.
static void _free_closure(ffi_closure *closure, ffi_cif *cif,
-ffi_type **arg_types)
+const ffi_type **arg_types)
{
ffi_closure_free(closure);
@@ -459,10 +459,10 @@
luaL_error(L, "luagtk_make_closure: invalid signature");
// allocate and fill arg_types, then ffi_cif
-cl->arg_types = (ffi_type**) g_malloc(sizeof(ffi_type*) * arg_count);
+cl->arg_types = (const ffi_type**) g_malloc(sizeof(ffi_type*) * arg_count);
set_ffi_types(sig, cl->arg_types);
-ffi_prep_cif(cl->cif, FFI_DEFAULT_ABI, arg_count-1, cl->arg_types[0],
- cl->arg_types+1);
+ffi_prep_cif(cl->cif, FFI_DEFAULT_ABI, arg_count-1,
+ (ffi_type*) cl->arg_types[0], (ffi_type**) cl->arg_types+1);
ffi_prep_closure_loc(cl->closure, cl->cif, closure_handler, (void*) cl,
cl->code);
}
diff -ru lua-gtk-0.9/src/hash-cmph.c /home/luagnome/build/lua-gtk-0.9/src/hash-cmph.c
--- lua-gtk-0.9/src/hash-cmph.c 2008-06-23 13:09:00.0 +0100
+++ /home/luagnome/build/lua-gtk-0.9/src/hash-cmph.c 2008-09-01 11:07:05.0 +0100
@@ -14,6 +14,68 @@
#include
#endif
+#ifdef __ARMEL__
+
+#if 0
+// access bytewise, which is not as efficient I guess. Well, optimization
+// shouldn't be done but I couldn't resist in this case.
+static int _get_bytes_simple(const void *p, int n)
+{
+unsigned int val = 0, shift = 0;
+
+while (n-- > 0) {
+ val |= (*(unsigned char*) p) << shift;
+ p ++;
+ shift += 8;
+}
+
+return val;
+}
+#en
Bug#497172: Please add armel to architecture list for lua-gtk - or maybe use "any"
done Upstream bug ticket http://luaforge.net/tracker/index.php?func=detail&aid=29514&group_id=121&atid=576 Thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#497188: maxima build fails on armel
Package: maxima Version: 5.16.2-1 User: [EMAIL PROTECTED] Usertags: eabi The build of maxima on armel fails saying: Loading binary-gcl/float.o Error in FPPREC1 [or a callee]: The function $RATDISREP is undefined. Fast links are on: do (use-fast-links nil) for debugging Broken at FPPREC1. Type :H for Help. Error in FPPREC1 [or a callee]: Can't extend the string. Fast links are on: do (use-fast-links nil) for debugging Broken at CONDITIONS::CLCS-UNIVERSAL-ERROR-HANDLER. 1 (Abort) Return to debug level 1. 2 Retry loading file "binary-gcl/float.o". 3 Return to top level. Full build log is at http://buildd.debian.org/fetch.cgi?&pkg=maxima&ver=5.16.2-1&arch=armel&stamp=1219684211&file=log -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495351: Problem is specific to debian rootfs in maemo chroot and is not present in Debian proper
I've tried this on armv5te and armv4t hardware under armel-sid under gdb and not, and in all cases it works fine, so I suggets closing this bug. For further details of the specific failing environment, see http://sourceforge.net/mailarchive/[EMAIL PROTECTED]&forum_name=ecls-list M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495351: Works fine for me
I just tried this, on a Thecus N2100 (armv5te) running sid and with a tripwire set on misaligned data accesses (echo 5 > /proc/cpu/alignment). Although the installation was very noisy, spewing warnings while recompiling common-lisp-controller three times, it turned out ok: n2100:/home/martin/arm# ecl ;;; Loading #P"/usr/lib/ecl/cmp.fas" ;;; Loading #P"/usr/lib/ecl/sysfun.lsp" ECL (Embeddable Common-Lisp) 0.9j (CVS 2008-02-16 11:33) Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya Copyright (C) 1993 Giuseppe Attardi Copyright (C) 2000 Juan J. Garcia-Ripoll ECL is free software, and you are welcome to redistribute it under certain conditions; see file 'Copyright' for details. Type :h for Help. Top level. > (+ 1 2) 3 > I gather it used to have problems with gcc-4.2. Have you apt-get update/dist-upgraded lately? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#497172: Hold that - build now fails on armel too.
Sorry, I just retried the previously successful build of lua-gtk on armel, and though the build succeeds, the testsuite fails spewing Bus errors, which indicate non-aligned 32-bit word accesses. Please leave this with me unless there is a good reason why lua-gtk should be x86-only. Cheers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#497172: Please add armel to architecture list for lua-gtk - or maybe use "any"
Package: lua-gtk Version: 0.8+20080510+dash-1 lua-gtk is restricted to Architectures i386 and amd64 although every other lua5.1 package is available on Architecture: any. I've tried the build on armel and it turns out fine; would you add armel in debian/control, or expand it to "any" please? Cheers! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#497165: amiga-fdisk-cross is not being built on any architecture other than i386
Package: amiga-fdisk-cross Version: 0.04-12 Not a bug in amiga-fdisk itself, but a Debian buildd issue that needs sorting On 16 Jan 2008, armel was added to the architecture list for amiga-fdisk-cross (bug #461081) but, despite being enabled for 12 architectures, the package has not been built for anything but i386. I am guessing this is due to being included in the various buildd admins' Not-For-Us lists - can you poke them? Cheers! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#497161: Please re-enable gobjc on armel
Package: gdb Version: 6.8-3 User: [EMAIL PROTECTED] Usertag: eabi, patch gobjc has now been ported to armel, so please re-enable the gobjc bindings in debian/control (gobjc [!armel] -> gobc) thanks --- gdb-6.8/debian/control 2008-08-30 12:15:55.0 +0100 +++ gdb-6.8+armel/debian/control 2008-08-30 11:46:16.0 +0100 @@ -3,7 +3,7 @@ Section: devel Priority: optional Standards-Version: 3.7.3 -Build-Depends: autoconf, libtool, texinfo (>= 4.7-2.2), texlive-base, libncurses5-dev, libreadline5-dev, bison, gettext, debhelper (>= 4.9.0), dejagnu, gcj [!kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 !alpha !arm !hppa], gobjc [!armel], mig [hurd-alpha hurd-amd64 hurd-arm hurd-armeb hurd-hppa hurd-i386 hurd-ia64 hurd-m32r hurd-m68k hurd-mips hurd-mipsel hurd-powerpc hurd-ppc64 hurd-s390 hurd-s390x hurd-sh3 hurd-sh3eb hurd-sh4 hurd-sh4eb hurd-sparc], cdbs (>= 0.4.17), quilt (>= 0.30), libkvm-dev [kfreebsd-alpha kfreebsd-amd64 kfreebsd-arm kfreebsd-armeb kfreebsd-hppa kfreebsd-i386 kfreebsd-ia64 kfreebsd-m32r kfreebsd-m68k kfreebsd-mips kfreebsd-mipsel kfreebsd-powerpc kfreebsd-ppc64 kfreebsd-s390 kfreebsd-s390x kfreebsd-sh3 kfreebsd-sh3eb kfreebsd-sh4 kfreebsd-sh4eb kfreebsd-sparc], type-handling (>= 0.2.1), libunwind7-dev [ia64], flex | flex-old, libexpat1-dev, g++-multilib [i386 powerpc s390 sparc], lib64readline5-dev [i386 powerpc s390 sparc] +Build-Depends: autoconf, libtool, texinfo (>= 4.7-2.2), texlive-base, libncurses5-dev, libreadline5-dev, bison, gettext, debhelper (>= 4.9.0), dejagnu, gcj [!kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 !alpha !arm !hppa], gobjc, mig [hurd-alpha hurd-amd64 hurd-arm hurd-armeb hurd-hppa hurd-i386 hurd-ia64 hurd-m32r hurd-m68k hurd-mips hurd-mipsel hurd-powerpc hurd-ppc64 hurd-s390 hurd-s390x hurd-sh3 hurd-sh3eb hurd-sh4 hurd-sh4eb hurd-sparc], cdbs (>= 0.4.17), quilt (>= 0.30), libkvm-dev [kfreebsd-alpha kfreebsd-amd64 kfreebsd-arm kfreebsd-armeb kfreebsd-hppa kfreebsd-i386 kfreebsd-ia64 kfreebsd-m32r kfreebsd-m68k kfreebsd-mips kfreebsd-mipsel kfreebsd-powerpc kfreebsd-ppc64 kfreebsd-s390 kfreebsd-s390x kfreebsd-sh3 kfreebsd-sh3eb kfreebsd-sh4 kfreebsd-sh4eb kfreebsd-sparc], type-handling (>= 0.2.1), libunwind7-dev [ia64], flex | flex-old, libexpat1-dev, g++-multilib [i386 powerpc s390 sparc], lib64readline5-dev [i386 powerpc s390 sparc] Package: gdb Architecture: any
Bug#497160: Cannot link to -lshp on armel: hidden symbol '__aeabi_dcmpgt'
Package: shapelib
Version: 1.2.10-4
Linking anything with -lshp fails on armel. e.g.:
$ cat > c.c
main(){}
^D
$ cc c.c -lshp
/usr/bin/ld: a.out: hidden symbol `__aeabi_dcmpgt' in
/usr/lib/gcc/arm-linux-gnueabi/4.3.1/libgcc.a(_cmpdf2.o) is referenced
by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
This breaks the build of swscanner (when configure probes for -lshp),
and makes gpsmanshp and xastir unrunnable
More details are on wiki.debian.org/ArmEabiProblems -> shapelib
If access to a fast armel-sid system is useful, please mail me.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#497147: usplash-theme-debian also needs +armel
Package: usplash-theme-debian Version: 4 Severity: wishlist Hi again! I just spotted that usplash-theme-debian also needs armel adding to its Architecture list in control to match the list in usplash. Thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496310: Invalid: in inittab there was a login session enabled on vt7
My fault: it was caused by me having enabled consoles on F1to F9 in inittab and the default xdm server starting on vt7 instead of vt10 der. closing... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496310: xdm enabled at startup is deaf to the keyboard
Package: xdm Version: 1:1.1.8-3 hi! I've dist-upgraded from etch to lenny and now when xdm starts up the X server at boot I get the login window but it seems totally deaf to the keyboard. The mouse moves ok. I've tried every key with no luck, except once when it suddenly spurted a load of 10;\99l!0 \n... running off the right side of the login window, then going deaf again. Another (rare) time, in the Login: box =-0999 - running off to the right hand side of the login window (outside the Login: input field). ctrl-alt-backspace won't work either. However, disabling the automatic launch in Xservers - 0: local /usr/bin/X :0 vt7 -nolisten tcp + #0: local /usr/bin/X :0 vt7 -nolisten tcp and enabling remote logins in xdm-config - DisplayManager.requestPort:0 + !DisplayManager.requestPort:0 # /etc/init,d.xdm restart and starting the session from the command line $ X -query localhost works perfectly, as does "startx". I've tried purging xdm and reinstalling it, to eliminate old config issues - no change. The same thing happens if I change the ati driver for the fbdev driver. The X server is normally idle but sometimes goes to consuming 100% CPU if I press random keys. The 100% CPU consumption can erliably be provoked by pressing digit 3 key - ther seems to be no other single key that reliably provokes this behaviour. There is no extra output in /var/log/Xorg.log.0 during this behaviour. Killing the X server at this point usually makes xdm restart - occasionally it leaves a black background with many white vertical lines and hangs the console. In this case, Xorg.log.0 says: (WW) xf86CloseConsole: KDSETMODE failed: Input/output error (WW) xf86CloseConsole: VT_GETMODE failed: Input/output error (WW) xf86CloseConsole: VT_ACTIVATE failed: Input/output error (WW) xf86CloseConsole: VT_WAITACTIVE failed: Input/output error but normality can be regained by issuing /etc/init.d/xdm restart Looks like a corrupt pointer in xdm's input section when dealing with the console directly. Any other diagnostics I can give you? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496305: nvi cannot handle characters with the top bit set
Package: nvi Version: 1.81.6-3 When I edit /var/lib/dpkg/status using nvi and then search for a string (or page down a few times), I get: "Conversion error on line 428" I then can't 428G, but 427G reveals: Package: libgammu3 Status: install ok installed Priority: optional Section: libs Installed-size: 1028 ~ Architecture: i386 Source: gammu (line 428 is the ~). Using a different vi, this line appears as: Maintainer: Michal \304\214iha\305\231 <[EMAIL PROTECTED]> Other lines with the same Maintainer are similarly garbled, and attempting to write the file out to some other filename truncates it to 427 lines. This seems to hold for any line that contains a character with the top bit set. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#452179: present with ati driver, ok on fbdev, ati AccelMethod nonexistent
Hi! I get the same effect using the ati X server with no special flags, whereas all is ok when using the fbdev server. The gimprc workaround also sorts the problem on the ati driver. However the workaround Section "Device" Identifier "ATI Technologies, Inc. Rage Mobility P/M AGP 2x" Driver "ati" # "ati" or "fbdev" BusID "PCI:1:0:0" AccelMethod "EXA" EndSection says Parse error on line 83 of section Device in file /etc/X11/xorg.conf "AccelMethod" is not a valid keyword in this section. and the X server refuses to start. FWIW, 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493167: confirmed
Bug confirmed on arm-sid chroot under eabi kernel with oabi-compat, using foo$ xhost bar bar$ DISPLAY=foo:0 arora See also the mail thread starting at http://lists.debian.org/debian-arm/2008/08/msg5.html for backtraces. For ssh access to a fast arm box mail me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#458745: misaligned access
Confirmed - there is a misaligned word access in the test case # echo 5 > /proc/cpu/alignnment $ gcc foo.c $ ./a.out Bus error reproducible in arm-sid using old-abi or eabi-oldabi-compat kernels. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486654: Der...
Actually your patch works fine, since D_A_B_CPU matches "arm" both on arm and on armel. My apologies. M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#463277: Smaller patch to same effect, doesn't needlessly use gcc-4.1 on armel
Hi This patch, apart from being much smaller, only uses g++-4.1 on arm instead of both arm and armel (needs to use DEB_BUILD_ARCH, nit DEB_BUILD_ARCH_CPU) Thanks anyway, Peter, I copied your arch detection code, which is much more elegant than my hacky attempt... M On arm (old-abi only) if you build with g++-4.2 or 4.3 the build segfaults the first time it tries to run the interpreter. MACHCONF is set to linux-arm on both arm and armel, so we invent another config variable to distringuish between Debian arm and armel, and select gcc-4.1 on arm only. Martin Guy <[EMAIL PROTECTED]>, 31 July 2008 --- afnix-1.5.2.orig/debian/control 2008-07-31 21:28:16.0 +0100 +++ afnix-1.5.2/debian/control 2008-07-31 21:29:57.0 +0100 @@ -2,7 +2,7 @@ Section: interpreters Priority: optional Maintainer: Paul Cager <[EMAIL PROTECTED]> -Build-Depends: debhelper (>= 5.0.42), dpatch (>= 2.0), +Build-Depends: debhelper (>= 5.0.42), dpatch (>= 2.0), g++-4.1 [arm], libncurses5 (>= 5.5), libncurses5-dev (>= 5.5) Standards-Version: 3.7.3 Homepage: http://www.afnix.org/ --- afnix-1.5.2.orig/cnf/mak/afnix-gcc-4.mak 2007-06-07 10:10:37.0 +0100 +++ afnix-1.5.2/cnf/mak/afnix-gcc-4.mak 2008-07-31 22:08:37.0 +0100 @@ -18,9 +18,17 @@ # - compiler and linker section - # +# On arm, only old-ABI, the build segfaults under g++-4.2 and 4.3. +DEB_BUILD_ARCH ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH) +ifeq ($(DEB_BUILD_ARCH),arm) +CC = g++-4.1 +LD = gcc-4.1 +LK = gcc-4.1 +else CC = g++ LD = gcc LK = gcc +endif AR = ar RANLIB = ranlib STDEVFLAGS =
Bug#486654: FTBFS blocking RC bug fixes
On 7/28/08, peter green <[EMAIL PROTECTED]> wrote: > > * adonthell: > > > > *** warning: prefs::read_adonthellrc: creating config file failed > > Fatal Python error: exceptions bootstrapping error. > > > > Workaround for this is to use python 2.4, I have posted a patch that does > that to > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486654 It is indeed required on armel but your patch is buggy. You need to use DEB_BUILD_ARCH instead of DEB_BUILD_ARCH_CPU, which is "arm" on both, whilc D_B_A is "arm" or "armel". -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#463277: More analysis of afnix 1.5.2 failing to build on arm old-abi
It also fails on arm-sid if compiled with gcc-4.2 in the very same way: SEGFAULT at the same line in the build. However, it succeeds if compiled with gcc-4.1 - see my AFNIX doc for details of the hack. Unfortunately to achieve this you need to patch one of the package's config files to select gcc-4.1 when architecture == arm. Is that a permissible workaround? If so I'll cobble together a patch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#463277: More analysis
The moment in which it segfaults is the first time it runs the interpreter it has just built, "axi", during the build, so I guess the whole interpreter is broken. I've tried a debugging build by hacking debian/rules: <./cnf/bin/afnix-setup -o --prefix=/usr >./cnf/bin/afnix-setup -g --prefix=/usr # -o/-g turn each other > off and the cause of death is in exactly the same place, indeed the same instruction (modulo code differences due to -O0 forced by the debug build) - some callback to a constructor function whose address is picked out of an array. #0 0x4005064c in mksob () at Constant.cpp:29 #1 0x40258504 in get_serial_object (sid=33 '!') at Serial.cpp:63 #2 0x40258dc8 in afnix::Serial::getserial (sid=33 '!') at Serial.cpp:163 #3 0x40258e48 in afnix::Serial::deserialize ([EMAIL PROTECTED]) at Serial.cpp:171 (more of this output at n2100.martinwguy.co.uk/martin/arm/AFNIX) HOWEVER 1.5.2-2 built fine on arm (but not armel - dunno if it was tried or not) 1.5.2-3.1 builds fine on armel but not arm - this should help narrow it down! The changes are miniscule: * Added gcc-4.3_support.dpatch to fix FTBFS with GCC 4.3 (Closes: #461964) -> just removing -Werror from the gcc command line * afnix-doc: should be Architecture:all (Closes: #451602) -> This implies less work to do, so shouldn't break anything. I've tried building without -B (for superstition), and it dies at the same command, with a Bus Error this time instead of SEGV (I have the box set to signal misaligned accesses instead of returning garbled values) * Fixed FTBFS: dpkg-shlibdeps: failure: couldn't find library libafnix- eng.so.1.5 needed by debian/afnix/usr/lib/afnix/libafnix- net.so.1.5.2. (Closes: #453794) -> it doesn't get this far. Given that it builds on every other arch, including armel, and since 1.5.2-2 was built 15-Jul-2007 on arm with gcc-4.2 or 4.1, the most likely cause seems that it is either tickling a bug in gcc-4.3 for ARM old-ABI, or that gcc-4.3 on ARM-OABI is violating some assumption afnix has about it. Yeah, the easy answer is to drop the package from Lenny, but it's annoying. I've mailed one of the authors asking if they want to look at it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#492175: libidl cannot be built without fakeroot
Package: libidl0 Version: 0.8.10-0.1 A user reports that libidl0, build as root with dpkg-buildpackage, fails saying: make[3]: Entering directory `/home/kevin/Debian/libidl0/libidl-0.8.10' /bin/sh ./libtool --tag=CC --mode=compile cc -DPACKAGE_NAME=\"libIDL\" -DPACKAGE_TARNAME=\"libIDL\" -DPACKAGE_VERSION=\"0.8.10\" -DPACKAGE_STRING=\"libIDL\ 0.8.10\" -DPACKAGE_BUGREPORT=\"http://bugzilla.gnome.org/enter_bug.cgi\?product=libIDL\"; -DLIBIDL_VERSION=\"0.8.10\" -DHAVE_CPP_PIPE_STDIN=1 -DCPP_NOSTDINC=\"-I-\" -DCPP_PROGRAM=\"cc\ -E\" -DYYTEXT_POINTER=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -DHAVE_STDDEF_H=1 -DHAVE_UNISTD_H=1 -DHAVE_WCHAR_H=1 -DHAVE_POPEN=1 -DHAVE_SYMLINK=1 -DHAVE_ACCESS=1 -DSIZEOF_LONG_LONG=8 -I. -DYYDEBUG=1 -DYYERROR_VERBOSE=1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I./include -DG_LOG_DOMAIN=\"libIDL\" -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations-O2 -g -Wall -O2 -c -o util.lo util.c cc -DPACKAGE_NAME=\"libIDL\" -DPACKAGE_TARNAME=\"libIDL\" -DPACKAGE_VERSION=\"0.8.10\" "-DPACKAGE_STRING=\"libIDL 0.8.10\"" "-DPACKAGE_BUGREPORT=\"http://bugzilla.gnome.org/enter_bug.cgi?product=libIDL\""; -DLIBIDL_VERSION=\"0.8.10\" -DHAVE_CPP_PIPE_STDIN=1 -DCPP_NOSTDINC=\"-I-\" "-DCPP_PROGRAM=\"cc -E\"" -DYYTEXT_POINTER=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -DHAVE_STDDEF_H=1 -DHAVE_UNISTD_H=1 -DHAVE_WCHAR_H=1 -DHAVE_POPEN=1 -DHAVE_SYMLINK=1 -DHAVE_ACCESS=1 -DSIZEOF_LONG_LONG=8 -I. -DYYDEBUG=1 -DYYERROR_VERBOSE=1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I./include -DG_LOG_DOMAIN=\"libIDL\" -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -O2 -g -Wall -O2 -c util.c -fPIC -DPIC -o .libs/util.o gcc-4.3: 0.8.10": No such file or directory gcc-4.3: unrecognized option '-E"' : warning: missing terminating " character : warning: missing terminating " character util.c: In function 'IDL_parse_filename': util.c:227: error: missing terminating " character while using -rfakeroot it succeeds. This turns out to be because option flags like -DPACKAGE_STRING=\"libIDL\ 0.8.10\" are getting split at the escaped space without fakeroot. Why is a mystery. See the thread at http://lists.debian.org/debian-arm/2008/07/msg00018.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#487396: Missing link error on ARM
On 6/24/08, Matthias Klose <[EMAIL PROTECTED]> wrote: > Is this arm only, or armel as well? armel too. I have /proc/cpu/alignment set to 5 and it's doing an unaligned word access under gdb (and gcc -g): Program received signal SIGBUS, Bus error. 0x400d2cd0 in std::string::assign () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0x400d2cd0 in std::string::assign () from /usr/lib/libstdc++.so.6 #1 0x8680 in std::string::operator= (this=0xbe8947af, __s=0x872c "") at main1.cpp:18 #2 0x85b0 in main (argc=1, argv=0xbe894914) at main1.cpp:30 (gdb) Set to the usual value of 1 (give garbage values): Program received signal SIGSEGV, Segmentation fault. 0x400d2cec in std::string::assign () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0x400d2cec in std::string::assign () from /usr/lib/libstdc++.so.6 #1 0x8680 in std::string::operator= (this=0xbec237af, __s=0x872c "") at main1.cpp:18 #2 0x85b0 in main (argc=1, argv=0xbec23914) at main1.cpp:30 (gdb) or 3 (fixup): Program received signal SIGSEGV, Segmentation fault. 0x400d2cec in std::string::assign () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0x400d2cec in std::string::assign () from /usr/lib/libstdc++.so.6 #1 0x8680 in std::string::operator= (this=0xbe9ce7af, __s=0x872c "") at main1.cpp:18 #2 0x85b0 in main (argc=1, argv=0xbe9ce914) at main1.cpp:30 (gdb) Hope this helps -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486095: Can libhdate use gpc instead of fpc?
Package: libhdate-pascal Version: 1.4.11-1 Severity: wishlist Hi! The pascal binding to libhdate uses FPC, which only works on five architectures, and from lenny+1 will only exist on four unless FPC is ported to armel. If libhdate-pascal could be compiled with GPC instead, it would be available on all 14 Debian architectures. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#483949: xulrunner crash
On 6/7/08, Mike Hommey <[EMAIL PROTECTED]> wrote: > The strange thing is that #482415 was originally reported on amd64, > where such alignment problems shouldn't have any effect. 482415 is something different, giving immediate failure on startup with a message. It was filed against iceweasel-3.0~b5-1, and is reported to be fixed in 3.0~rc1-1. The two unaligned 32-bit accesses in xulrunner occur long after startup when visiting previously unvisited URLs and give SIGBUS in nsUrlClassifierDBServiceWorker::GetShaEntries() at toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp line 2024 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#484885: execution profiling not enabled for armel in iop4xx kernel
Package: linux-2.6 Version: 2.6.25-4 User: [EMAIL PROTECTED] Usertag: eabi In the configuration for iop4xx on armel, CONFIG_PROFILING is not set, which breaks the gprof execution profiling tool. I haven't checked the other armel configurations, but this should be enabled in all Debian linux kernels. Come to think of it, this is the second missing kernel option I've spotted in this configuration, so it is likely that other omissions and peculiarities would be uncovered if all configurations of all architectures were checked against a standard set of kernel features that should be enabled (or should be disabled) for Debian, rather than having each one configured individually. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#483949:
Oops. There's another occurrence of the same thing a few dozen lines later.
This new patch fixes both of them (in the same grotty manner :)
Firefox now seems crash-free as far as unaligned word accesses are concerned.
M
---
xulrunner-1.9~rc1.orig/toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp
2008-05-07 21:33:45.0 +0100
+++
xulrunner-1.9~rc1/toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp
2008-06-02 10:09:06.0 +0100
@@ -2020,8 +2020,20 @@
return NS_ERROR_FAILURE;
}
const nsCSubstring& str = Substring(chunk, start, 4);
+#if 0
+// You can't just cast a char* to an int* and access through it
const PRUint32 *p = reinterpret_cast(str.BeginReading());
entry->mAddChunkId = PR_ntohl(*p);
+#else
+// the old-school way...
+union {
+ PRUint32 i;
+ char c[4];
+} u;
+
+memcpy(u.c, reinterpret_cast(str.BeginReading()), 4);
+entry->mAddChunkId = PR_ntohl(u.i);
+#endif
if (entry->mAddChunkId == 0) {
NS_WARNING("Received invalid chunk number.");
return NS_ERROR_FAILURE;
@@ -2049,8 +2061,20 @@
if (chunkType == CHUNK_SUB) {
const nsCSubstring& str = Substring(chunk, start, 4);
+#if 0
+ // You can't just cast a char* to an int* and access through it
const PRUint32 *p = reinterpret_cast(str.BeginReading());
entry->mAddChunkId = PR_ntohl(*p);
+#else
+ // the old-school way...
+ union {
+PRUint32 i;
+char c[4];
+ } u;
+
+ memcpy(u.c, reinterpret_cast(str.BeginReading()), 4);
+ entry->mAddChunkId = PR_ntohl(u.i);
+#endif
if (entry->mAddChunkId == 0) {
NS_WARNING("Received invalid chunk number.");
return NS_ERROR_FAILURE;
Bug#483949: unaligned word access in xulrunner
Package: xulrunner
Version: 1.9~rc1
Severity: normal
User: [EMAIL PROTECTED]
Usertags: patch
There is an unaligned word access bug in
toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp line 2024
where a char pointer is cast to an int pointer and accessed. On arm
and armel by default this silently gives junk values. On other
architectures it will cause a bus faults.
Fortunately the fix is trivial and local, though there are probably
more mozilla- o C++-like ways to reimplement this before sending it
upstream.
---
xulrunner-1.9~rc1.orig/toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp
2008-05-07 21:33:45.0 +0100
+++
xulrunner-1.9~rc1/toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp
2008-06-01 13:24:06.0 +0100
@@ -2020,8 +2020,20 @@
return NS_ERROR_FAILURE;
}
const nsCSubstring& str = Substring(chunk, start, 4);
+#if 0
+// You can't just cast a char* to an int* and access through it
const PRUint32 *p = reinterpret_cast(str.BeginReading());
entry->mAddChunkId = PR_ntohl(*p);
+#else
+// the old-school way...
+union {
+ PRUint32 i;
+ char c[4];
+} u;
+
+memcpy(u.c, reinterpret_cast(str.BeginReading()), 4);
+entry->mAddChunkId = PR_ntohl(u.i);
+#endif
if (entry->mAddChunkId == 0) {
NS_WARNING("Received invalid chunk number.");
return NS_ERROR_FAILURE;
Bug#468322:
That may be because it is doing more these days. In particular, there is an option in /etc/gkrellmd.conf that disables a particularly slow and little-used feature: # The Internet monitor defaults to reading tcp connections once per second. # However, for Linux SMP kernels where reading /proc/net/tcp causes high # cpu usage, the inet-interval may be set to 1-20 seconds to slow down # /proc/net/tcp reads. Or set it to 0 to totally disable the Inet monitor. inet-interval 0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#482403: speedup reenabling optimization
Just dropping the "CFLAGS=-g" clause, the following speedups are obtained: tested over 3 runs of "time xaos -maxiter 1024" q Yes armel usertime: 1.00 1.03 0.99 -> 0.93 0.89 0.91 athlon usertime: .064 .076 .064 -> .048 .032 .044 M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#482403: xaos is compiled with compiler optimization turned off
Package: xaos Version: 3.3-1 Severity: normal debian/rules line 9: CFLAGS=-g ./configure --prefix=/usr which disables all compiler optimization for xaos, as well as foiling people trying to use CFLAGS="-mfpu=myfpu -O2" dpkg-buildpackage If you leave CFLAGS alone, xaos does compiler tests and picks what it thinks are the best optimisation options. e.g. on x86: -D__OPTIMIZE__ -Wall -Wundef -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wsign-compare -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -march=pentiumpro -fstrength-reduce -ffast-math -fomit-frame-pointer -pipe -fno-exceptions -O6 -funroll-loops -frerun-loop-opt -fstrict-aliasing -malign-double -mno-ieee-fp (__OPTIMIZE__ also pick arch-dependent optimisations in the source) Is there a reason for this? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479163: signed char bug in ginac/clifford.cpp
Package: ginac
Version: 1.4.3-1
Hi! While compiling your package on arm, where characters are unsigned
by default, I noticed a bug:
g++ -DHAVE_CONFIG_H -I. -I. -I.. -g -Wall -O2 -finline-limit=1200 -c
add.cpp -fPIC -DPIC -o add.o
add.cpp: In member function 'virtual GiNaC::ex GiNaC::add::coeff(const
GiNaC::ex&, int) const':
add.cpp:295: warning: comparison is always true due to limited range
of data type
add.cpp:304: warning: comparison is always false due to limited range
of data type
because clifford_max_label returns either a valid unsigned char 0-255
or -1 on failure, which will never signal failure where character->int
promotion yields 0-255, and would give a false failure on
architectures with signed characters for a valid return value of 255
(if this is possible).
The attached patch fixed this by extending the return value to int so
that all 257 values can be returned.
This patch fixes a bug on machines where char is unsigned by default, by
extending the type of clifford_max_label to include all 257 possible
return values.
--- ginac-1.4.3.orig/ginac/add.cpp 2008-03-27 10:16:10.0 +
+++ ginac-1.4.3/ginac/add.cpp 2008-05-03 10:59:02.0 +0100
@@ -291,7 +291,7 @@
{
std::auto_ptr coeffseq(new epvector);
std::auto_ptr coeffseq_cliff(new epvector);
- char rl = clifford_max_label(s);
+ int rl = clifford_max_label(s);
bool do_clifford = (rl != -1);
bool nonscalar = false;
--- ginac-1.4.3.orig/ginac/clifford.cpp 2008-03-27 10:16:10.0 +
+++ ginac-1.4.3/ginac/clifford.cpp 2008-05-03 10:58:24.0 +0100
@@ -1126,7 +1126,7 @@
return e1;
}
-char clifford_max_label(const ex & e, bool ignore_ONE)
+int clifford_max_label(const ex & e, bool ignore_ONE)
{
if (is_a(e))
if (ignore_ONE && is_a(e.op(0)))
@@ -1134,7 +1134,7 @@
else
return ex_to(e).get_representation_label();
else {
- char rl = -1;
+ int rl = -1;
for (size_t i=0; i < e.nops(); i++)
rl = (rl > clifford_max_label(e.op(i), ignore_ONE)) ?
rl : clifford_max_label(e.op(i), ignore_ONE);
return rl;
--- ginac-1.4.3.orig/ginac/clifford.h 2008-03-27 10:16:10.0 +
+++ ginac-1.4.3/ginac/clifford.h2008-05-03 11:04:08.0 +0100
@@ -299,7 +299,7 @@
*
* @param e Expression to be processed
* @ignore_ONE defines if clifford_ONE should be ignored in the search*/
-char clifford_max_label(const ex & e, bool ignore_ONE = false);
+int clifford_max_label(const ex & e, bool ignore_ONE = false);
/** Calculation of the norm in the Clifford algebra. */
ex clifford_norm(const ex & e);
Bug#478891: sorry, changing builddeps is not enough
Sorry, just changing the builddeps as I suggested to remove armel gnat
dep is not enough. It needs a clause in debian/rules too and
control.in too.
The f95 test fails:
Testing front-end f95
./test_f95.sh: line 55: 30317 Segmentation fault
$f95dir/x${index}f -dev $device -o ${OUTPUT_DIR}/x${index}f95.$dsuffix
$options 2>test.error
-- Process completed
***Failed
but the package builds ok. Patches are attached.
(cc-ing Colin Tuckley, our armel fortran wizard)
--- plplot-5.9.0/debian/control 2008-05-02 22:48:07.0 +0100
+++ plplot-5.9.0+armel-noada/debian/control 2008-05-02 22:51:08.0
+0100
@@ -14,7 +14,7 @@
python-gtk2-dev, libwxgtk2.6-dev, python-gnome2-dev,
python-all-dev (>= 2.3.5-11), python-central (>= 0.5.6),
python-numpy (>= 1.0.4-4), ttf-freefont, java-gcj-compat-dev [!arm],
- fastjar, swig, gnat [!alpha !arm !mips !mipsel]
+ fastjar, swig, gnat [!alpha !arm !armel !mips !mipsel]
Build-Depends-Indep: docbook-xml, docbook, docbook-dsssl, docbook-xsl,
docbook2x, opensp, jadetex
Build-Conflicts: libplplot5, octave2.1-headers
--- plplot-5.9.0/debian/control.in 2008-05-02 22:48:07.0 +0100
+++ plplot-5.9.0+armel-noada/debian/control.in 2008-05-02 22:51:08.0
+0100
@@ -14,7 +14,7 @@
python-gtk2-dev, libwxgtk2.6-dev, python-gnome2-dev,
python-all-dev (>= 2.3.5-11), python-central (>= 0.5.6),
python-numpy (>= 1.0.4-4), ttf-freefont, java-gcj-compat-dev [!arm],
- fastjar, swig, gnat [!alpha !arm !mips !mipsel]
+ fastjar, swig, gnat [!alpha !arm !armel !mips !mipsel]
Build-Depends-Indep: docbook-xml, docbook, docbook-dsssl, docbook-xsl,
docbook2x, opensp, jadetex
Build-Conflicts: libplplot5, octave2.1-headers
--- plplot-5.9.0/debian/rules 2008-05-02 22:48:07.0 +0100
+++ plplot-5.9.0+armel-noada/debian/rules 2008-05-02 22:47:09.0
+0100
@@ -47,6 +47,10 @@
BUILD_JAVA = no
endif
+ifeq ($(DEB_BUILD_ARCH),armel)
+BUILD_ADA = no
+endif
+
ifeq ($(DEB_BUILD_ARCH),mips)
BUILD_ADA = no
endif
Bug#479113: please re-enable java bindings on armel
Package: swig1.3 Version: 1.3.35-3.2 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi, patch Hi! gcj/gij now work fine on armel, so you can now re-enable the java bindings by removing "!armel !armeb" from the Build-Dep clauses for gcj and gij in debian/control I've tried this out and the package builds ok on armel. (note: [!arm] should stay - gcj/gij have now been removed from the old arm port) Thanks! --- swig1.3-1.3.35/debian/control 2008-05-01 18:29:22.0 +0100 +++ swig1.3-1.3.35+armel/debian/control 2008-05-01 18:28:25.0 +0100 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Torsten Landschoff <[EMAIL PROTECTED]> Standards-Version: 3.7.2 -Build-Depends: debhelper (>= 4.0), quilt (>= 0.40), tcl8.4-dev, tk8.4-dev, libperl-dev, bison, python-dev (>= 2.4), python-dev (<< 2.6), ruby1.8, ruby1.8-dev, guile-1.6-dev, php5-dev, php5-cgi, ocaml, libchicken-dev [!m68k !mips !mipsel], libpcre3-dev [!m68k !mips !mipsel], gcj [!hppa !armel !armeb !mips !mipsel !kfreebsd-amd64 !kfreebsd-i386 !alpha !arm !hurd-i386], gij [!hppa !armel !armeb !mips !mipsel !kfreebsd-amd64 !kfreebsd-i386 !alpha !arm !hurd-i386] +Build-Depends: debhelper (>= 4.0), quilt (>= 0.40), tcl8.4-dev, tk8.4-dev, libperl-dev, bison, python-dev (>= 2.4), python-dev (<< 2.6), ruby1.8, ruby1.8-dev, guile-1.6-dev, php5-dev, php5-cgi, ocaml, libchicken-dev [!m68k !mips !mipsel], libpcre3-dev [!m68k !mips !mipsel], gcj [!hppa !mips !mipsel !kfreebsd-amd64 !kfreebsd-i386 !alpha !arm !hurd-i386], gij [!hppa !mips !mipsel !kfreebsd-amd64 !kfreebsd-i386 !alpha !arm !hurd-i386] Package: swig Architecture: any
Bug#479111: Please re-enable java bindings on armel
Package: gdb Version: 6.8-1 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi, patch Hi! gcj/gij now work fine on armel, so you can re-enable the java interface by removing "!armel" from the Build-Dep clauses for gcj in debian/control (patch attached) I've tried this out and the package builds ok on armel. Thanks! --- gdb-6.8/debian/control 2008-05-01 18:41:26.0 +0100 +++ gdb-6.8+armelgcj/debian/control 2008-05-01 18:33:35.0 +0100 @@ -3,7 +3,7 @@ Section: devel Priority: optional Standards-Version: 3.7.3 -Build-Depends: autoconf, libtool, texinfo (>= 4.7-2.2), texlive-base, libncurses5-dev, libreadline5-dev, bison, gettext, debhelper (>= 4.9.0), dejagnu, gcj [!kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 !armel], gobjc [!armel], mig [hurd-alpha hurd-amd64 hurd-arm hurd-armeb hurd-hppa hurd-i386 hurd-ia64 hurd-m32r hurd-m68k hurd-mips hurd-mipsel hurd-powerpc hurd-ppc64 hurd-s390 hurd-s390x hurd-sh3 hurd-sh3eb hurd-sh4 hurd-sh4eb hurd-sparc], cdbs (>= 0.4.17), quilt (>= 0.30), libkvm-dev [kfreebsd-alpha kfreebsd-amd64 kfreebsd-arm kfreebsd-armeb kfreebsd-hppa kfreebsd-i386 kfreebsd-ia64 kfreebsd-m32r kfreebsd-m68k kfreebsd-mips kfreebsd-mipsel kfreebsd-powerpc kfreebsd-ppc64 kfreebsd-s390 kfreebsd-s390x kfreebsd-sh3 kfreebsd-sh3eb kfreebsd-sh4 kfreebsd-sh4eb kfreebsd-sparc], type-handling (>= 0.2.1), libunwind7-dev [ia64], flex | flex-old, libexpat1-dev, g++-multilib [i386 powerpc s390 sparc], lib64readline5-dev [i386 powerpc s390 sparc] +Build-Depends: autoconf, libtool, texinfo (>= 4.7-2.2), texlive-base, libncurses5-dev, libreadline5-dev, bison, gettext, debhelper (>= 4.9.0), dejagnu, gcj [!kfreebsd-amd64 !kfreebsd-i386 !hurd-i386], gobjc [!armel], mig [hurd-alpha hurd-amd64 hurd-arm hurd-armeb hurd-hppa hurd-i386 hurd-ia64 hurd-m32r hurd-m68k hurd-mips hurd-mipsel hurd-powerpc hurd-ppc64 hurd-s390 hurd-s390x hurd-sh3 hurd-sh3eb hurd-sh4 hurd-sh4eb hurd-sparc], cdbs (>= 0.4.17), quilt (>= 0.30), libkvm-dev [kfreebsd-alpha kfreebsd-amd64 kfreebsd-arm kfreebsd-armeb kfreebsd-hppa kfreebsd-i386 kfreebsd-ia64 kfreebsd-m32r kfreebsd-m68k kfreebsd-mips kfreebsd-mipsel kfreebsd-powerpc kfreebsd-ppc64 kfreebsd-s390 kfreebsd-s390x kfreebsd-sh3 kfreebsd-sh3eb kfreebsd-sh4 kfreebsd-sh4eb kfreebsd-sparc], type-handling (>= 0.2.1), libunwind7-dev [ia64], flex | flex-old, libexpat1-dev, g++-multilib [i386 powerpc s390 sparc], lib64readline5-dev [i386 powerpc s390 sparc] Package: gdb Architecture: any
Bug#478891: please disable ada binding for new arm targets
Package: plplot Version: 5.9.0-6 Severity: wishlist gnat has not been ported to arm processors yet, so please extend debian/control's "Build-Depends: gnat" clause to include the new arm ports [!armel !armeb] so that all the other plplot binary packages and their dependents can be built. Thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#464140: Processed: Please really add arm and armel to debian/control
> lua-gtk is broken on arm and armel: > > http://experimental.debian.net/build.php?pkg=lua-gtk Ok, thanks, I'll forget it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#464140: Hang on...
Hold that... with 0.8 on armel I'm getting failures in the testsuite instead, and am working to see if that's lua-gtk/armel's fault or some system corruption at my end... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#464140: Please really add armel and armeb
Hi Adding armel and armeb to debian/control seems to have gotten missed out in the last upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397616:
In order of preference 2 or 3: fixup misaligned accesses 4 or 5: SIGBUS the process in question, rather than silently giving the wrong results (it is the same logic as dividing by zero or accessing memory through an invalid pointer). 0 or 1: silently give wrong results. I'm afraid the linked IRC discussion has disappeared from the web and is not on archive.org - in any case, mailing lists are the place to hold open source discussions, both so that it is archived and to avoid "select inner group" false consensus among the few people who happen to be awake and hanging out on IRC at the time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#478561: xjove function keys do not work
Package: xjove
Version: 4.16.0.70-3
Severity: minor
The default actions of the function keys that are advertised on
xjove's startup page do not do what it says:
F1 ("Save and Exit") takes you to the ":" prompt,
F2 ("Save") splits the current buffer,
F3 ("Information about JOVE") moves you to the next buffer
F4 ("Exit without saving") full-screens the current buffer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#478558: xjove dies immediately on i386
Package: xjove Version: 4.16.0.70-3 On i386 in etch and sid, xjove dies immediately saying: $ xjove A command window has exited because its child exited. Its child's process id was 17854 and it exited with return code 1. $ however, it works ok on arm and armel, etch and sid. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#408802: perhaps remove instead
> For nmu'ers looking at this bug, please test xview after > applying the patch. It is unclear if it actually works on > armel. It works fine on armel with all the xview programs I have tested. I'd say that working perfectly for 11 years without modification and being ported to a dozen architectures that never even existed when it was written is a plus point for xview. Being one of the first X toolkits and having existed for so long makes it very likely that people are also using it with specialist software that is not included in Debian and that we have never heard of, because thay can just compile their weird things without needing to know how to install libraries. In general I wouldn't remove things that work fine and that are used by hundreds of people, just for some sense of modernity of cleanliness. I can understand its authors in the 1980s not being able to imagine 64 bit architectures being widespread. I would guess this port will happen the first time someone wants to use a complex xview application on their 64-bit platform, but saying "xview !*64" seems reasonable. While I think of it, Riku, can you campaign for "Architecture: !foo !bar" in all contexts where "Architecture:" occurs? Given the hundreds of hours you, I and the package maintainers have wasted saying "please add armel" that has stopped us tackling the real problems, I think that would be a valuable investment for all future ports of Debian. Cheers M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476846: Bug does NOT happen for sid version (9:1.1.7.1-1) of genisoimage on armel
> Maybe this is support for the explanation as an endian problem? arm and armel are little-endian. The main weirdnesses of plain arm are a bizarre middle-endian floating point format (look for things trying to read FP values off a disk file or network stream) and unusual structure-packing behaviour (look for filling a struct with values and dumping it whole to a file or stream or vice versa). Good luck! M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#474276: testsuite failures on i386
On 4/4/08, Matthias Klose <[EMAIL PROTECTED]> wrote: > Martin Guy writes: > > ...and on i386-sid on Athlon-32 the testsuite fails mightily: > > > > === libffi Summary === > > > > # of expected passes505 > > # of unexpected failures513 > > # of unresolved testcases 8 > > # of unsupported tests 15 > > is this the run for -m64? If yes, then it's expected. Ah yes, there are two test runs, of which the first succeeds 100% and the second: Target is x86_64-pc-linux-gnu Host is x86_64-pc-linux-gnu Build is i486-pc-linux-gnu fails. My apologies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
