Bug#378265: closed by Brice Goglin [EMAIL PROTECTED] (Bug#378265: xserver-xorg: Random X and system crash on Radeon Mobility M6 LY, Crusoe)
Thank you, apologies for not following up on this. I have not seen the problem in quite a long time, so closing it is appropriate. -Adam On Thu, 2007-05-24 at 06:48 +, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report #378265: xserver-xorg: Random X and system crash on Radeon Mobility M6 LY, Crusoe, which was filed against the xserver-xorg package. It has been closed by Brice Goglin [EMAIL PROTECTED]. Their explanation is attached below. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Brice Goglin [EMAIL PROTECTED] by replying to this email. Debian bug tracking system administrator (administrator, Debian Bugs database) email message attachment Forwarded Message From: Brice Goglin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug#378265: xserver-xorg: Random X and system crash on Radeon Mobility M6 LY, Crusoe Date: Thu, 24 May 2007 08:45:06 +0200 Mailer: Icedove 1.5.0.10 (X11/20070329) Version: 1:6.6.2-1 Closing as #366114. If the bug is not fixed as expected, please reopen. Brice -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378265: xserver-xorg: Random X and system crash on Radeon Mobility M6 LY, Crusoe
merge 378265 366114 thanks On Mon, 2006-07-17 at 11:32 +0200, Michel Dänzer wrote: On Fri, 2006-07-14 at 16:12 -0400, Adam C Powell IV wrote: Package: xserver-xorg Version: 7.0.22 Severity: important Greetings, My laptop, Fujitsu P2120 with Radeon Mobility M6 LY and Crusoe CPU, hangs while running xorg with the ati driver. This did not happen with 6.9.0, nor with xserver-xfree86-dbg (which the Crusoe CPU required, see bug 261251). No output because the machine hangs with nothing in the logs, it doesn't hang when I'm at the console. This happens under 2.6.15, .16 and .17 kernels. It never crashes when I halt/reboot from the GNOME Desktop menu, but always crashes when I log out. Otherwise, crashes are random with a half-life around 30-60 minutes. Sounds like this could be #366114. Indeed, sounds very similar, thanks. Funny thing is, I tried to reconfigure xserver-xorg to use the fbdev driver, but it seems to have left the Driver: ati in xorg.conf. It doesn't seem to take -- that is, xorg.conf doesn't reflect the changes I'm making in dpkg-reconfigure. How do I force it to use the fbdev driver? Thanks again, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html
Bug#378265: xserver-xorg: Random X and system crash on Radeon Mobility M6 LY, Crusoe
Package: xserver-xorg Version: 7.0.22 Severity: important Greetings, My laptop, Fujitsu P2120 with Radeon Mobility M6 LY and Crusoe CPU, hangs while running xorg with the ati driver. This did not happen with 6.9.0, nor with xserver-xfree86-dbg (which the Crusoe CPU required, see bug 261251). No output because the machine hangs with nothing in the logs, it doesn't hang when I'm at the console. This happens under 2.6.15, .16 and .17 kernels. It never crashes when I halt/reboot from the GNOME Desktop menu, but always crashes when I log out. Otherwise, crashes are random with a half-life around 30-60 minutes. Haven't tried the -dbg build. The fbdev driver has not crashed on me yet, and has passed the logout test. Cheers, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373248: x11-common: Needs conflict with realplayer, xserver-xfree86-dbg
Package: x11-common Version: 7.0.22 Greetings, The packages realplayer (8.0.6) and xserver-xfree86-dbg provide binaries in /usr/X11R6/bin and break installation of x11-common. Please add them to Conflicts. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354674: What on earth?
Greetings, Please tell me if I have this right: * You don't like .la files * So you're unilaterally removing them from a core package (libxcursor) with dozens of reverse-depends, breaking all of them * Even though they're a years-old and very well established technology * Which upstream libtool has not yet decided to eliminate (It's already under discussion) * And which has not been discussed on debian-devel or any other Debian list as far as I can tell (Google search). Can you really be serious? For example, if the maintainer of GLib decides (s)he doesn't like the way it handles modules, and upstream *might* at some point change the behavior, is that alone enough justification to change it and break all of its dozens of reverse-depending packages? -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354674: What on earth?
On Thu, 2006-04-13 at 11:12 -0400, Adam C Powell IV wrote: Greetings, Please tell me if I have this right: * You don't like .la files * So you're unilaterally removing them from a core package (libxcursor) with dozens of reverse-depends, breaking all of them * Even though they're a years-old and very well established technology * Which upstream libtool has not yet decided to eliminate (It's already under discussion) * And which has not been discussed on debian-devel or any other Debian list as far as I can tell (Google search). Okay, my mistake, the removal of .la files throughout X packages indicates that this was an X-wide decision, not an isolated developer. But I still don't see any discussion on Debian lists outside of this one bug. I guess that's why they call it unstable... Cheers, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354674: What on earth?
On Thu, 2006-04-13 at 19:12 +0300, Daniel Stone wrote: On Thu, Apr 13, 2006 at 11:12:06AM -0400, Adam C Powell IV wrote: Please tell me if I have this right: * You don't like .la files Yes. * So you're unilaterally removing them from a core package (libxcursor) with dozens of reverse-depends, breaking all of them Yes. * Even though they're a years-old and very well established technology .la files? I wouldn't call them 'very well established'. Okay, then 'widespread', as is evident from the number of broken packages. * Which upstream libtool has not yet decided to eliminate (It's already under discussion) And X.Org upstream are currently seriously discussing whether or not to eliminate libtool, at which point you get broken away. This, believe it or not, a) improves portability, and b) makes you immune to further changes. Okay, I misunderstood, s/libtool/Xorg/. Even so, what further changes? There are no further changes yet, there are merely discussions. This doesn't change that you acted unilaterally. * And which has not been discussed on debian-devel or any other Debian list as far as I can tell (Google search). Yes. This is the main problem. In numerous other transitions, from udev/hal to C++, we had fair warning and could coordinate release schedules. See Steve's post. Can you really be serious? Yes. For example, if the maintainer of GLib decides (s)he doesn't like the way it handles modules, and upstream *might* at some point change the behavior, is that alone enough justification to change it and break all of its dozens of reverse-depending packages? If the dependent packages can be fixed with a rebuild, and the reason is solid, rather than, 'I'm bored'? Yes. So I'm supposed to rebuild all of the dependencies between my package and libxcursor, like multiple GNOME and KDE libraries (GNOME in my case), just to build my package? And then what? Upload it? I can't, because those intermediate libs are broken in unstable, so it won't autobuild. And who's to say the interfaces won't change before the next upload of those intermediates? For example, GNOME is in the middle of its 2.12-2.14 transition, with dozens of packages in flight from alioth via experimental. It would *really* have helped if you had let them know of these plans *before* they started uploading 2.14 packages. Now everybody needs to wait while the maintainers of those packages build and upload. In the correct order. Regardless of other release plans. With no notice. *Think* for a moment about the consequences. This is not a simple rebuild, this is a serious problem. Is a rebuild really that phenomenally onerous for you? In the time spent arguing this point, tons of packages could've been simply rebuilt. I don't see where the problem lies, unless you happen to enjoy random flamebait more than actual productive work. Flamebait? Well, if you consider discussions on stranding a large fraction of Debian's 1000 part-time volunteer developers without the ability to build their packages in unstable to be random flamebait, I really can't help you. Regards, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354674: What on earth?
On Thu, 2006-04-13 at 19:58 -0400, David Nusinow wrote: On Thu, Apr 13, 2006 at 07:09:55PM -0400, Adam C Powell IV wrote: *Think* for a moment about the consequences. This is not a simple rebuild, this is a serious problem. I agree and I take full responsibility for the issue. I'm sorry for the trouble. I'm fully willing to put back the .la files on request from the release team, who I should definitely have coordinated with beforehand. Note that I would have done so if I'd realized the magnitude of the problem, and not doing so was entirely my error. Wow. Thank you. This would help in the short term, though I suspect the damage is done and the other packages are fixing their bugs at this point. I agree that the release team should decide. I hope such problems can be avoided in the future. Cheers, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#216933: Release notes: please include cantfix Crusoe/X bug 216933
Greetings and apologies for the delay, First, in http://www.debian.org/releases/testing/i386/release-notes/ it does not seem that there's a natural place for known bugs, so that will need to be created, perhaps at the end or under Detailed changes to the system. So here is the sample text: The X server shipping in Debian 3.1 contains optimized code which is not properly executed by many Transmeta(TM) Crusoe(TM) processors. The result of this is that at a certain time (when cached code morphed from x86 to Crusoe VLIW instructions in the CPU is in a buggy state), X client applications which connect with it fail with the following error message: X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 18 (X_ChangeProperty) Serial number of failed request: 15 Current serial number in output stream: 18 In practical terms, this means that after a few hours of operation, applications will suddenly quit in rapid succession; if a display manager is running, that too will repeatedly quit and attempt to restart itself. The state will persist until the buggy VLIW Transmeta code is flushed from the cache. The workaround for this bug is to install an X server compiled without optimization, such as the xserver-xfree86-dbg package. Since the bug is in the proprietary Transmeta Code Morphing Software (CMS), and the laptop BIOS checks the CMS for a vendor signature at boot time, only cooperation between Transmeta and the laptop vendor can fix this. Thus far, only HP is known to have done this for the Compaq TabletPC TC1000 family (http://h18007.www1.hp.com/support/files/compaqtabletpc/us/download/18120.html), and Transmeta has dropped support for their proprietary CMS, making further fixes unlikely. For more details, see Debian bug #216933, freedesktop.org bugzilla id 455 (https://bugs.freedesktop.org/show_bug.cgi?id=455) and detailed technical analysis and a list of known platforms with the bug at http://www.cs.auc.dk/~fleury/bug_cms/ . On Fri, 2005-05-06 at 20:07 +0100, Rob Bradford wrote: Adam C Powell IV wrote: I'd be happy to suggest wording for such a section, just let me know. Please do this and send it to me and CC [EMAIL PROTECTED] Cheers, Rob -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#216933: Release notes: please include cantfix Crusoe/X bug 216933
Greetings, There's a major X stability problem with Transmeta Crusoe CPUs and Radeon Mobility graphics hardware, discussed in Debian bug 216933, in X.org bugzilla, and at http://www.cs.auc.dk/~fleury/bug_cms/ . This bug causes X to crash seemingly randomly at a rate of approximately every 2-5 hours, depending on applications running and various other factors. It has been the bane of my existence since I upgraded to sarge last February. Fortunately, there is a workaround, which is to install the -dbg flavor of the X server. For the sake of our users, I feel we should put this in a known bugs section of the Sarge/3.1 release notes for the i386 platform. I hate to think that users of stable will have to deal with such a significant problem without any warning/documentation, so at least documenting it prominently would probably help such users quite a bit. I'd be happy to suggest wording for such a section, just let me know. Please CC me in replies. Thanks, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#258399: xlibs: dvorak keyboard layout is missing right alt key
On Thu, 2004-10-07 at 18:41, Branden Robinson wrote: On Tue, Aug 31, 2004 at 07:31:32PM -0400, Adam C Powell IV wrote: I see, so dvorak has different right alt behavior from pc/us. Thank you for the detailed explanation. [...] Hmm... I am satisfied, but the next guy to come along using dvorak might not be, so it's good enough for me, but not necessarily good enough for Debian. Let's leave it open, I don't want to take any more of your time, so I'll try to create another variant myself and send it to this bug as a patch. I should be able to get to it in the next day or two. Any luck with this? Not yet I'm afraid. Feel free to close it, and if I get around to learning how to do this I'll either reopen it if it's within 30 days or open a new wishlist bug. Thanks for your diligence and attention to this very minor bug. :-) -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Bug#258399: xlibs: dvorak keyboard layout is missing right alt key
On Tue, 2004-08-31 at 18:08, Denis Barbier wrote: On Mon, Aug 30, 2004 at 12:08:07PM -0400, Adam C Powell IV wrote: [...] Interestingly, I had thought that the absence of Alt_R in mod2 was the problem with the Dvorak/switched layout. But it's also missing in the default US/no switch layout, in which right Alt works just fine... FYI, in the case of Dvorak/no switch, right Alt does nothing; with US/switch, right Alt works fine. So Dvorak seems to be the problem. Great, thank you for your detailed report. Your analysis is right, swapcaps and mod2 are not causing this bug. Since xmodmap output is similar in both cases, one could believe that their modifiers are the same, but this is wrong. The difference is more subtle, it becomes visible when running $ xmodmap -pke | grep 113 (because 113 is the keycode of right Alt key in your case) with both layouts (do not swap caps/ctrl to make less changes) and compare their output: keycode 113 = Alt_R Meta_R keycode 113 = ISO_Level3_Shift Multi_key With pc/us, right Alt key is bound to Alt_R Meta_R. Unfortunately xmodmap does not tell why Alt_R is bound to mod1, this is because XKB is much more powerful and xmodmap is unable to display all details. The reason can be found by running $ xkbcomp :0 and searching for Alt_R in the generated server-0.xkb file. OTOH right Alt key is bound to ISO_Level3_Shift (and thus mod5) with dvorak layout, so pressing this key grabs the 3rd column found in /etc/X11/xkb/symbols/pc/dvorak (ie. dead keys). This event is intercepted by XKB and not sent to your window manager. So in fact, your right Alt key works as expected, but not as you want. I see, so dvorak has different right alt behavior from pc/us. Thank you for the detailed explanation. This bug should either be fixed by providing a pure ASCII dvorak variant, or you have to bind your right Alt key to mod1. I believe that selecting altwin:meta_alt option does the trick. In such a case, can this bugreport be closed, or do you really need another variant? Hmm... I am satisfied, but the next guy to come along using dvorak might not be, so it's good enough for me, but not necessarily good enough for Debian. Let's leave it open, I don't want to take any more of your time, so I'll try to create another variant myself and send it to this bug as a patch. I should be able to get to it in the next day or two. Thanks, -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Bug#258399: xlibs: dvorak keyboard layout is missing right alt key
On Thu, 2004-08-26 at 15:37, Denis Barbier wrote:
Adam C Powell IV wrote:
On Wed, 2004-08-25 at 16:38, Branden Robinson wrote:
[snip]
So I'm thinking the fix is to apply the above, then modify the
symbol maps such that (in most cases) any keys that get modifier
mappings are cleared first.
This solution will absolutely positively need testing.
No, original bugreport is against -4, so this is a different issue.
And 'modifier_map none' does not appear in XFree86 CVS, so shipping
files with this construct seems very risky. OTOH incorporating 667
would be nice since users may try this syntax if everything else
fails.
I see. Thanks for the rapid response! Let me know how I can help with
testing.
What does
$ xmodmap
$ setxkbmap -print
display? You told that your right alt key is missing, what does xev
tell when it is pressed? And what is this key supposed to do in your
environment?
This is with the GNOME keyboard manager set to the Dvorak layout with
left Ctrl and caps lock switched:
54 p4-117-1% xmodmap
xmodmap: up to 3 keys per modifier, (keycodes in parentheses):
shift Shift_L (0x32), Shift_R (0x3e)
lockCaps_Lock (0x25)
control Control_L (0x42), Control_R (0x6d)
mod1Alt_L (0x40), BadKey (0x7d), BadKey (0x9c)
mod2Num_Lock (0x4d)
mod3
mod4BadKey (0x7f), BadKey (0x80)
mod5Mode_switch (0x5d), ISO_Level3_Shift (0x7c)
55 p4-117-1% setxkbmap -print
xkb_keymap {
xkb_keycodes { include xfree86+aliases(qwerty) };
xkb_types { include complete };
xkb_compat{ include complete };
xkb_symbols { include pc/pc(pc104)+pc/dvorak+ctrl(swapcaps) };
xkb_geometry { include pc(pc104) };
};
Now when I use the capplet to remove Dvorak and add U.S. English, and
remove the ctrl-caps lock switch (IOW, revert to defaul settings):
56 p4-117-1% xmodmap
xmodmap: up to 3 keys per modifier, (keycodes in parentheses):
shift Shift_L (0x32), Shift_R (0x3e)
lockCaps_Lock (0x42)
control Control_L (0x25), Control_R (0x6d)
mod1Alt_L (0x40), BadKey (0x7d), BadKey (0x9c)
mod2Num_Lock (0x4d)
mod3
mod4BadKey (0x7f), BadKey (0x80)
mod5Mode_switch (0x5d), ISO_Level3_Shift (0x7c)
57 p4-117-1% setxkbmap -print
xkb_keymap {
xkb_keycodes { include xfree86+aliases(qwerty) };
xkb_types { include complete };
xkb_compat{ include complete };
xkb_symbols { include pc/pc(pc104)+pc/us};
xkb_geometry { include pc(pc104) };
};
Interestingly, I had thought that the absence of Alt_R in mod2 was the
problem with the Dvorak/switched layout. But it's also missing in the
default US/no switch layout, in which right Alt works just fine...
FYI, in the case of Dvorak/no switch, right Alt does nothing; with
US/switch, right Alt works fine. So Dvorak seems to be the problem.
Thanks much,
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: Everything gtk is crashing!
On Tue, 2004-08-24 at 15:15, Aaron M. Ucko wrote: Your laptop has a Transmeta processor, right? If so, I believe you're running into Bug#216933 (aka #234556 and #261251)... Yes! That sounds like it. Thanks for the pointer. -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Bug#258399: xlibs: dvorak keyboard layout is missing right alt key
Hello again and apologies for the delay, On Tue, 2004-07-13 at 00:44, Branden Robinson wrote: tag 258399 + moreinfo upstream thanks On Fri, Jul 09, 2004 at 08:48:38AM -0400, Adam C Powell IV wrote: Package: xlibs Version: 4.3.0.dfsg.1-4 Severity: minor Greetings, On switching from a normal US layout to the dvorak layout in GNOME (on a PC), I've lost the use of the right alt key... I think this is the sort of thing the unpopular modifier key change backported from upstream in -5 was intended to address. Can you reproduce this problem with 4.3.0.dfsg.1-6? Yes. I've upgraded xlibs[-data] and the individual libraries on which it depends, and xserver-[xfree86|common], and the problem persists. Of course, this is still just testing with a newer X, though libxklavier is at its newest version, but other old packages could be causing this... Please let me know if you need any further information. -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Everything gtk is crashing!
Greetings, On my laptop, a Fujitsu P2120 with a Radeon Mobility M6 LY running testing and kernel 2.6.3 (because alsa doesn't work with 2.6.6 or 2.6.7 with the ALi M5451), from time to time all gtk+ apps spontaneously start to crash. The error messages in .xsession-errors look like: The program 'gnome-panel' received an X Window System error. This probably reflects a bug in the program. The error was 'BadLength (poly request too large or internal Xlib length erro'. (Details: serial 33 error_code 16 request_code 18 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Gnome-Message: gnome_execute_async_with_env_fds: returning -1 The program 'evolution-alarm-notify' received an X Window System error. This probably reflects a bug in the program. The error was 'BadLength (poly request too large or internal Xlib length erro'. (Details: serial 33 error_code 16 request_code 18 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Trouble is, because everything crashes (except enlightenment, so I exit X by logging out of E from the middle-button menu), and nothing new linked to gtk+ will start up again, I can't very well debug with --sync. The problem persists through X restarts, only a reboot fixes it. Very often this happens soon after start-up, with gdm repeatedly crashing until either I can accumulate enough keystrokes in the console between crashes to log in as root and reboot, or it gives out, or I give up and hard reset the machine. If it gets past gdm, the machine has about a two-hour half-life before the behavior forces a reboot. Also on this laptop and only this laptop, every 10-20 minutes X slows to a crawl, with the monitor applet still running and showing 100% CPU usage, of which 20-30% is system. Any ideas? I'm not subscribed to debian-x, so if you reply to only that list (and not debian-gtk-gnome), please CC me. -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Bug#258399: xlibs: dvorak keyboard layout is missing right alt key
Package: xlibs Version: 4.3.0.dfsg.1-4 Severity: minor Greetings, On switching from a normal US layout to the dvorak layout in GNOME (on a PC), I've lost the use of the right alt key... Thanks, -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: please build XFree86 4.3.0 for experimental
On Fri, 2003-10-31 at 16:15, Branden Robinson wrote:
On Fri, Oct 31, 2003 at 07:54:08AM -0500, Adam C Powell IV wrote:
Is anyone building -0pre1v4? If not I've got a build going and can
upload when it's done. (Tried to install -0pre1v3 last night, but
xlibs-data is only -0pre1v4.)
I would very much like to see an ARM upload of -0pre1v4.
Okay, finally finished building this morning (various difficulties), and
installed successfully; just uploaded. Sorry about the delay.
And good news, it even seems to work! But I haven't pushed it yet...
Also, I noticed two problem along the way. First, there seems to be a
circular dependency here. xfree86 needs libxcursor-dev to build. But
libxcursor1 depends on xlibs. So one needs xlibs-dev 4.2.x installed in
order to build xcursor, though when xfree86 4.3.0 goes into unstable,
there will be no xlibs-dev 4.2.x. Long-term, any release of xcursor
while xfree86 is building (and thus is uninstallable on some arches)
breaks stuff, so IMO this is a serious bug.
Unless I'm misunderstaning you, this is no different from the
build-dependency loop between tetex-base and xfree86.
(TeTeX depends on Xlib for xdvi, and XFree86 depends on TeTeX to
generate docs.)
You're right, I hadn't thought of that.
The new problem with 4.3.0 is the versioned dependency of xlibs on
xlibs-data. So there is a problem if new tetex or xcursor source is
uploaded between the upload of xlibs-data and xlibs. If, say, MIPS is
slow to build xfree86, then tetex/xcursor will be impossible to
autobuild in the meantime, because xlibs-dev will be impossible to
install. And then, if a new X is uploaded before this is resolved,
neither one can be built because neither is installable.
Even worse, autobuilding X becomes totally impossible once xlibs-data is
accepted, because to build it, one must install libxcursor-dev, which
requires installing xlibs, which is not installable because it is old
and xlibs-data is new. So one must have previously installed either
xlibs 4.2.x or else *both* the old xlibs *and* old xlibs-data, then one
can install libxcursor-dev, then one can build the new X. Or one could
have previously installed libxcursor-dev and tetex-bin (which is why I
didn't notice this wrt tetex), but the autobuilders of course have none
of these.
There are two ways to resolve this: break the dependency of libxcursor1
on xlibs (or change it to Recommends or Suggests), or soften the
version requirement of the dependency relationship between xlibs and
xlibs-data (e.g. = 4.3.0 or even =${Source-Version} will solve
this problem, though it may break in other subtle ways).
I broke the circular dep manually by forcing libxcursor1 to install
though xlibs was not configured (wouldn't configure without xlibs-data
at the same version). But the only sane long-term workaround I can
think of is to remove the dependency between libxcursor1 and xlibs, and
just let applications depend on both shlib packages.
I don't understand.
See above.
Second, xlibs-data asks manually if I want to accept new versions of
*all* of its config files the first time it's installed. I'm not sure
about what can be done about this, since those files seem to be moving
from one package to another, but it's a bit annoying...
xfree86 (4.3.0-0pre1v5) experimental; urgency=low
[...]
* Update xlibs and xlibs-data's package descriptions to clarify that X
Keyboard Extension (XKB) data is in xlibs, but other
architecture-independent data is in xlibs-data. The XKB data has not
moved because dpkg supports no mechanism for migrating conffiles between
packages, and it is unacceptable for people to be spuriously shown dpkg's
changed-conffile prompt dozens of times when upgrading from versions of
xlibs prior to 4.3.0.
- debian/control
-0pre1v5 isn't released yet, but the above change has already been made.
Thank you, this helps a lot! It would be much better of course if dpkg
could migrate conffiles, but that sounds like a lot of work...
Now ARM folk, any chance of some help with 212569? (my Tuesday post
about Mozilla regxpcom/regchrome and C++ on our beloved platform...)
Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: please build XFree86 4.3.0 for experimental
Hello, Is anyone building -0pre1v4? If not I've got a build going and can upload when it's done. (Tried to install -0pre1v3 last night, but xlibs-data is only -0pre1v4.) Also, I noticed two problem along the way. First, there seems to be a circular dependency here. xfree86 needs libxcursor-dev to build. But libxcursor1 depends on xlibs. So one needs xlibs-dev 4.2.x installed in order to build xcursor, though when xfree86 4.3.0 goes into unstable, there will be no xlibs-dev 4.2.x. Long-term, any release of xcursor while xfree86 is building (and thus is uninstallable on some arches) breaks stuff, so IMO this is a serious bug. I broke the circular dep manually by forcing libxcursor1 to install though xlibs was not configured (wouldn't configure without xlibs-data at the same version). But the only sane long-term workaround I can think of is to remove the dependency between libxcursor1 and xlibs, and just let applications depend on both shlib packages. Second, xlibs-data asks manually if I want to accept new versions of *all* of its config files the first time it's installed. I'm not sure about what can be done about this, since those files seem to be moving from one package to another, but it's a bit annoying... Apologies if these have already been discussed (or solved?) on debian-x; please CC me on posts to that list (though I'm on debian-arm, so if you reply to both lists I'm all set). On Wed, 2003-10-08 at 04:31, Philip Blundell wrote: On Tue, 2003-10-07 at 23:27, Branden Robinson wrote: Please, please, build xfree86 4.3.0-0pre1v3 from experimental for your architecture. Othmar, I thought you built and uploaded this several days ago. What's up? -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: # Re: XFree86 4.2 Debian packages for Alpha
Branden Robinson wrote: On Tue, Oct 22, 2002 at 01:29:04PM +0200, [EMAIL PROTECTED] wrote: Dear Falk and Lists You'r right, new unstable libc sounds a bit to unstable for me... Is there any way to replase the xfree86 4.1 in Woody with the 4.2 version, without having to be a Debian expert? I'm copying this to debian-alpha@lists.debian.org and debian-x@lists.debian.org for further comments from you and others... You'd have to persuade the Stable Release Manager to permit such a thing, and frankly I think there is a greater chance of the Sun reversing its course across the sky. Because he is so busy he appears to be only permitting in security fixes and *nothing* else. Stability aside, I thought I saw somewhere that someone had built the X 4.2 packages for stable; a quick look on Debian Planet or some such should turn it up. If nothing else, at least it's easier than making the sun reverse its course across the sky... :-) Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: # Re: XFree86 4.2 Debian packages for Alpha
Branden Robinson wrote: On Tue, Oct 22, 2002 at 01:29:04PM +0200, [EMAIL PROTECTED] wrote: Dear Falk and Lists You'r right, new unstable libc sounds a bit to unstable for me... Is there any way to replase the xfree86 4.1 in Woody with the 4.2 version, without having to be a Debian expert? I'm copying this to [EMAIL PROTECTED] and [EMAIL PROTECTED] for further comments from you and others... You'd have to persuade the Stable Release Manager to permit such a thing, and frankly I think there is a greater chance of the Sun reversing its course across the sky. Because he is so busy he appears to be only permitting in security fixes and *nothing* else. Stability aside, I thought I saw somewhere that someone had built the X 4.2 packages for stable; a quick look on Debian Planet or some such should turn it up. If nothing else, at least it's easier than making the sun reverse its course across the sky... :-) Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xfree86 4.2.1-0pre1v1 (mips,mipsel,m68k,powerpc,sh4) available at the X Strike Force
Branden Robinson wrote: [Please direct follow-ups to debian-x.] I hadn't sent an update on these packages, but XFree86 4.2.1 pre-release packages are now available for the five architectures mentioned in the subject line, as well as for Alpha, i386, and SPARC, which were already announced. I still need builds for the following architectures: * ARM * HP-PA * IA-64 (I'm handling this one) * S/390 Othmar Pasteka was working on an ARM build but apparently debussy hung while compiling it. I hope it wasn't the XFree86 build that caused it! I'd be happy to do ARM... consider it started. Where do I upload to? -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: xfree86 4.2.1-0pre1v1 (mips,mipsel,m68k,powerpc,sh4) available at the X Strike Force
Adam C Powell IV wrote: Branden Robinson wrote: Othmar Pasteka was working on an ARM build but apparently debussy hung while compiling it. I hope it wasn't the XFree86 build that caused it! I'd be happy to do ARM... consider it started. Where do I upload to? Oops, forgot how much disk space this takes. I'll give it a try, but it will likely fail, my unstable chroot has only ~400 MB available. Speaking of disk space, why is tetex-bin in Build-Depends and not Build-Depends-Indep? Is there documentation built using it in binary-arch? Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: xfree86 4.2.1-0pre1v1 (mips,mipsel,m68k,powerpc,sh4) available at the X Strike Force
Adam C Powell IV wrote: Adam C Powell IV wrote: Branden Robinson wrote: Othmar Pasteka was working on an ARM build but apparently debussy hung while compiling it. I hope it wasn't the XFree86 build that caused it! I'd be happy to do ARM... consider it started. Where do I upload to? Oops, forgot how much disk space this takes. I'll give it a try, but it will likely fail, my unstable chroot has only ~400 MB available. Yup, not even close, moving the 100+MB of tarballs out of the way didn't help at all. Sorry, no can do. :-( -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: xfree86 4.2.1-0pre1v1 (mips,mipsel,m68k,powerpc,sh4) availableat the X Strike Force
Branden Robinson wrote: [Please direct follow-ups to debian-x.] I hadn't sent an update on these packages, but XFree86 4.2.1 pre-release packages are now available for the five architectures mentioned in the subject line, as well as for Alpha, i386, and SPARC, which were already announced. I still need builds for the following architectures: * ARM * HP-PA * IA-64 (I'm handling this one) * S/390 Othmar Pasteka was working on an ARM build but apparently debussy hung while compiling it. I hope it wasn't the XFree86 build that caused it! I'd be happy to do ARM... consider it started. Where do I upload to? -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xfree86 4.2.1-0pre1v1 (mips,mipsel,m68k,powerpc,sh4) availableat the X Strike Force
Adam C Powell IV wrote: Branden Robinson wrote: Othmar Pasteka was working on an ARM build but apparently debussy hung while compiling it. I hope it wasn't the XFree86 build that caused it! I'd be happy to do ARM... consider it started. Where do I upload to? Oops, forgot how much disk space this takes. I'll give it a try, but it will likely fail, my unstable chroot has only ~400 MB available. Speaking of disk space, why is tetex-bin in Build-Depends and not Build-Depends-Indep? Is there documentation built using it in binary-arch? Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xfree86 4.2.1-0pre1v1 (mips,mipsel,m68k,powerpc,sh4) availableat the X Strike Force
Adam C Powell IV wrote: Adam C Powell IV wrote: Branden Robinson wrote: Othmar Pasteka was working on an ARM build but apparently debussy hung while compiling it. I hope it wasn't the XFree86 build that caused it! I'd be happy to do ARM... consider it started. Where do I upload to? Oops, forgot how much disk space this takes. I'll give it a try, but it will likely fail, my unstable chroot has only ~400 MB available. Yup, not even close, moving the 100+MB of tarballs out of the way didn't help at all. Sorry, no can do. :-( -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.2.0-0pre1v1 available for Alpha and ARM
Branden Robinson wrote: [Note: I am not subscribed to the -arm or -alpha lists.] Thanks to Falk Hueffner and Phil Blundell for compiling these. The migration of people.d.o from klecker to gluck has finished, and I have restored my repository, which was unavailable for a few days. http://people.debian.org/~branden/sid/ Thanks! Works great for me on ARM, though bug 113022 persists. Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: New ARM elfloader patch
Guess what... it built! (Had to split it among the two local partitions and put relatively inactive stuff on NFS.) So the patches were successful that far; they're at: Adam C Powell IV wrote: Christian T. Steigies wrote: On Tue, Oct 09, 2001 at 04:04:51PM -0400, Adam C Powell IV wrote: http://lyre.mit.edu/~powell/debs/311_arm_compiler_h.diff http://lyre.mit.edu/~powell/debs/312_arm_elfloader.diff http://lyre.mit.edu/~powell/debs/350_mips_compiler_h.diff http://lyre.mit.edu/~powell/debs/400_hppa_support.diff Unpack the X source, then put all of these in debian/patches, and remove 310_arm_compiler_h.diff from that directory. Build logs are at: http://lyre.mit.edu/~powell/debs/xfree86_4.1.0-7.8.log http://lyre.mit.edu/~powell/debs/xfree86_4.1.0-7.8b.log (the first completed build and ran out of space in install; the second has install and binary-arch.) There was one warning worth noting, during the dh_movefiles substitute: cp: cannot stat `/redhat/packages/xfree86-4.1.0/debian/tmp/usr/X11R6/lib/modules/drivers/tdfx.o': No such file or directory Now the bad news: it doesn't work. :-( The debugging loader churns out over 30 MB of stuff, then dies with: ElfGetSymbolNameIndex(6b,a) afbCreateDefColormap 1 0 0 FBIOPUT_VSCREENINFO: Invalid argument Fatal server error: AddScreen/ScreenInit failed for driver 0 The (huge!) log and XF86Config (generated by debconf) are at: http://lyre.mit.edu/~powell/debs/XFree86.0.log http://lyre.mit.edu/~powell/debs/XF86Config-4 Does this much (this little) progress justify including the above patches in the X package? Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New ARM elfloader patch
[EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Adam C Powell IV writes: Ah, yes. You're right. If I tell it 8-bit, then it gets past that, and gets signal 4 later, after setting up the mouse. Oh well. Config and log at the same place as last time. But yes, the ELF loader might just be working... :-) Signal 4 is illegal instruction, which unfortunately points the finger of blame back at the loader. The log on its own isn't especially illuminating; can you run XFree86 under the debugger and find out what instruction it's tripping up on? Hmm. Must be an intermittent thing. I ran it in the debugger, and it came up just fine! Well, almost, the mouse was not happy, but that's because I was running gpm too. And the ctrl-alt commands didn't seem to work. With gpm turned off, startx ran perfectly! Well, slow as anything because of all the debugging info it's generating (though according to top, it uses 98% of CPU, so it's not a disk issue), it takes 3-4 minutes to start! Okay, out of six attempts, it has signal 4'd twice, one of those with gpm off. I'm afraid I've run out of time to work on this, I guess a few more runs under the debugger would do it. But in the meantime... I can log in via gdm, and run GNOME and Enlightenment, with ripples, and transparent gnome-terminal, and alpha-blended icons, and, and, it's so beautiful! Eight-bit color isn't the greatest, but, well, I'm pretty happy. Once the server is up, it seems pretty stable (okay, so I've just tested it for 30 minutes :-). I've moved the packages to http://lyre.mit.edu/~powell/debs/ for others to help test, and just share and enjoy! I'm short of time for the next couple of weeks, so it will be a while before I can work on this again. Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New ARM elfloader patch
Guess what... it built! (Had to split it among the two local partitions and put relatively inactive stuff on NFS.) So the patches were successful that far; they're at: Adam C Powell IV wrote: Christian T. Steigies wrote: On Tue, Oct 09, 2001 at 04:04:51PM -0400, Adam C Powell IV wrote: http://lyre.mit.edu/~powell/debs/311_arm_compiler_h.diff http://lyre.mit.edu/~powell/debs/312_arm_elfloader.diff http://lyre.mit.edu/~powell/debs/350_mips_compiler_h.diff http://lyre.mit.edu/~powell/debs/400_hppa_support.diff Unpack the X source, then put all of these in debian/patches, and remove 310_arm_compiler_h.diff from that directory. Build logs are at: http://lyre.mit.edu/~powell/debs/xfree86_4.1.0-7.8.log http://lyre.mit.edu/~powell/debs/xfree86_4.1.0-7.8b.log (the first completed build and ran out of space in install; the second has install and binary-arch.) There was one warning worth noting, during the dh_movefiles substitute: cp: cannot stat `/redhat/packages/xfree86-4.1.0/debian/tmp/usr/X11R6/lib/modules/drivers/tdfx.o': No such file or directory Now the bad news: it doesn't work. :-( The debugging loader churns out over 30 MB of stuff, then dies with: ElfGetSymbolNameIndex(6b,a) afbCreateDefColormap 1 0 0 FBIOPUT_VSCREENINFO: Invalid argument Fatal server error: AddScreen/ScreenInit failed for driver 0 The (huge!) log and XF86Config (generated by debconf) are at: http://lyre.mit.edu/~powell/debs/XFree86.0.log http://lyre.mit.edu/~powell/debs/XF86Config-4 Does this much (this little) progress justify including the above patches in the X package? Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: New ARM elfloader patch
Philip Blundell wrote: FBIOPUT_VSCREENINFO: Invalid argument That looks like a good error, in the sense that I don't think it's at all related to the ELF loader. Instead you seem to have some kind of fbcon problem. I think this can happen if you are trying to start up X in a different colour depth to the one you currently have set, or that kind of thing. I think fbset will tell you the current situation. Ah, yes. You're right. If I tell it 8-bit, then it gets past that, and gets signal 4 later, after setting up the mouse. Oh well. Config and log at the same place as last time. But yes, the ELF loader might just be working... :-) Next question: why can't I have 16-bit? fbset -depth 16 gives me the same error. But I have 2 MB VRAM (standard Netwinder), and at 1024x768, 16-bit should use just 1.5 MB, right? I've had 16-bit success with previous 2.4.x kernels, but can't get 2.4.5 to do it. Here's what fbset -i has to say: mode 1024x768-60 # D: 64.998 MHz, H: 48.362 kHz, V: 60.002 Hz geometry 1024 768 1024 768 8 timings 15385 160 24 29 3 136 6 accel true rgba 8/0,8/0,8/0,0/0 endmode Frame buffer device information: Name: CyberPro2000 Address : 0xc000 Size: 2097152 Type: PACKED PIXELS Visual : PSEUDOCOLOR XPanStep: 0 YPanStep: 1 YWrapStep : 0 LineLength : 1024 MMIO Address: 0xc080 MMIO Size : 786432 Accelerator : Unknown (33) Thanks, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: New ARM elfloader patch
[EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Adam C Powell IV writes: Ah, yes. You're right. If I tell it 8-bit, then it gets past that, and gets signal 4 later, after setting up the mouse. Oh well. Config and log at the same place as last time. But yes, the ELF loader might just be working... :-) Signal 4 is illegal instruction, which unfortunately points the finger of blame back at the loader. The log on its own isn't especially illuminating; can you run XFree86 under the debugger and find out what instruction it's tripping up on? Hmm. Must be an intermittent thing. I ran it in the debugger, and it came up just fine! Well, almost, the mouse was not happy, but that's because I was running gpm too. And the ctrl-alt commands didn't seem to work. With gpm turned off, startx ran perfectly! Well, slow as anything because of all the debugging info it's generating (though according to top, it uses 98% of CPU, so it's not a disk issue), it takes 3-4 minutes to start! Okay, out of six attempts, it has signal 4'd twice, one of those with gpm off. I'm afraid I've run out of time to work on this, I guess a few more runs under the debugger would do it. But in the meantime... I can log in via gdm, and run GNOME and Enlightenment, with ripples, and transparent gnome-terminal, and alpha-blended icons, and, and, it's so beautiful! Eight-bit color isn't the greatest, but, well, I'm pretty happy. Once the server is up, it seems pretty stable (okay, so I've just tested it for 30 minutes :-). I've moved the packages to http://lyre.mit.edu/~powell/debs/ for others to help test, and just share and enjoy! I'm short of time for the next couple of weeks, so it will be a while before I can work on this again. Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: New ARM elfloader patch
Okay, I give up. I've tried several times to build this package, and each time it's failed, because of something having nothing to do with the package itself. I got some patches together, and after a couple of early mistakes they've built just fine -- and work with -7 too. But at some point, during unpacking or during dh_makeshlibs or anywhere in between, the following happens: nfs: server not responding, still trying (I don't have enough disk space on my Netwinder to hold the entire build tree.) I can't seem to get out of this, can't unmount the remote directories, can't kill the processes which are keeping it busy, even have trouble rebooting sometimes. If I try to debian/rules build after it fails in the middle, it seems to do a make clean or something similar which removes all of the previously-built libraries and object files. So the previous progress is lost. So, could someone else please take my patches and build and upload X for us? They're at: http://lyre.mit.edu/~powell/debs/311_arm_compiler_h.diff http://lyre.mit.edu/~powell/debs/312_arm_elfloader.diff http://lyre.mit.edu/~powell/debs/350_mips_compiler_h.diff http://lyre.mit.edu/~powell/debs/400_hppa_support.diff Unpack the X source, then put all of these in debian/patches, and remove 310_arm_compiler_h.diff from that directory. It should build, and if all goes well, it may even work! The first two are based on the previous 310_arm_compiler_h.diff and 600 and 600a from debian/held-patches. No rocket science here, I just had to tweak it a bit to use the inx/outx prototypes from libc, specifically sys/io.h. The last two differ from what's there now only in line numbers so their compiler.h hunks are applied without offset. Thanks, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New ARM elfloader patch
Christian T. Steigies wrote: On Tue, Oct 09, 2001 at 04:04:51PM -0400, Adam C Powell IV wrote: So, could someone else please take my patches and build and upload X for us? They're at: http://lyre.mit.edu/~powell/debs/311_arm_compiler_h.diff http://lyre.mit.edu/~powell/debs/312_arm_elfloader.diff http://lyre.mit.edu/~powell/debs/350_mips_compiler_h.diff http://lyre.mit.edu/~powell/debs/400_hppa_support.diff Unpack the X source, then put all of these in debian/patches, and remove 310_arm_compiler_h.diff from that directory. It should build, and if all goes well, it may even work! The first two are based on the previous 310_arm_compiler_h.diff and 600 and 600a from debian/held-patches. No rocket science here, I just had to tweak it a bit to use the inx/outx prototypes from libc, specifically sys/io.h. The last two differ from what's there now only in line numbers so their compiler.h hunks are applied without offset. Do you know if these patches could help makeing the m68k elfloader work? I don't think so, I think there's quite a bit of ARM-specific stuff in there. But you can change some of the #ifdef(__arm__) to use m68k as well, and give it a shot! Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New ARM elfloader patch
Okay, I give up. I've tried several times to build this package, and each time it's failed, because of something having nothing to do with the package itself. I got some patches together, and after a couple of early mistakes they've built just fine -- and work with -7 too. But at some point, during unpacking or during dh_makeshlibs or anywhere in between, the following happens: nfs: server not responding, still trying (I don't have enough disk space on my Netwinder to hold the entire build tree.) I can't seem to get out of this, can't unmount the remote directories, can't kill the processes which are keeping it busy, even have trouble rebooting sometimes. If I try to debian/rules build after it fails in the middle, it seems to do a make clean or something similar which removes all of the previously-built libraries and object files. So the previous progress is lost. So, could someone else please take my patches and build and upload X for us? They're at: http://lyre.mit.edu/~powell/debs/311_arm_compiler_h.diff http://lyre.mit.edu/~powell/debs/312_arm_elfloader.diff http://lyre.mit.edu/~powell/debs/350_mips_compiler_h.diff http://lyre.mit.edu/~powell/debs/400_hppa_support.diff Unpack the X source, then put all of these in debian/patches, and remove 310_arm_compiler_h.diff from that directory. It should build, and if all goes well, it may even work! The first two are based on the previous 310_arm_compiler_h.diff and 600 and 600a from debian/held-patches. No rocket science here, I just had to tweak it a bit to use the inx/outx prototypes from libc, specifically sys/io.h. The last two differ from what's there now only in line numbers so their compiler.h hunks are applied without offset. Thanks, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: New ARM elfloader patch
Christian T. Steigies wrote: On Tue, Oct 09, 2001 at 04:04:51PM -0400, Adam C Powell IV wrote: So, could someone else please take my patches and build and upload X for us? They're at: http://lyre.mit.edu/~powell/debs/311_arm_compiler_h.diff http://lyre.mit.edu/~powell/debs/312_arm_elfloader.diff http://lyre.mit.edu/~powell/debs/350_mips_compiler_h.diff http://lyre.mit.edu/~powell/debs/400_hppa_support.diff Unpack the X source, then put all of these in debian/patches, and remove 310_arm_compiler_h.diff from that directory. It should build, and if all goes well, it may even work! The first two are based on the previous 310_arm_compiler_h.diff and 600 and 600a from debian/held-patches. No rocket science here, I just had to tweak it a bit to use the inx/outx prototypes from libc, specifically sys/io.h. The last two differ from what's there now only in line numbers so their compiler.h hunks are applied without offset. Do you know if these patches could help makeing the m68k elfloader work? I don't think so, I think there's quite a bit of ARM-specific stuff in there. But you can change some of the #ifdef(__arm__) to use m68k as well, and give it a shot! Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: New ARM elfloader patch
[EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Adam C Powell IV writes:
and 600a from debian/held-patches. No rocket science here, I just had
to tweak it a bit to use the inx/outx prototypes from libc, specifically
sys/io.h. The last two differ from what's there now only in line
Whoa, this is dangerous talk. I think X and libc have differing views
on what order the parameters to outx() go in. Extreme caution is
advisable if you are making changes in this area.
Hmm, the 600 patch in debian/held-patches specifically says:
+/* for Linux on ARM, we use the LIBC inx/outx routines */
+/* note that the appropriate setup via ioperm needs to be done */
+/* *before* any inx/outx is done. */
+
+static __inline__ void
+xf_outb(unsigned short port, unsigned char val)
+{
+outb(val, port);
+}
This is basically what I used in my 311 patch. So this inline routine
reorders the parameters.
I can make you an account on one of the armlinux.org machines if you
want somewhere to build this stuff, just let me know.
Cool! I just realized there's one more thing I can try, so I'll do that
and reply offline if it doesn't work.
Thanks much,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe!
http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: What's the status on Xfree86 4.1.0?
Philip Blundell wrote: On Thu, 27 Sep 2001, Adam C Powell IV wrote: So, where do I get this patch? It doesn't come with the 4.1.0-6 source; I presume it's against 4.0.2-*? I thought it was still shipped with 4.1.0 in held-patches. If not, yeah, you can get it from the 4.0.x source. Or in case of complete desperation I can mail you a copy. Oh yeah, there it is. Thanks. -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New ARM elfloader patch
Adam C Powell IV wrote: The new patch is at http://lyre.mit.edu/~powell/debs/311_arm_elfloader.diff D'oh! Forgot about patch application order, put in as number 311 it interferes with other patches (#400 in particular) and causes the build to fail due to patch offsets. So, change of strategy. I merged 310 and the compiler.h part of this and call it 311, which replaces 310. And the elf.h, elfloader.c and xf86sym.c parts I put in 312. New URLs: http://lyre.mit.edu/~powell/debs/311_arm_compiler_h.diff http://lyre.mit.edu/~powell/debs/312_arm_elfloader.diff Also, this caused one offset problem with 400, which I replaced with: http://lyre.mit.edu/~powell/debs/401_hppa_support.diff So at least this unpacks successfully, and is building... The build log-in-progress is at http://lyre.mit.edu/~powell/debs/xfree86_4.1.0-6.log Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What's the status on Xfree86 4.1.0?
Phil Blundell wrote: I was pretty sure that the module loader would be broken. I need an arm hacker to go through the arm-specific patches in debian/held-patches an re-merge them with 4.1.0. Blast, yes, I forgot the module loader. From a quick glance at the code, you want to apply 600_arm_module_loader_and_port_IO.diff. A lot of the elfloader.c hunks will fail but I think they are no longer required. You also need at least the xf86sym.c part of 600a.diff; again one hunk will fail and can be ignored. Okay, I'm getting sufficiently fed up with not having X on the netwinder that I'd like to give this a try. So, where do I get this patch? It doesn't come with the 4.1.0-6 source; I presume it's against 4.0.2-*? Thanks, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
New ARM elfloader patch
Greetings, I have made a new ARM elfloader patch based on held-patches/600 and 600a. So those held patches are obsolete. A thorough reading of held-patch 612_arm_elfloader.diff indicates that too is obsolete. The new patch is at http://lyre.mit.edu/~powell/debs/311_arm_elfloader.diff The build log-in-progress is at http://lyre.mit.edu/~powell/debs/xfree86_4.1.0-6.log Let's see if it works... Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: New ARM elfloader patch
Adam C Powell IV wrote: The new patch is at http://lyre.mit.edu/~powell/debs/311_arm_elfloader.diff D'oh! Forgot about patch application order, put in as number 311 it interferes with other patches (#400 in particular) and causes the build to fail due to patch offsets. So, change of strategy. I merged 310 and the compiler.h part of this and call it 311, which replaces 310. And the elf.h, elfloader.c and xf86sym.c parts I put in 312. New URLs: http://lyre.mit.edu/~powell/debs/311_arm_compiler_h.diff http://lyre.mit.edu/~powell/debs/312_arm_elfloader.diff Also, this caused one offset problem with 400, which I replaced with: http://lyre.mit.edu/~powell/debs/401_hppa_support.diff So at least this unpacks successfully, and is building... The build log-in-progress is at http://lyre.mit.edu/~powell/debs/xfree86_4.1.0-6.log Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: What's the status on Xfree86 4.1.0?
Phil Blundell wrote: I was pretty sure that the module loader would be broken. I need an arm hacker to go through the arm-specific patches in debian/held-patches an re-merge them with 4.1.0. Blast, yes, I forgot the module loader. From a quick glance at the code, you want to apply 600_arm_module_loader_and_port_IO.diff. A lot of the elfloader.c hunks will fail but I think they are no longer required. You also need at least the xf86sym.c part of 600a.diff; again one hunk will fail and can be ignored. Would someone like to try that out and see what happens? Adam, if you still have your build tree around it should be quite easy to apply those patches and rebuild just the affected parts. I'm sorry, I'm pretty swamped for the next three weeks. If I get some time, I'll try it, but can't promise anything. I did notice, however, that -4 seemed to autobuild! Progress! Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What's the status on Xfree86 4.1.0?
Phil Blundell wrote: I was pretty sure that the module loader would be broken. I need an arm hacker to go through the arm-specific patches in debian/held-patches an re-merge them with 4.1.0. Blast, yes, I forgot the module loader. From a quick glance at the code, you want to apply 600_arm_module_loader_and_port_IO.diff. A lot of the elfloader.c hunks will fail but I think they are no longer required. You also need at least the xf86sym.c part of 600a.diff; again one hunk will fail and can be ignored. Would someone like to try that out and see what happens? Adam, if you still have your build tree around it should be quite easy to apply those patches and rebuild just the affected parts. I'm sorry, I'm pretty swamped for the next three weeks. If I get some time, I'll try it, but can't promise anything. I did notice, however, that -4 seemed to autobuild! Progress! Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: What's the status on Xfree86 4.1.0?
Branden Robinson wrote: [debian-arm readers, please keep debian-x in the thread] On Wed, Aug 29, 2001 at 11:46:42AM -0400, Adam C Powell IV wrote: It worked! Failed the manifest check of course, but the diff looked kosher (a few cs - cz and sk key map moves, lots of font stuff, man pages moved from /usr/share/man to /usr/X11R6/man, nothing of any consequence to the binary-arch packages). So I touched debian/stampdir/install (since the manifest check ends that target), and am making binary-arch now, will genchanges and dupload when it's done. Oh- and will test it and see whether it works! But since 4.0.3 is broken, maybe it's not such a bad thing to upload 4.1.0 either way? :-\ Please don't upload official .debs that are the result of a kludged process like this. It makes me really nervous. I'd be happy to host such .debs at the X Strike Force, however, until we have arm packages that build correctly from start to finish. Okay... unfortunately, I didn't get your message in time, but due to interrupted builds from NFS errors (my Netwinder doesn't have sufficient disk space to build X), I ended up just re-starting from zero late last night, copying in the new MANIFEST.arm, and with that one file changed, everything built successfully from start to finish. Just uploaded about three hours ago. Sounds good? Relevant files: http://lyre.mit.edu/~powell/debs/MANIFEST.arm.4.1.0-2 http://lyre.mit.edu/~powell/debs/xfree86_4.1.0-2.build-install.log and coming soon (an hour or two?): http://lyre.mit.edu/~powell/debs/xfree86_4.1.0-2.binary-arch.log Thanks! I'll check this stuff out. Okay, actually, the new unified build-install-binary log is at: http://lyre.mit.edu/~powell/debs/xfree86_4.1.0-2.log Unfortunately, it didn't work. Log at: http://lyre.mit.edu/~powell/debs/XFree86.0.log Oh well, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: What's the status on Xfree86 4.1.0?
Adam C Powell IV wrote: I'm afraid I don't have too much time to try it under multiple kernels, so someone else will have to investigate. If 2.4.5 makes X build (won't know until tomorrow morning), I'll report that. It worked! Failed the manifest check of course, but the diff looked kosher (a few cs - cz and sk key map moves, lots of font stuff, man pages moved from /usr/share/man to /usr/X11R6/man, nothing of any consequence to the binary-arch packages). So I touched debian/stampdir/install (since the manifest check ends that target), and am making binary-arch now, will genchanges and dupload when it's done. Oh- and will test it and see whether it works! But since 4.0.3 is broken, maybe it's not such a bad thing to upload 4.1.0 either way? :-\ So, ARM fails to build X under 2.2.19 because of fakeroot trouble, but 2.4.5 is fine. Someone may want to investigate why fakeroot fails under 2.2.19, it seemed to work just fine for 2.2.13 but I didn't try to build X... Relevant files: http://lyre.mit.edu/~powell/debs/MANIFEST.arm.4.1.0-2 http://lyre.mit.edu/~powell/debs/xfree86_4.1.0-2.build-install.log and coming soon (an hour or two?): http://lyre.mit.edu/~powell/debs/xfree86_4.1.0-2.binary-arch.log Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: XFree86 4.1.0-0pre1v5 now available; 4.1.0-1 imminent
Adam C Powell IV wrote: It's building now with the patch put in as debian/patches/999_z_arm_pci.diff (you'll probably give it a different number, or merge it with another patch?), log-in-progress at http://lyre.mit.edu/~powell/debs/xfree86_4.1.0-0pre1v5b.log . Nope, failed again, different error (MANIFEST check failed). I'm afraid I've run out of time to debug, but if someone sends a patch I'd be glad to start another build. Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.1.0-0pre1v5 now available; 4.1.0-1 imminent
Philip Blundell wrote: Nope, failed again, different error (MANIFEST check failed). I'm afraid I've run out of time to debug, but if someone sends a patch I'd be glad to start another build. MANIFEST checks don't usually need much debugging. You just need to look over the diff to make sure that it all seems reasonable (ie that the X server hasn't been removed or anything) and then update the file to reflect the actual situation on the ground. Right, I'm afraid I don't even have time to do that. :-( I leave town tomorrow early morning, then am back for next Monday and Tuesday, then away for two weeks... lots of rushing around. If someone sends a patch, I'll start it going again, but can't do more until around August 7 or 8. Sorry, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.1.0-0pre1v5 now available; 4.1.0-1 imminent
Adam C Powell IV wrote: It's building now with the patch put in as debian/patches/999_z_arm_pci.diff (you'll probably give it a different number, or merge it with another patch?), log-in-progress at http://lyre.mit.edu/~powell/debs/xfree86_4.1.0-0pre1v5b.log . Nope, failed again, different error (MANIFEST check failed). I'm afraid I've run out of time to debug, but if someone sends a patch I'd be glad to start another build. Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: XFree86 4.1.0-0pre1v5 now available; 4.1.0-1 imminent
Philip Blundell wrote: Nope, failed again, different error (MANIFEST check failed). I'm afraid I've run out of time to debug, but if someone sends a patch I'd be glad to start another build. MANIFEST checks don't usually need much debugging. You just need to look over the diff to make sure that it all seems reasonable (ie that the X server hasn't been removed or anything) and then update the file to reflect the actual situation on the ground. Right, I'm afraid I don't even have time to do that. :-( I leave town tomorrow early morning, then am back for next Monday and Tuesday, then away for two weeks... lots of rushing around. If someone sends a patch, I'll start it going again, but can't do more until around August 7 or 8. Sorry, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: XFree86 4.1.0-0pre1v5 now available; 4.1.0-1 imminent
Adam C Powell IV wrote: Branden Robinson wrote: The latest prerelease of 4.1.0 .debs is now available at the X Strike Force repository (see the URL in my .sig). Great! I tried to build -0pre1v4 on ARM, but it failed; build log at http://lyre.mit.edu/~powell/debs/xfree86_4.1.0-0pre1v4.log . I'll try -0pre1v5, but it'll take a few hours. :-) That failed too, same error. Okay, isolated the problem. One-line patch attached for the relevant Imakefile. Are there any other PCI-based arches (HPPA)? If so, you'll need lines for those as well... It's building now with the patch put in as debian/patches/999_z_arm_pci.diff (you'll probably give it a different number, or merge it with another patch?), log-in-progress at http://lyre.mit.edu/~powell/debs/xfree86_4.1.0-0pre1v5b.log . I hope this works, we haven't had a working X server since 4.0.2! Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg --- xc/programs/Xserver/hw/xfree86/os-support/bus/Imakefile~Wed Jul 18 09:39:34 2001 +++ xc/programs/Xserver/hw/xfree86/os-support/bus/Imakefile Wed Jul 18 09:44:43 +2001 @@ -36,6 +36,7 @@ (defined(PpcArchitecture) || \ defined(MipsArchitecture) || \ defined(ia64Architecture) || \ + defined(Arm32Architecture) || \ defined(Mc68020Architecture)) XCOMM generic linux PCI driver (using /proc/bus/pci, requires kernel 2.2)
Re: XFree86 4.1.0-0pre1v5 now available; 4.1.0-1 imminent
Adam C Powell IV wrote: Branden Robinson wrote: The latest prerelease of 4.1.0 .debs is now available at the X Strike Force repository (see the URL in my .sig). Great! I tried to build -0pre1v4 on ARM, but it failed; build log at http://lyre.mit.edu/~powell/debs/xfree86_4.1.0-0pre1v4.log . I'll try -0pre1v5, but it'll take a few hours. :-) That failed too, same error. Okay, isolated the problem. One-line patch attached for the relevant Imakefile. Are there any other PCI-based arches (HPPA)? If so, you'll need lines for those as well... It's building now with the patch put in as debian/patches/999_z_arm_pci.diff (you'll probably give it a different number, or merge it with another patch?), log-in-progress at http://lyre.mit.edu/~powell/debs/xfree86_4.1.0-0pre1v5b.log . I hope this works, we haven't had a working X server since 4.0.2! Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg --- xc/programs/Xserver/hw/xfree86/os-support/bus/Imakefile~Wed Jul 18 09:39:34 2001 +++ xc/programs/Xserver/hw/xfree86/os-support/bus/Imakefile Wed Jul 18 09:44:43 2001 @@ -36,6 +36,7 @@ (defined(PpcArchitecture) || \ defined(MipsArchitecture) || \ defined(ia64Architecture) || \ + defined(Arm32Architecture) || \ defined(Mc68020Architecture)) XCOMM generic linux PCI driver (using /proc/bus/pci, requires kernel 2.2)
Re: XFree86 4.1.0-0pre1v5 now available; 4.1.0-1 imminent
Philip Blundell wrote: defined(ia64Architecture) || \ + defined(Arm32Architecture) || \ defined(Mc68020Architecture)) Huh, I thought it was just ArmArchitecture. But if it works for you... grep Arm `find xfree86-4.1.0/build-tree/xc/ -name Imakefile -print` turns up only Arm32Architecture, likewise for \*.tmpl. I can't find anything with ArmArchitecture... May be a 4.1 thing? Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: XFree86 4.1.0-0pre1v5 now available; 4.1.0-1 imminent
Branden Robinson wrote: The latest prerelease of 4.1.0 .debs is now available at the X Strike Force repository (see the URL in my .sig). Great! I tried to build -0pre1v4 on ARM, but it failed; build log at http://lyre.mit.edu/~powell/debs/xfree86_4.1.0-0pre1v4.log . I'll try -0pre1v5, but it'll take a few hours. :-) I plan to release 4.1.0-1 as soon as XFree86 upstream has resolved the issue with missing PIC symbols in unshared objects on some architectures, or once we have a workaround that doesn't break other things (like the X server's module loader, which cannot handle PIC information). Cool. Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
xserver-xfree86 configuration on ARM
Hello, The simple attached patch vs. 4.0.2-11 forces us to use fbdev, but seems to generate a viable XF68Config-4. Is there some reason we don't have something like this yet (aside from the broken module loader)? ARM people, what other drivers are necessary or eventually hoped to work? Just wondering, -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! --- xfree86-4.0.2/debian/xserver-xfree86.config.bak Mon Mar 26 14:32:03 2001 +++ xfree86-4.0.2/debian/xserver-xfree86.config Mon Mar 26 14:40:19 2001 @@ -218,6 +218,9 @@ # ati driver is currently broken on SPARC, add it back in when it's fixed DRIVER_LIST="fbdev, glint, sunbw2, suncg14, suncg3, suncg6, sunffb, sunleo, suntcx" ;; + arm) +DRIVER_LIST="fbdev" +;; *) exit 0 ;;
xserver-xfree86 configuration on ARM
Hello, The simple attached patch vs. 4.0.2-11 forces us to use fbdev, but seems to generate a viable XF68Config-4. Is there some reason we don't have something like this yet (aside from the broken module loader)? ARM people, what other drivers are necessary or eventually hoped to work? Just wondering, -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! --- xfree86-4.0.2/debian/xserver-xfree86.config.bak Mon Mar 26 14:32:03 2001 +++ xfree86-4.0.2/debian/xserver-xfree86.config Mon Mar 26 14:40:19 2001 @@ -218,6 +218,9 @@ # ati driver is currently broken on SPARC, add it back in when it's fixed DRIVER_LIST=fbdev, glint, sunbw2, suncg14, suncg3, suncg6, sunffb, sunleo, suntcx ;; + arm) +DRIVER_LIST=fbdev +;; *) exit 0 ;;
