Bug#336308: mozilla-firefox: On ARM920T processor both installation and firefox-bin die with Illegal instruction
Package: mozilla-firefox
Version: 1.0.6-5
Severity: important
On my ARM system, apt-get install mozilla-firefox ends with:
Setting up mozilla-firefox (1.0.6-5) ...
Updating mozilla-firefox chrome
registry.../usr/sbin/update-mozilla-firefox-chrome: line 106: 1354
Illegal instruction firefox-bin -register /dev/null 21
E: Registration process existed with status: 132
E: /usr/lib/mozilla-firefox/extensions/installed-extensions.txt still
present. Registration might have gone wrong.
mv: cannot stat `/usr/lib/mozilla-firefox/defaults.ini': No such file or
directory
dpkg: error processing mozilla-firefox (--configure):
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
mozilla-firefox
E: Sub-process /usr/bin/dpkg returned an error code (1)
arma:/home/martin/amp-0.7.6#
and if I run the program I get:
[EMAIL PROTECTED]:~$ firefox
/usr/bin/firefox: line 349: 1478 Illegal instruction
DISPLAY=${CMDLINE_DISPLAY} ${MOZ_PROGRAM} -remote 'ping()' /dev/null
21
Illegal instruction
[EMAIL PROTECTED]:~$
The system in question has been running continuously for three weeks;
plain mozilla works perfectly, as do video players, mp3 decoders and
all the Debian superstructure. Has firefox been compiled for xscale
maybe?
Bless
M
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing')
Architecture: arm (armv4l)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.4.27-a9-1
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages mozilla-firefox depends on:
ii debianutils 2.14.3 Miscellaneous utilities specific t
ii fontconfig2.3.2-1generic font configuration library
ii libatk1.0-0 1.10.3-1 The ATK accessibility toolkit
ii libc6 2.3.5-6GNU C Library: Shared libraries an
ii libfontconfig12.3.2-1generic font configuration library
ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib
ii libgcc1 1:4.0.2-2 GCC support library
ii libglib2.0-0 2.8.3-1The GLib library of C routines
ii libgtk2.0-0 2.6.10-1 The GTK+ graphical user interface
ii libidl0 0.8.5-1library for parsing CORBA IDL file
ii libjpeg62 6b-10 The Independent JPEG Group's JPEG
ii libkrb53 1.3.6-5MIT Kerberos runtime libraries
ii libpango1.0-0 1.8.2-3Layout and rendering of internatio
ii libpng12-01.2.8rel-1 PNG library - runtime
ii libstdc++64.0.2-2The GNU Standard C++ Library v3
ii libx11-6 6.8.2.dfsg.1-7 X Window System protocol client li
ii libxext6 6.8.2.dfsg.1-7 X Window System miscellaneous exte
ii libxft2 2.1.7-1FreeType-based font drawing librar
ii libxinerama1 6.8.2.dfsg.1-7 X Window System multi-head display
ii libxp66.8.2.dfsg.1-7 X Window System printing extension
ii libxt66.8.2.dfsg.1-7 X Toolkit Intrinsics
ii psmisc21.6-1 Utilities that use the proc filesy
ii xlibs 6.8.2.dfsg.1-7 X Window System client libraries m
ii zlib1g1:1.2.3-4 compression library - runtime
mozilla-firefox recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388246: gcc-4.1.1 manual pages are now missing!
Package: gcc Version: 4.1.1-13 (gcc version 4.1.2) I was about to report the dangling symlinks in the gcc man directory /usr/share/man/man1/i486-linux-gnu-cpp.1.gz - cpp-4.1.1.gz /usr/share/man/man1/cpp.1.gz - cpp-4.1.1.gz /usr/share/man/man1/c++.1.gz - /etc/alternatives/c++.1.gz /usr/share/man/man1/gcov.1.gz - gcov-4.1.1.gz /usr/share/man/man1/cc.1.gz - /etc/alternatives/cc.1.gz /usr/share/man/man1/i486-linux-gnu-gcc.1.gz - gcc-4.1.1.gz but by upgrading gcc, I see that they have been fixed (bug #384923: Dangling slave link to cc.1.gz) not by installing the referenced man pages, but by removing the symlinks. Now gcc, g++, cpp, gcov, cc do not have manual pages at all. $ man cc No manual entry for cc. $ I am running Debian unstable (etch) on i686. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394876: gtk-gnutella in testing has expired
Package: gtk-gnutella Version: 0.96.1svn11444 gtk-gnutella version: 0.96.2u (2006-08-03; GTK2; Linux i686) At startup the program claims it has expiresd and refuses to start up at all without cryptic user intervention. This is a recurring grave functionality bug (see bug 340933) Suggested fix: patch out this fascist test in the source, since debian versions will get upgraded when they are available... or disable it by always including a line ancient_version_force = gtk-gnutella/0.96.2u (2006-08-03; GTK2; Linux i686) (or whatever) in the user's .gtk-gnutella/config_gnet file -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396529: rezound packaging should recommend lame
Package: rezound Version: 0.12.2beta-6 Hi! I just installed rezound from testing(etch) with aptitude, and when I run it it says on stdout: 'lame' executable not found in $PATH -- mp3 support will be disabled It turns out that toolame is installed on the system (by chance) but does not provide an actual lame command. Another alternative, twolame, doesn't either. If I create a lame symlink to either one of these two, rezound fails to open any mp3 file, popping up a window saying: -- file: Love_On_The_Line.mp3 lame command line: '/home/martin/bin/lame --decode Love_On_The_Line.mp3 -' error - virtual bool ClameSoundTranslator::onLoadSound(std::string, CSound*) const -- it looks as if either there is an error in the input file -- or lame was not compiled with decoding support (get latest at http://mp3dev.org) -- or an error has occuring executing lame -- or your version of lame has started to output a different wave file header when decoding MPEG Layer-1,2,3 files to wave files. Changes will have to be made to this source to handle the new wave file output -- I guess the Debian version needs changing to use mpg123 -s if lame is not installed, and to recommend package mpg321 (since mpg123 is an alternative that may point to a cpu-optimised versions) ... or persuade the upstream maintainer to look for mpg123 if lame is unavailable. Bless M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391936: libagg-dev: new function render_scanlines_compound_layered is not in latest Debian version
Package: libagg-dev Version: 2.4-1 From: Gnash project developer Since 19 June 2006, agg-2.4 contains a new optimised function render_scanlines_compound_layered which is used in the new Gnash AGG backend, but this addition has not propagated to the Debian package in unstable and testing. Updating to this version should enable the Gnash project to tell Debian users simply to install libagg-dev, rather than having to tell them to install agg-2.4 from source before being able to tackle gnash-cvs itself. The specific error during build of gnash with ./configure --enable-renderer=agg is: render_handler_agg.cpp:897: error: 'render_scanlines_compound_layered' is not a member of 'agg' See also http://www.antigrain.com/news/index.html first section, 5th bullet point Bless M Env: Debian testing (etch) for x86. -- 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#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#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#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#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#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#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#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#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#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=maximaver=5.16.2-1arch=armelstamp=1219684211file=log -- 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
done Upstream bug ticket http://luaforge.net/tracker/index.php?func=detailaid=29514group_id=121atid=576 Thanks! -- 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 string.h // memset, strcmp, memcpy
#include stdarg.h // 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 lauxlib.h // luaL_check*, luaL_ref/unref
-#include luagtk_ffi.h
+// #include luagtk_ffi.h
#include string.h // memset
#include stdlib.h // 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 endian.h
#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
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
attachment: netwatch-arm-alignment-bugs.png--- 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#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: 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#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#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#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: 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: 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#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#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#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#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#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#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#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' command-line: warning: missing terminating character command-line: 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#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#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#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#465246: user-root exploit in vmsplice()
Package: linux-image-2.6.18-6-686 Version: 2.6.18.dfsg.1-17etch1 Severity: important There is a bug in vmsplice from 2.6.17 to 2.6.24.1 that can be exploited by any user process to gain root privileges. info is here http://isc.sans.org/newssummary.html which links to the source code for the exploit here: http://www.milw0rm.com/exploits/5092 ...which has been tested, and works like a charm. Also here: http://www.isec.pl/vulnerabilities/isec-0026-vmsplice_to_kernel.txt ...which describes the exploit in more detail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460562: change of package name to libdb-dev makes it uninstallable
Package: db Version: 4.6.21-5 Hi! I'm trying to satisfy the build dependencies of subversion in sid, but cannot because - subversion build-depends on libdb4.4-dev and libaprutil1-dev - libaprutil1-dev depends on libdb-dev - libdb4.4-dev provides and conflicts with libdb-dev This seems to be caused by the change from binary package libdb4.X-dev providing libdb-dev to (in 4.6) package libdb-dev providing libdb4.6-dev. Is there a good reason not to continue the scheme used in libdb4.[12345] ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460562: [Pkg-db-devel] Bug#460562: change of package name to libdb-dev makes it uninstallable
2008/1/13, Florian Weimer [EMAIL PROTECTED]: Is there a good reason not to continue the scheme used in libdb4.[12345] ? The name scheme is not the problem, it's the fact that all Berkeley DB -dev packages conflict (because they all install the db.h header file). the db.h conflict is not the problem; that just means you can only install one of libdb[12345]-dev, which provided virtual package libdb-dev. That caused no problems. Now in the Packages file instead of Package: libdb4.4-dev Provides: libdb-dev Conflicts: libdb-dev, libdb1-dev, libdb2-dev, libdb3-dev from version 4.6 we have Package: libdb-dev Provides: libdb4.6-dev Conflicts: libdb1-dev, libdb2-dev, libdb3-dev so a virtual package has become a real package (and libdb4.6-dev is virtual). Can't you link Subversion against Berkeley DB 4.6? According to a report on the Subversion mailing list, the current version passes its test suite unchanged even when using Berkeley DB. I could if I were building for myself, but in the debian context packages may build-depend on specific versions of libdb4.?-dev or may be happy with any (specifying libdb-dev), some figures for how many source packages specify the different versions in sid: libdb4.1-dev 0 libdb4.2-dev 10 libdb4.3-dev 14 libdb4.4-dev 19 libdb4.5-dev 14 libdb4.6-dev 9 libdb-dev 38 Previously, the specific version would provide the virtual package and both build dependencies would be satisfied. Now libdb-dev, which should mean any, always resolves to 4.6, which conflicts with the specific version asked for by some other package. The same build problem now occurs with php5: .../php5-5.2.4# dpkg-checkbuilddeps dpkg-checkbuilddeps: Unmet build dependencies: apache2-prefork-dev (= 2.0.53-3) .../php5-5.2.4# apt-get install apache2-prefork-dev The following extra packages will be installed: libaprutil1-dev libdb-dev The following packages will be REMOVED: libdb4.4-dev .../php5-5.2.4# dpkg-checkbuilddeps dpkg-checkbuilddeps: Unmet build dependencies: libdb4.4-dev .../php5-5.2.4# apt-get install libdb4.4-dev The following packages will be REMOVED: apache2-prefork-dev libaprutil1-dev libdb-dev ... and so on. What is the advantage of switching the virtual/real package names over? To force the other 60 packages to make sure they work with libdb4.6 instead of having up to five versions if libdb installed on every system? If it's worth the aggro, I agree it would be a step forward. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460562: [Pkg-db-devel] Bug#460562: Bug#460562: change of package name to libdb-dev makes it uninstallable
reassign 460562 db thanks Sorry, it's not as simple as that; it impacts on more than one other package. If you want to get everyone to use libdb4.6 instead of explicitly 4.[2345] (which would be a Good Thing, assuming 4.6 is backward-compatible with all the others), then I think you need to file bugs against all 66 other packages that call for specific versions (presumably because what they really meant was at least version 4.N) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460562: [Pkg-db-devel] Bug#460562: Bug#460562: change of package name to libdb-dev makes it uninstallable
feel free to help out by adding to http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED];tag=oldbdb;dist=unstable Can do. Should I ask them to change to requiring libdb-dev or libdb4.6-dev? I.E. Is the future plan to keep one version only and simply increase libdb's version number, or to carry on from here with the 4.6 4.7 4.8 scheme of things to limit breakage? (the former I hope!) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461080: please add armel to architecture list
Package: amoga-fdisk Version: 0.04-11 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi Please add armel to the architecture lists in debian/control See wiki.debian.org/ArmEabiPort Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461081: please add armel to architecture list
Package: amiga-fdisk Version: 0.04-11 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi Please add armel to the architecture list in debian/control (or make it any) (A new ARM port should be going into lenny to replace the old one in lenny+1; see wiki.debian.org/ArmEabiPort) Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461088: please add armel to architecture list
Package: gsynaptics Version: 0.9.7-3 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi Please add armel to the architecture list in debian/control (or make it any) (A new ARM port should be going into lenny to replace the old one in lenny+1; see wiki.debian.org/ArmEabiPort) Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461089: please add armel to architecture list
Package: ddccontrol Version: 0.4.2-1 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi Please add armel to the architecture list in debian/control (A new ARM port should be going into lenny to replace the old one in lenny+1; see wiki.debian.org/ArmEabiPort) Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461090: please add armel to architecture list
Package: ibam Version: 1:0.4-4 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi Please add armel to the architecture list in debian/control (A new ARM port should be going into lenny to replace the old one in lenny+1; see wiki.debian.org/ArmEabiPort) Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461091: please add to architecture lists
Package: kerry Version: 0.2.2-1 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi kerry's architecture list in the control file says: Architecture: amd64 arm i386 ia64 powerpc whereas in sid it is available in 5 other architectures http://packages.debian.org/search?searchon=nameskeywords=kerry although these versions are not upgraded automatically; presumably they were built and uploaded manually. armel (wiki.debian.org/ArmEabiPort) is the reason I am writing, but if it is appropriate, you could add the other known-to-work architectures, armel hppa kfreebsd-amd64 s390 sparc to the control file or simply make it any Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461096: please add armel to architecture list
Package: nictools-pci Version: 1.3.8-1.1 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi Please add armel to the architecture list in debian/control (A new ARM port should be going into lenny to replace the old one in lenny+1; see wiki.debian.org/ArmEabiPort) Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408787: armel/armeb have not been added in new nictools-pci upload
Hi! Just to say the why of the reopening: armel and armeb have not been added to debian/control, whatever the changelog may say Bless M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461096: and armeb
... and armeb as well, while you're at it. The Debian ChangeLog says this has been done, but it hasn't. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461564: Upgrade to latest version would give manyfold speed improvement
Package: foomatic-filters Version: 3.0.2-20061031-1.2 Severity: wishlist --- Przemyslaw Kwiatkowski [EMAIL PROTECTED] writes on 19 Jan 2008 ... I replaced foomatic-rip from (foomatic-filters 3.0.2-20061031-1.2) with new one from http://www.openprinting.org/foomatic-rip (this version is not yet available in Debian, even in sid). And now my print server works about 5-8 times FASTER. High-res 200MB ghostscript picture leaves printer after 3-5mins and is is good enough for me (previously it was about 30-40mins!). On his 200MHz ARM, foomatic-rip was taking 90% of the CPU - more than even ghostscript on a system with extremely slow floating point. May I suggest an update to a more recent version in sid before lenny goes out? Cheers M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461564: Further info
For info, the specific config exhibiting the immense slowness was: HP DJ 990cxi connected via usb, driver is hpijs 2.6.10+1.6.10-4.2+lenny1 (and hplip 1.6.10-4.2+lenny1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461564: Get it right!
...and it was a 600Mhz ARM. Der! M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461564: and again
... and the ratio was Actually gs is eating only about 20%, and foomatic-rip takes 80% Sorry, I must have been having a bad day. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455909: linux-image-2,6-iop32x: many misaligned memory accesses
Strange, I've all zeroes right after a boot (with an OABI kernel). Here it's a vanilla Debian armel 2.6.23-1-iop32x kernel on XScale-80219 rev 0 (v5l) It's not serious as misaligned accesses in kernel are always trapped and fixed up. I'd be inclined to close this item for lack of importance. M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463444: rbot is uninstallable due to dependecy on ruby 1.9
Package: rbot Version: 0.9.10-1 Severity: serious # apt-get install rbot The following packages have unmet dependencies: rbot: Depends: ruby ( 1.9) but 4.1 is to be installed E: Broken packages because rbot Depends: ruby (= 1.8), ruby ( 1.9) but ruby switched to a versioning scheme which avoids confusing with the real ruby version. Please Depend on ruby1.8 explicitly if you need that specific version. Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439832: Status of armel in the archive?
2008/1/30, Luk Claes [EMAIL PROTECTED]: On Wed, Jan 02, 2008 at 10:32:55AM +0100, Marc 'HE' Brockschmidt wrote: [armel]'s quality is at least matching the current arm port Could you please comment on the current status and list outstanding issues blocking the inclusion of armel in the archive? Well, since no one else has actually answered the question... In unstable, arm is at 95.69% of the archive, while armel is at 91.94% Of the lacking packages, the lion's share is due to lack of language support. gcc-3 is not supported in armel and never will be, which excludes g77 and everything that uses it. The success of armel therefore depends on the success of the g77-gfortran transition. Objective C does not work on armel, which knocks out gnustep. ARM are now funding CodeSourcery to make the necessary modifications to gcc. It remains to be seen which mainline version this will go into - probably gcc-4.4, since 4.3 is now open only to regression fixes, while lenny's current default gcc is 4.2 with some people pressing for it to be 4.3. Debian may have to carry these modifications as patches. Other packages either don't compile or don't work on armel, including some that are included in the repository but do not work at all, of which the most high-profile are iceweasel and iceape-browser. Unfortunately there is currently no public bug tracker for issues other than the wiki pages; that would be one advantage of inclusion in lenny. The advantage of armel over arm from a normal user's point of view is the immense increase in floating point speed (a factor of 11) plus the possibility of using current hardware FPUs (for a further factor of between 2.5 and 7) The disadvantage is that it requires armv4t processors, excluding older ARMv4-based systems (CATS, NetWinder, Balloon 2). The simplest way to circumvent this would be to patch the kernel to emulate the missing BX instruction. wiki.debian.org/armelLennyReleaseRecertification summarises its certification status wiki.debian.org/ArmEabiTodo givean overview of the main issues wiki.debian.org/ArmEabiProblems is the closest we have to a public bug tracker. arm will be supported on lenny... I think that is highly desirable. The arm port is more mature and more functional at present M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463803: ardour would enjoy libfftw3-dev
Package: ardour Version: 2.2-1 While configuring on debian, ardour says: Checking for fftw3f...no Checking for fftw3...no Checking for C header file fftw3.h... no - You do not have the FFTW single-precision development package installed. This prevents Ardour from using the Rubberband library for timestretching and pitchshifting. It will fall back on SoundTouch for timestretch, and pitchshifting will not be available. - whereas, if libfftw3-dev happens to be installed by chance, it does detect it and you get a different build. I suggest you add libfftw3-dev to ardour's Build-Depends line -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463816: Please add armel to architectures list
Package: libinotify-ruby Version: 0.0.2-1 Severity: wishlist Please add armel to the architectures lists for libinotify-ruby1.[89] in debian/control for benefit of the new ARM port [1] ... or make it any to avoid future hassle with new ports. Thanks [1] http://wiki.debian.org/ArmEabiPort -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440425: Yes, QEMU does need gcc-3.4
QEMU requires gcc-3.4 at runtime because it emulates 5 different CPUs by translating the machine code into C, compiling the C fragments and editing the assembler output to trim off function call/return sequences. This makes it the fastest emulator on the planet but it does not understand gcc-4 assembler output. This would be a good reason to keep gcc-3.4 in Debian unless there is progress upstream, since QEMU is often used in Debian development itself. M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464140: Please include armel in debian/control
Package: lua-gtk Version: 0.7-1 Severity: wishlist Please add armel and armeb to the Architectures: list for lua-gtk in debian/control since it builds fine there too. (See wiki.debian.org/ArmEabiPort) While you're at it, I think it would be better to put a single Architectures: clause in the Source: section instead of the same list in each Package: section. That means it is only built on architectures that want it, rather than being built on all and producing no packages on most. That would also mean that the Architectures: list appear in the main Sources file, which makes life easier for port maintainers because we can find Arch anomalies by grepping through the Sources file, rather than having to download every source package and grep debian/control, which is an unfeasibly immense task. ... or make Architecture: any and let buildd maintainers weed out the broken ports... Thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434016: Also broken on armel
Yes, armel gives the same error message -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464140: Please include armel in debian/control
2008/2/8, Enrico Tassi [EMAIL PROTECTED]: Please compilerun the test file src/callback-test.c and give me feedback. It exits 0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464903: Please add arm, armel and armeb to Architectures: list (or change to any)
Package: music123 Version: 15-0.1 Severity: wishlist Hi! The arm, armel and armeb architectures are missing from the Architectures: line in debian/control It's particularly pernicious to specify Archirectures in the Package: clauses of debian/control because the package seems to build fine on new architectures but silently doesn't produce any binary packages - for example, the arm port has been lacking music123 for many years for no reason. Can you just specify Architecture: any in the Source: section so as not to keep having to do this for every future port? Cheers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455909: linux-image-2,6-iop32x: many misaligned memory accesses
2007/12/28, Martin Michlmayr [EMAIL PROTECTED]:
I can reproduce this problem with 2.6.18-5 and 2.6.22-3, but not with
2.6.23-1 from unstable. Can you try 2.6.23?
The 2.6.23-2 kernel package I built from source will still not boot
from flash (a separate issue) but I can copy the
/boot/{vmlinuz,initrd.img}-2.6.23-1-iop32x it creates elsewhere and
load them into redboot via http. That still gives:
[EMAIL PROTECTED]:/$ uname -r
2.6.23-1-iop32x
[EMAIL PROTECTED]:/$ cat /proc/cpu/alignment
User: 0
System: 47706027
Skipped:0
Half: 0
Word: 47706027
DWord: 0
Multi: 0
User faults:0 (ignored)
[EMAIL PROTECTED]:/$
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455909: linux-image-2,6-iop32x: many misaligned memory accesses
2008/1/9, Martin Michlmayr [EMAIL PROTECTED]: Presumably right after boot without doing anything special? No, after some kernel building. Right after a boot it's: n2100:~# cat /proc/cpu/alignment User: 0 System: 3928 Skipped:0 Half: 0 Word: 3928 DWord: 0 Multi: 0 User faults:0 (ignored) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460067: Support compilation with gpc as well as (instead of?) fpc
Package: gearhead Version: 1.100-1 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi gearhead currently build-depends on fp-compiler, which is only available on 5 architectures. If it could transition to gpc (pascal-compiler), it would be available on all 16. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460068: Support compilation with gpc as well as (instead of?) fpc
Package: hedgewars Version: 0.9.0-7 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi hedgewars currently build-depends on fp-compiler, which is only available on 5 architectures. If it could transition to gpc (pascal-compiler), it would be available on all 16. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460069: Support compilation with gpc as well as (instead of?) fpc
Package: imapcopy Version: 1.01+20060420-1 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi imapcopy currently build-depends on fp-compiler, which is only available on 5 architectures. If it could transition to gpc (pascal-compiler), it would be available on all 16. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460071: Support compilation with gpc as well as (instead of?) fpc
Package: lazarus Version: 0.9.24-0-4 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi Hi! Is it possible for lazarus to support gpc as well as (instead of?) fpc? If so, it would be available on all 16 architectures instead of just 5. I don't know how compatible the two compilers are, how fpc-dependent lazarus is, or even whether the suggestion makes any sense. I only ask because I'm pushing the new Debian arm (armel) port, and hope to avoid having to port fp-compiler to it. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460077: please add armel to architecture list
Package: happs Version: 0.8.8+darcs20070523-2 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi We now have ghc6 in the armel port, so please add armel to the ghc6-version-picking architecture lists in debian/control -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460081: please add armel to architecture list
Package: haskell-binary Version: 0.3-2 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi We now have ghc6 in the armel port, so please add armel to the ghc6-version-picking architecture lists in debian/control -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460083: please add armel to architecture list
Package: haskell-x11-extras Version: 0.4-2 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi We now have ghc6 in the armel port, so please add armel to the ghc6-version-picking architecture lists in debian/control -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460082: please add armel to architecture list
Package: haskell-hlist Version: 2.0+darcs20070316-2 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi We now have ghc6 in the armel port, so please add armel to the ghc6-version-picking architecture lists in debian/control -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460084: please add armel to architecture list
Package: jack-audio-connection-kit Version: 0.103.0-6 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi Please add armel to the architecture lists in the control file so it is included in the new ARM port http://wiki.debian.org/ArmEabiPort Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460096: please add arm variants to exclusion list in debian/control
Package: shogun Version: 0.4.4-1 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi Please add !armel and !armeb to debian/control's Build-Depends: atlas3-base-dev [!arm] for the forthcoming variants of the arm port [1] Thanks [1] http://wiki.debian.org/ArmEabiPort -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460098: please add armel to architecture list, if ghc6 version dependency is important
Package: happs Version: 0.8.8+darcs20070523-2 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi We now have ghc6 in the armel port [1] so debian/control's Build-Depends clauses: ghc6 (= 6.6.1) [alpha amd64 arm hppa i386 ia64 kfreebsd-i386 m68k mips mipsel powerpc ppc64 s390 sparc], ghc6 ( 6.6.1+) [alpha amd64 arm hppa i386 ia64 kfreebsd-i386 m68k mips mipsel powerpc ppc64 s390 sparc] should include armel in that list if the version check is important. Actually, it gets ghs6 anyway on armel because, even though ghc6 is not explicitly depended on, when it installs two of the build dependencies, it goes: Note, selecting ghc6 instead of libghc6-base-dev Note, selecting ghc6-prof instead of libghc6-base-prof [1] http://wiki.debian.org/ArmEabiPort -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460121: openssh builddep on groff is too severe: only groff-base is necessary
Package: openssh Version: 1:4.7p1-1 Severity: wishlist the build dependency on groff is unnecessary: the smaller groff-base is enough (I've checked this with groff-base and no groff installed, and it builds fine with dpkg-buildpackage -d) This would make bootstrapping of future ports slightly more linear -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460136: please include armel in debian/control architecture list to guarantee selinux support
Package: openssh Version: 1:4.7p1-1 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi debian/control says: Build-Depends: libselinux1-dev [alpha amd64 arm armeb hppa i386 ia64 lpia m68k mips mipsel powerpc ppc64 s390 sparc], libgnomeui-dev (= 2.0.0) | libgnome-dev to which armel should be added. In practice, both of the alternatives libgnome-dev and libgnomeui-dev are available, of which -ui-dev also brings in libselinux1-dev and -dev does not. At present it has built on armel with libgnomeui and thus selinux was present by chance; With libgnome-dev installed and no libselinux1-dev, configure fails for lack of selinux headers. Does the order in which alternatives are listed imply an order of preference when several of them are present? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460141: please add arm variants to exclusion list in debian/control
Package: cgal Version: 3.3.1-1 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi Please add !armel and !armeb to debian/control's Build-Depends: [!arm !m68k] clause for the forthcoming variants of the arm port [1] Thanks [1] http://wiki.debian.org/ArmEabiPort -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453009: Upgrade to varkon-1.19B removes need for gcc-3.3
Package: varkon Version: 1.18A-3 Varkon FTFBS on the new ARM EABI port because it has -fwritable-strings in its makefiles, which disappeared after gcc-3.3, and ARM EABI only works from gcc-4.1; it will never have gcc pre-4.1 ---Johan Kjellander [EMAIL PROTECTED]--- As far as I know -fwritable-strings has been removed from all Varkon makefiles for linux. The current source dist. 1.19B on SourceForge should definitely compile without writable strings. - I is also interesting that varkon is the very last package out of 7000 that requires gcc-3.3 I suggest upgrading the Debian version of varkon to 1.19B both to make it compilable on Debian armel and to remove the last requirement for gcc-3.3. For armel it's critical; for everyone else a wish-list item. Bless M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455892: linux-image-2,6-iop32x: please enable process accounting
Package: linux-image-2.6-iop32x Version: 2.6.22+11 User: [EMAIL PROTECTED] Usertags: eabi The armel kernel for iop32x doesn't have BSD process accounting configured in, breaking package acct. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455909: linux-image-2,6-iop32x: many misaligned memory accesses
Package: linux-image-2.6-iop32x Version: 2.6.22+11 User: [EMAIL PROTECTED] Usertags: eabi Severity: wishlist After running for a mere 20 hours, /proc/cpu/alignment reports millions of misaligned word accesses from the kernel: $ cat /proc/cpu/alignment User: 0 System: 2765980 Skipped:0 Half: 0 Word: 2765980 DWord: 0 Multi: 0 User faults:0 (ignored) I gather this has a performance penalty, as misaligned kernel memory accesses are always trapped and fixed up. None or the other EABI kernels I am running exhibits the same behaviour: Angstrom's 2.6.20-rc1-h1940 reports 3 system-word alignment fixups in 30 days; Angstrom's 2.6.23 running Angstrom GPE reports 9 user-word fixups in 12 days a Debian-armel system with custom kernel reports no misalignments in 9 days. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455909: linux-image-2,6-iop32x: many misaligned memory accesses
I can reproduce this problem with 2.6.18-5 and 2.6.22-3, but not with 2.6.23-1 from unstable. Can you try 2.6.23? Seems I can't, no, having spent a day trying. But then I never built a kernel package before, so that doesn't mean much. After most of a day trying I'm giving up. Can you give me a prod in the right direction? The binary's not in the repo, and all my various attempts at building it from the linux-2.6_2.6.23-1 Debian sources with dpkg-makepackage or from linux-sources-2.6.23 using: make-kpkg all fail, gabbling about /bin/sh: line 0: [: -lt: unary operator expected /bin/sh: line 0: [: -eq: unary operator expected /bin/sh: line 0: [: -eq: unary operator expected /bin/sh: line 0: [: -eq: unary operator expected /bin/sh: line 0: [: -lt: unary operator expected /bin/sh: line 0: [: -eq: unary operator expected /bin/sh: line 0: [: -eq: unary operator expected /bin/sh: line 0: [: -gt: unary operator expected /bin/sh: line 0: [: -ge: unary operator expected /bin/sh: line 0: [: -ge: unary operator expected Not in correct source directory For example, the make-kpkg runes I'm using are: # apt-get install linux-source-2.6.23 $ cd /usr/src $ tar xfj lin*bz2 $ ln -s linux-2.6.23 linux [EMAIL PROTECTED]:/usr/src$ cd linux [EMAIL PROTECTED]:/usr/src/linux$ make iop32x_defconfig [EMAIL PROTECTED]:/usr/src/linux$ fakeroot make-kpkg kernel_image exec debian/rules DEBIAN_REVISION=..-10.00.Custom kernel_image /bin/sh: line 0: [: -lt: unary operator expected /bin/sh: line 0: [: -eq: unary operator expected /bin/sh: line 0: [: -eq: unary operator expected /bin/sh: line 0: [: -gt: unary operator expected /bin/sh: line 0: [: -ge: unary operator expected /bin/sh: line 0: [: -ge: unary operator expected Not in correct source directory I also don't understand how the autobuilt kernel package gets its config, so I've used iop32x_defconfig in the debian-patched source tree. Is that right? Riku reports that 2.6.23-1 on his N2100s does not exhibit the same symptoms either. Any clues, or shall I wait until a binary makes it into the repo? Cheers M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425971: Bug#455909: linux-image-2,6-iop32x: many misaligned memory accesses
Hi! The armel port is still blocked on this item. The bugfix was submitted over 7 months ago and included over a month a go in version control. If possible, would you expedite an upload of the new version please? These timescales are glacial! Thanks M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458745: arm-only miscompilation of alloca code
I just tried foo.c on up-to-date arm-sid and armel-sid systems, both under qemu and on real hardware and I cannot reproduce the problem; all succeed the same way, for example: [EMAIL PROTECTED]:~$ /usr/bin/gcc-4.2 foo.c [EMAIL PROTECTED]:~$ ./a.out 0xbe92ec84 0x1 0x2 0x3 [EMAIL PROTECTED]:~$ gcc --version gcc (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4) So I can only suspect a leisner problem of some kind. If you would like to try reproducing the problem here, please get in touch and I'll arrange access. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462962: apt-get --no-install-recommends is not documented in man page
Package: apt Version: 0.7.10 The new -no-install-recommends flag is not documented in the man page for apt-get. Given the new install-recommends-by-default policy, this is particularly important. It would be worth mentioning the APT::Install-Recommends in the manual page as well and to highlight the fact that its default setting has changed recently. Actually, I disagree with this change - it makes apt-get build-dep install tons of stuff that is not necessary to build (like all the x servers for librsvg1-bin, a firefox dep). However, given that it's in it, documenting it, and how to get round it, would be good. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460084: please add armeb too
While you're at it, you may as well add armeb for that forthcoming port -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458911: please add armeb too
while you're at it, you might as well add the forthcoming armeb architecture too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460077: Please add armeb also
While you're at it, you may as well also add armeb, the forthcoming big-endian version of the port -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435384: Please add armeb too
While you're at it, you may as well add the forthcoming armeb port as well -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434846: PLease add armeb also
While you're at it, you may as well add the forthcoming armeb port as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436237: Please add armeb too
While you're at it, also adding armeb for that future port would be a good idea. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461091: Please add armeb also
While you're at it, if you add armel, please also add the forthcoming armeb port too -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461081: and armeb
...while you're at it, adding armeb for that future port would be a good idea too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463128: Please allow later versions of gcc
Package: emile Version: 0.10-1 Severity: wishlist emile is the last package in Debian to require gcc-3.3 If it will compile with gcc-4 it can also be included in the new armel architecture (which lacks even gcc-3.4) - at present it fails early on because of signed/unsigned errors and -Werror (at present, removing -Werror and using gcc4 the build fails on the struct syntax error mentioned in #451415) Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443052: Galeon goes into an infinite loop saving a page that contains #8230;
Package: galeon
Version: 2.0.2-4
Saving the page http://www.apexonline.com/melodybar/cataf~1.htm to a
local file, galeon goes into an infinite loop consuming 100% CPU.
strace reveals that it is doing:
write(24, , 0);
write(24, , 0);
write(24, #48;, 5);
repeatedly, and the output file contains an infinite repetition of
#48; from the point where an ellipsis character ('...', so to
speak) should be.
A minimal sample file that provokes the behaviour is
htmlhead/headbody
page 10#8230; (JC)
/body/html
which you can also load as
http://martinwguy.co.uk/martin/debian/bugs/galeon-8230.html
Reproduce the behaviour by loading that page with galeon and saving
the file as something.
Environment:
Debian etch for i386 under X server sis and fvwm 2.5.18 (not gnome)
on dual AMD Athlon
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443453: Purging xboing does not remove highscore file
Package: xboing Version: 2.4-29 Severity: minor Installation of xboing creates /var/games/xboing.score but purging does not remove that file As a consequence, when all games are removed, apt-get complain forever that /var/games is not empty. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443493: When pinball is purged it does not remove directory /var/games/pinball
Package: pinball Version: 0.3.1-7 Severity: minor Installation of pinball creates /var/games/pinball/*/highscores but purging it does not remove the directory. As a consequence, when all games are removed, apt-get complain forever that /var/games is not empty. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405077: iodbc rundepends on libiodbc2
Package: iodbc Version: 3.52.4-3 iodbcadm-gtk binary in package iodbc requires shared library libiodbcinst.so.2 so it needs to depend on package libiodbc2 # apt-get install iodbc ... The following NEW packages will be installed: iodbc ... $ iodbcadm-gtk iodbcadm-gtk: error while loading shared libraries: libiodbcinst.so.2: cannot open shared object file: No such file or directory ... # apt-get install libiodbc2 ... $ iodbcadm-gtk [runs ok] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299095: back again in attr 2.4.32-1
Package: attr Version: 2.4.32-1 This bug, of attr using system calls directly, presents itself again in attr 2.4.32-1. In this case it is with the switch to ARM EABI that triggers the bug because the system call base number changes. If this bug really was fixed in 2.4.31-1, then that fix has disappeared. The initial report is at http://lists.arm.linux.org.uk/pipermail/linux-arm/2006-November/012433.html and the most elegant fix is the attachment (for gnu-linux) is http://bugs.debian.org/cgi-bin/bugreport.cgi/attr.diff?bug=299095;msg=10;att=1 to make it use glibc when available instead of reimplementing all the system calls. M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
