Re: etch -- lenny upgrade report on Alpha platform
On Sat, Oct 18, 2008 at 12:38:57AM -0500, Bob Tracy wrote: Thanks for the *very* large clue as to what's going on. A quick search of bug reports led me to try adding -Wl,--no-relax to DSO_LDOPTS in mozilla/firefox_obj/config/autoconf.mk. The libxul.so build now succeeds! Here's the unfortunate part: the GNU ld relax bug was observed and reported back in 2007... I don't have the link handy, but Google found it pretty quickly when I searched for the relocation error string. If I get a working firefox-3.0.3 out of all this, debian-alpha will be the first to know about it... Close, but no cigar :-(. I'm getting a segmentation fault shortly after the browser window opens with the expected two tabs (home page, and the you've upgraded page). The segfault occurs while the two pages are loading. If there's good news concerning the segfault, 64-bit x86 builds are suffering from the same problem, so we might reasonably expect that the Alpha build will work when the 64-bit x86 build works. Here are the mods (so far) to get the mozilla.org firefox-3.0.3 source to build on an Alpha: (1) netwerk/cookie/src/Makefile.in Commented-out CXXFLAGS += $(WARNINGS_AS_ERRORS). No way we can leave -Werror enabled with gcc/g++-4.x on an Alpha :-(. (2) xpcom/reflect/xptcall/src/md/unix/Makefile.in Under the Linux/alpha section, added Linuxalphaev56 to the filter statement. Linuxalpha will not match the PWS 433au. (3) firefox_obj/config/autoconf.mk Added -Wl,--no-relax to DSO_LDOPTS. There's an outstanding bug in the GNU ld relax code from 2007 that causes the libxul.so build to fail. Item (3) is the only mod that's made to a generated file. There's probably a way to fix DSO_LDOPTS prior to generating the autoconf.mk file, but I couldn't find it. So the build procedure is something like (a) apply mods (1) and (2). (b) run gmake -f client.mk build. (c) after the build is well under way, but before it gets to libxul.so, apply mod (3). -- Bob Tracy | I was a beta tester for dirt. They never did [EMAIL PROTECTED] | get all the bugs out. - Steve McGrew on /. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch -- lenny upgrade report on Alpha platform
On Fri, Oct 17, 2008 at 05:23:17PM +1300, Michael Cree wrote: On 17/10/2008, at 3:56 PM, Bob Tracy wrote: Trying to roll my own firefox 3 has been educational to say the least. Yeah, I also tried to compile firefox from source, and after noting the completely non-standard build, the confusing options in the configure script, and the lack of installation instructions, my reaction was WTF and gave up. I've also tried to build GNU icecat, the FSF's modified firefox. I think it links xulrunner statically, and after making a couple of changes to the Makefiles (to correctly include some Alpha specific code since it misdetected my Alpha, and to turn off -Werror on a module so that compilation can continue) it fails on the final linking stage with gprel errors, and that some library has objects that it can't relocate or something (I'm working off memory here). Looking at the Alpha compiler options in the gcc manual I see there is mention of small data area where data are accessed via 16-bit references from the $gp register. So I tried inserting -mlarge-data options to the compilation in the hope it might fix it, but still got the relocation errors at linking. I understand what 16-bit relative addressing means, but I don't really understand (from the gcc manual) what the options to modify compilation to use different data referencing schemes are really doing, and what one can do to avoid getting gprel relocation errors (my reading of the gcc manual suggested that -mlarge-data should've worked). Thanks for the *very* large clue as to what's going on. A quick search of bug reports led me to try adding -Wl,--no-relax to DSO_LDOPTS in mozilla/firefox_obj/config/autoconf.mk. The libxul.so build now succeeds! Here's the unfortunate part: the GNU ld relax bug was observed and reported back in 2007... I don't have the link handy, but Google found it pretty quickly when I searched for the relocation error string. If I get a working firefox-3.0.3 out of all this, debian-alpha will be the first to know about it... -- Bob Tracy | I was a beta tester for dirt. They never did [EMAIL PROTECTED] | get all the bugs out. - Steve McGrew on /. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch -- lenny upgrade report on Alpha platform
Bob Tracy wrote: Someone asked me why I don't try iceweasel. I have... Version 3.0.1-1 bombs consistently with an illegal instruction, Yes, I have the same problem. Iceweasel 3.0.1-1 crashes on invocation. I see a similar problem was reported for x64, Debian bug #492488, so I added a backtrace of the iceweasel crash on Alpha to that bug report. Iceweasel 3.0.3 is on its way to unstable (i386 is there, but the other architectures are still to be uploaded). Cheers Michael. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch -- lenny upgrade report on Alpha platform
[EMAIL PROTECTED] wrote: Someone asked me why I don't try iceweasel. I have... Version 3.0.1-1 bombs consistently with an illegal instruction, even if all plugins are disabled and my .mozilla directory is moved out of the way. I thought I might try looking at the iceweasel source package to see how Debian got around the libxul.so issue, and the answer seems to be use xulrunner-dev. I might try that in a few days, but I've got a 2.6.27-final kernel build to do first :-). It may be of interest that I couldn't get any gecko based browser to run on my alpha either after installing lenny. It seemed that Javascript was to blame. I could start epiphany-webkit, but it too bombed on any page with javascript. I need to investigate further. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch -- lenny upgrade report on Alpha platform
On Thu, Oct 16, 2008 at 11:07:17PM +1300, Michael Cree wrote: Bob Tracy wrote: Someone asked me why I don't try iceweasel. I have... Version 3.0.1-1 bombs consistently with an illegal instruction, Yes, I have the same problem. Iceweasel 3.0.1-1 crashes on invocation. I see a similar problem was reported for x64, Debian bug #492488, so I added a backtrace of the iceweasel crash on Alpha to that bug report. Very cool. Thanks for the input. For what it's worth, 3.0.3-2 hit testing sometime in the past few days: the update was downloaded and installed last night. Unfortunately, the crash on invocation is still happening. Trying to roll my own firefox 3 has been educational to say the least. Found several blog entries to the effect that the Linux distros (Debian evidently included) are building firefox on top of xulrunner rather than attempting to build firefox the official way (private copy of the XUL stuff). That's a bit further down the rabbit hole than I originally intended to go :-). I'll try a static build (ac_add_options --enable-static --disable-libxul: officially discouraged) before giving up. -- Bob Tracy | I was a beta tester for dirt. They never did [EMAIL PROTECTED] | get all the bugs out. - Steve McGrew on /. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch -- lenny upgrade report on Alpha platform
On 5/10/2008, at 6:50 PM, Michael Cree wrote: Jay Estabrook wrote: OK, here are the patches I mentioned, plus one. You may already have some, or may not need some, but for completeness: 1. dbus-alpha-unaligned.patch force gcc to generate proper code; it normally assumes structures are aligned. 2. hal-0.5.10-cache-alignment.patch force proper alignment of elements larger than 32 bits Has anyone tried these patches? I managed to apply the dbus patch to debian dbus-1.2.1-3 and dbus's unaligned trap verbiage has been tamed. Nice. But hald has decided, presumably because of the silence due to dbus's absence:-/, to let fly with tons of unaligned trap messages. But I can't the hal patch to apply cleanly to debian hal 0.5.11-3. Just to let people know, with some guidance from Jay, I have tracked down the problem. Being new to using the Debian package build system I didn't realise that it placed the libdbus-1 shared library into a different package than dbus, and so when I installed my patched dbus package, it updated dbus-daemon, but not libdbus-1.so. The UAAs from hal are due to the libdbus-1 library, and the patch dbus-alpha- unaligned.patch fixes not only dbus-daemon, but a number of programs including hal. The patch hal-0.5.10-cache-alignment.patch is not needed on the Debian supplied hal, as a fix is already included. I see Debian hal bug #368863 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=368863 ) is still open. I will send a message to the bug tracker later today to advise the hal maintainers that hal unaligned trap is fixed and that the remaining traps are due to libdbus-1. I have searched the Debian bug database for package dbus and there is no bug logged for unaligned traps. Later today I will log a bug report on the dbus package and upload Jay's patch. Cheer Michael. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch -- lenny upgrade report on Alpha platform
On Thu, Oct 16, 2008 at 11:19:17AM +1300, Michael Cree wrote: I see Debian hal bug #368863 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=368863 ) is still open. I will send a message to the bug tracker later today to advise the hal maintainers that hal unaligned trap is fixed and that the remaining traps are due to libdbus-1. I have searched the Debian bug database for package dbus and there is no bug logged for unaligned traps. Later today I will log a bug report on the dbus package and upload Jay's patch. Thanks. I've been a slug and haven't gotten around to doing much with my Alpha other than cursing my inability to get firefox-3.0.3 to build. The journey started when I wanted to try building firefox-3.x, and discovered I needed to upgrade from etch to lenny to get the necessary library versions to even attempt a build. The good news is, gcc/g++-4.2.4 and the associated binutils will probably get the job done at some point, whereas I had to use gcc/g++-3.3 back in the firefox-2.0.0.13 timeframe: the 4.x compilers were badly confused by the mess that is the mozilla source tree. The bad news is, I can't get past the link step that builds libxul.so, regardless of which compiler version I use. Someone asked me why I don't try iceweasel. I have... Version 3.0.1-1 bombs consistently with an illegal instruction, even if all plugins are disabled and my .mozilla directory is moved out of the way. I thought I might try looking at the iceweasel source package to see how Debian got around the libxul.so issue, and the answer seems to be use xulrunner-dev. I might try that in a few days, but I've got a 2.6.27-final kernel build to do first :-). -- Bob Tracy | I was a beta tester for dirt. They never did [EMAIL PROTECTED] | get all the bugs out. - Steve McGrew on /. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch -- lenny upgrade report on Alpha platform
Bother, meant to reply to list. Trying again. Jay Estabrook wrote: OK, here are the patches I mentioned, plus one. You may already have some, or may not need some, but for completeness: 1. dbus-alpha-unaligned.patch force gcc to generate proper code; it normally assumes structures are aligned. 2. hal-0.5.10-cache-alignment.patch force proper alignment of elements larger than 32 bits Has anyone tried these patches? I managed to apply the dbus patch to debian dbus-1.2.1-3 and dbus's unaligned trap verbiage has been tamed. Nice. But hald has decided, presumably because of the silence due to dbus's absence:-/, to let fly with tons of unaligned trap messages. But I can't the hal patch to apply cleanly to debian hal 0.5.11-3. Hal, at line 175, module hald/create_cache.c has: #define ROUND(len,align) ((len + align - 1) -align) #define ROUND32(len) ROUND(len, 4) #define RULES_ROUND(off) ROUND(off, __alignof__(struct rule)) whereas the patch, hunk 1, has: -#define ROUND32(len) ((len + 3) ~0x03) +#define SZ (sizeof(size_t)) +#define SZM (SZ - 1) +#define ROUNDXX(len) ((len + SZM) ~SZM) which fails to match because of the ROUND() and the RULES_ROUND() lines which the patch is not expecting. Other hunks also fail because of the use of RULES_ROUND() at places the patch is not expecting. To apply the patch is going to need some editing of the code/patch. If I was feeling brave I would give it a go, but wondered if anyone has already got a solution? Michael. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch -- lenny upgrade report on Alpha platform
On Mon, Aug 25, 2008 at 09:35:29AM -0500, Bob Tracy wrote: On Sun, Aug 24, 2008 at 11:09:20AM -0700, Steve Langasek wrote: A report against upgrade-reports would definitely be useful here, and in particular I think we would want a copy of /var/log/apt/term.log covering the upgrade attempt in question, to see what packages failed to upgrade and why. (The failing packages should be considered RC-buggy, and fixed before the release.) Arrgh! I don't know what might cause initialization/truncation of term.log, but the oldest entry in the file is at least a day after the upgrade failed. The best I can do at this point is rely on my admittedly faulty memory and say that the wheels came off the upgrade process during installation of the Gnome packages. The log is rotated periodically - how about /var/log/apt/term.log.1.gz? (Xorg radeon driver DefaultConnectorTable option required(?) on Alpha and possibly other non-x86 platforms.) Ah, nice... :) That sounds like it should be a separate bug report on the radeon package, then? Would you call it a bug, or simply a configuration detail that needs to be noted during installation on non-x86 platforms? Sounds like a bug to me. :) Similar issue with radvd, but I reported *that* one (with a code workaround) back in December 2007 (bug id# 456205). At least with radvd, the underlying issue is use of a character array and later trying to force a particular structure alignment on it. The workaround was to force 8-byte (sizeof(size_t)) alignment on the offending array using __attribute__ ((aligned(8))). I've prodded the maintainer about this now, perhaps radvd can still be fixed in time for lenny. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch -- lenny upgrade report on Alpha platform
On Thu, Aug 28, 2008 at 01:34:32AM -0700, Steve Langasek wrote: The log is rotated periodically - how about /var/log/apt/term.log.1.gz? No old logs in /var/log/apt: looks like we're SOL this time around :-(. (radvd problem reported back in Dec. 2007) I've prodded the maintainer about this now, perhaps radvd can still be fixed in time for lenny. I'd love to see Jay Estabrook's fixes for hal and dbus make it into lenny as well. Can't vouch for the ghostscript and qt fixes only because I haven't encountered the problems they address. Jay -- are there corresponding bug IDs for the affected packages? -- Bob Tracy | I was a beta tester for dirt. They never did [EMAIL PROTECTED] | get all the bugs out. - Steve McGrew on /. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch -- lenny upgrade report on Alpha platform
On Sun, Aug 24, 2008 at 11:09:20AM -0700, Steve Langasek wrote: A report against upgrade-reports would definitely be useful here, and in particular I think we would want a copy of /var/log/apt/term.log covering the upgrade attempt in question, to see what packages failed to upgrade and why. (The failing packages should be considered RC-buggy, and fixed before the release.) Arrgh! I don't know what might cause initialization/truncation of term.log, but the oldest entry in the file is at least a day after the upgrade failed. The best I can do at this point is rely on my admittedly faulty memory and say that the wheels came off the upgrade process during installation of the Gnome packages. (Xorg radeon driver DefaultConnectorTable option required(?) on Alpha and possibly other non-x86 platforms.) Ah, nice... :) That sounds like it should be a separate bug report on the radeon package, then? Would you call it a bug, or simply a configuration detail that needs to be noted during installation on non-x86 platforms? Sheesh... I'm old enough to remember having to remind programmers that not all the world is a VAX :-). I'll *definitely* be filing a bug report on dbus-daemon... The system logs are full of the following (which also appear on the console): dbus-daemon(2382): unaligned trap at 0200010409fc: 00011f9d52a1 28 3 dbus-daemon(2382): unaligned trap at 020001040a1c: 00011f9d52a1 2c 1 Similar issue with radvd, but I reported *that* one (with a code workaround) back in December 2007 (bug id# 456205). At least with radvd, the underlying issue is use of a character array and later trying to force a particular structure alignment on it. The workaround was to force 8-byte (sizeof(size_t)) alignment on the offending array using __attribute__ ((aligned(8))). -- Bob Tracy | I was a beta tester for dirt. They never did [EMAIL PROTECTED] | get all the bugs out. - Steve McGrew on /. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch -- lenny upgrade report on Alpha platform
Bob Tracy wrote: I'll *definitely* be filing a bug report on dbus-daemon... The system logs are full of the following (which also appear on the console): dbus-daemon(2382): unaligned trap at 0200010409fc: 00011f9d52a1 28 3 dbus-daemon(2382): unaligned trap at 020001040a1c: 00011f9d52a1 2c 1 I believe I have a patch for this, along with one for the hal package, that'll keep the logs clean of those. I've also fixed one in qt that shows up as from *many* KDE apps. I'll round them up at work, and send them along... Similar issue with radvd, but I reported *that* one (with a code workaround) back in December 2007 (bug id# 456205). At least with radvd, the underlying issue is use of a character array and later trying to force a particular structure alignment on it. The workaround was to force 8-byte (sizeof(size_t)) alignment on the offending array using __attribute__ ((aligned(8))). Haven't seen that one before... --Jay++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch -- lenny upgrade report on Alpha platform
OK, here are the patches I mentioned, plus one. You may already have some, or may not need some, but for completeness: 1. dbus-alpha-unaligned.patch force gcc to generate proper code; it normally assumes structures are aligned. 2. hal-0.5.10-cache-alignment.patch force proper alignment of elements larger than 32 bits 3. qt-alpha-unaligned.patch force proper alignment for DOUBLEs encoded as char arrays 4. ghostscript-alpha-unaligned.patch force use of memset/memcpy instead of local (buggy on Alpha) optimized routines In my version of ghostscript, when rendering under Firefox pages full of postscript, sometimes I'd see as many as 200 Million UAAs for a single page. The others were just VERY annoying in logs and on console, amounting to only in the thousands over long periods of time. Hope they help. --Jay++ Estabrook, Jay wrote: Bob Tracy wrote: I'll *definitely* be filing a bug report on dbus-daemon... The system logs are full of the following (which also appear on the console): dbus-daemon(2382): unaligned trap at 0200010409fc: 00011f9d52a1 28 3 dbus-daemon(2382): unaligned trap at 020001040a1c: 00011f9d52a1 2c 1 I believe I have a patch for this, along with one for the hal package, that'll keep the logs clean of those. I've also fixed one in qt that shows up as from *many* KDE apps. I'll round them up at work, and send them along... Similar issue with radvd, but I reported *that* one (with a code workaround) back in December 2007 (bug id# 456205). At least with radvd, the underlying issue is use of a character array and later trying to force a particular structure alignment on it. The workaround was to force 8-byte (sizeof(size_t)) alignment on the offending array using __attribute__ ((aligned(8))). Haven't seen that one before... --Jay++ patches-for-debian.tgz Description: application/compressed-tar
Re: etch -- lenny upgrade report on Alpha platform
On Mon, Aug 25, 2008 at 10:42:03AM -0400, Jay Estabrook wrote: Bob Tracy wrote: I'll *definitely* be filing a bug report on dbus-daemon... The system logs are full of the following (which also appear on the console): dbus-daemon(2382): unaligned trap at 0200010409fc: 00011f9d52a1 28 3 dbus-daemon(2382): unaligned trap at 020001040a1c: 00011f9d52a1 2c 1 I believe I have a patch for this, along with one for the hal package, that'll keep the logs clean of those. I had momentarily forgotten about hal :-(. That's definitely still a problem. I've also fixed one in qt that shows up as from *many* KDE apps. I'll round them up at work, and send them along... Thanks! MUCH appreciated :-). Similar issue with radvd, but I reported *that* one (with a code workaround) back in December 2007 (bug id# 456205). At least with radvd, the underlying issue is use of a character array and later trying to force a particular structure alignment on it. The workaround was to force 8-byte (sizeof(size_t)) alignment on the offending array using __attribute__ ((aligned(8))). Haven't seen that one before... Install tspc and configure your Alpha as an IPv6 gateway/router. You'll definitely see it :-(. It's even more noisy than dbus-daemon, which is saying something. -- Bob Tracy | I was a beta tester for dirt. They never did [EMAIL PROTECTED] | get all the bugs out. - Steve McGrew on /. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch -- lenny upgrade report on Alpha platform
On Sun, Aug 24, 2008 at 01:29:43AM -0500, Bob Tracy wrote: In a nutshell, the instructions I found for doing the dist-upgrade were (1) Edit /etc/apt/sources.list (2) Change all occurrences of stable to testing. (3) apt-get update (4) apt-get dist-upgrade Step (4) successfully identified and downloaded 1.2 GB of updated packages, then bombed spectacularly during the installation of those packages. As near as I can tell, apt-get got extremely confused by all the interdependencies. After watching the train wreck to its conclusion (lots of error messages as apt-get's confusion increased), I found a few packages had been successfully upgraded in place. A few more were found installed, but unconfigured. Still more were in the forced-deconfigured state. I ended up spending the next several days manually installing packages with dpkg -i, occasionally having to specify --auto-deconfigure to get past some of the more stubborn cases of multiple dependencies. If it calculated an upgrade and started downloading packages, then that's a quite positive sign! It means that the ultimate upgrade failure is due to isolated bugs in one or more of the packages it was trying to install, and not a systemic issue with dependency changes between the two releases. A report against upgrade-reports would definitely be useful here, and in particular I think we would want a copy of /var/log/apt/term.log covering the upgrade attempt in question, to see what packages failed to upgrade and why. (The failing packages should be considered RC-buggy, and fixed before the release.) Separate report on the new Xorg radeon driver... There's a new feature enabled by default that attempts to use the video BIOS to determine if there's anything connected to any of the potentially multiple video outputs on the card (VGA and DVI to name two possibilities). There's no reason to expect that feature to function properly on a non-x86 platform, and in that respect, I wasn't disappointed :-). Specifying 'Option DefaultConnectorTable true' in xorg.conf causes the driver to assume a default video output configuration based on the detected chipset, and that got things working for me. The clue that led to trying that option? A line of output in the Xorg.0.log file where the driver indicated it was having to guess wildly. Needless to say, it chose poorly. Ah, nice... :) That sounds like it should be a separate bug report on the radeon package, then? Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
