Bug#874531: mesa: FTBFS on armel: __atomic_fetch_add_8 undefined
Source: mesa Version: 17.2.0-2 Severity: serious Tags: upstream Justification: fails to build from source (but built successfully in the past) Builds of mesa for armel have been failing lately: glsl/.libs/libstandalone.a(libmesautil_la-disk_cache.o): In function `disk_cache_remove': ./build/src/util/../../../src/util/disk_cache.c:643: undefined reference to `__atomic_fetch_add_8' collect2: error: ld returned 1 exit status Makefile:2110: recipe for target 'glsl_compiler' failed make[5]: *** [glsl_compiler] Error 1 make[5]: Leaving directory '/<>/build/src/compiler' Please link glsl_compiler (and anything else that uses libstandalone) against -latomic. If you don't want that dependency on architectures that don't need it, you can either conditionalize on architecture or precede -latomic with -Wl,--as-needed (and follow it with -Wl,--no-as-needed if desired). Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#873463: xserver-xorg-video-openchrome: FTBFS on hurd-i386: iopl undefined
Source: xserver-xorg-video-openchrome Version: 1:0.6.0-2 Severity: important Justification: fails to build from source (but built successfully in the past) The latest hurd-i386 build of xserver-xorg-video-openchrome failed: registers.o: In function `main': ./build/tools/../../tools/registers.c:1149: undefined reference to `iopl' collect2: error: ld returned 1 exit status Makefile:409: recipe for target 'via_regs_dump' failed Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#870445: libglvnd: FTBFS on non-Linux: u_execmem_free undefined
Source: libglvnd Version: 0.2.999+git20170201-4 Severity: important Tags: upstream Justification: fails to build from source Builds of libglvnd for kFreeBSD and the Hurd (admittedly not release architectures) have been failing: ./build/src/GLdispatch/vnd-glapi/../../../../src/GLdispatch/vnd-glapi/stub.c:110: undefined reference to `u_execmem_free' Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#870444: libglvnd: FTBFS on arm64: no _glapi_tls_Current@Base
Source: libglvnd Version: 0.2.999+git20170201-4 Severity: important Tags: upstream Justification: fails to build from source The arm64 build of libglvnd failed: dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libglvnd0/DEBIAN/symbols doesn't match completely debian/libglvnd0.symbols --- debian/libglvnd0.symbols (libglvnd0_0.2.999+git20170201-4_arm64) +++ dpkg-gensymbols4xEoPS 2017-08-01 17:19:46.984994738 + @@ -16,4 +16,4 @@ __glDispatchUnregisterStubCallbacks@Base 0 _glapi_Current@Base 0 _glapi_get_current@Base 0 - _glapi_tls_Current@Base 0 +#MISSING: 0.2.999+git20170201-4# _glapi_tls_Current@Base 0 Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#837034: libdrm: FTBFS on kfreebsd-*: drm.h: bad #include choices
Andreas Boll <andreas.boll@gmail.com> writes: > Please ignore Hurd in this bug report since it hasn't successfully > built in the past and won't be useful at all without adding the > equivalent of the Linux Direct Rendering Manager (DRM) subsystem to > the Hurd. I'm going to remove Hurd from the architecture list of > libdrm in the next upload. That's fair; I rather suspected deeper issues there. ;-) > For the kFreeBSD FTBFS I've done a quick investigation and found out > that those includes in drm.h haven't changed since 2009. All the same, it's best practice for headers to #include anything they need, to keep things simple for their reverse dependencies. FWIW, I noticed this problem when looking into a libcmrt FTBFS on kFreeBSD: libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../src -D_DEBUG -DPTHREADS -I/usr/include/libdrm -I/src/cmrt -DSYSCONFDIR=\"/etc\" -Wdate-time -D_FORTIFY_SOURCE=2 -fpermissive -g -O2 -Wall -Wno-missing-braces -fvisibility=default -DLINUX -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -msse4 -fPIC -g -O2 -fdebug-prefix-map=/«BUILDDIR»/libcmrt-1.0.5+git20160516.dfsg1=. -fstack-protector-strong -Wformat -Werror=format-security -c ../../src/cm_buffer.cpp -fPIC -DPIC -o .libs/libcmrt_la-cm_buffer.o In file included from /usr/include/libdrm/i915_drm.h:30:0, from ../../src/cm_device.h:32, from ../../src/cm_device.cpp:31: /usr/include/libdrm/drm.h:50:9: error: 'uint8_t' does not name a type Thanks for the quick response! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#837034: libdrm: FTBFS on non-Linux: drm.h: bad #include choices
Source: libdrm Version: 2.4.70-1 Severity: important Justification: fails to build from source (but built successfully in the past) Builds of libdrm on kFreeBSD and the Hurd have been failing because the headers drm.h pulls in on those platforms don't work out. Specifically, kFreeBSD builds have been failing with In file included from ../../../include/drm/drm_fourcc.h:27:0, from ../../../tests/kms/libkms-test-framebuffer.c:33: ../../../include/drm/drm.h:50:9: error: unknown type name 'uint8_t' typedef uint8_t __u8; ^ ../../../include/drm/drm.h:52:9: error: unknown type name 'uint16_t' typedef uint16_t __u16; ^ ../../../include/drm/drm.h:54:9: error: unknown type name 'uint32_t' typedef uint32_t __u32; ^ ../../../include/drm/drm.h:56:9: error: unknown type name 'uint64_t' typedef uint64_t __u64; ^ and Hurd builds have been failing with In file included from ../xf86drm.h:40:0, from ../xf86drm.c:70: ../include/drm/drm.h:47:24: fatal error: sys/ioccom.h: No such file or directory To remedy these errors, I would recommend replacing with (which is more broadly available, and pulls in on both kFreeBSD/GNU and pure *BSD), and supplementing with . ( should stay for size_t.) Could you please take a look? Thanks!
Bug#609145: Fwd: triggering bug under kernel 2.6.35
Forwarding to what appears to have been the intended bug number. ---BeginMessage--- I was also able to trigger the bug under kernel 2.6.35 getting the following in dmesg: [ 211.274392] [TTM] Buffer eviction failed [ 211.699964] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -22! ---End Message---
Bug#574396: please set enable-meta-key (_rl_enable_meta) sanely
retitle 574396 please set enable-meta-key (_rl_enable_meta) sanely reassign 574396 bash 4.1-2 clone 574396 -1 reassign -1 libreadline6 6.1-1 thanks [Summary for newly added recipients: after a recent round of upgrades, I found that typing meta-key combinations into xterm with bash as my shell resulted in non-ASCII characters rather than the expected escape sequences. Further analysis revealed that the trigger was an update to xterm's terminfo entry (from ncurses-base), which added definitions of smm and rmm despite the comment in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=444250#40 .] Thomas Dickey dic...@his.com writes: That's already been discussed in SuSE - it's an issue with bash. It should allow the decision whether to enable meta mode to be configurable. bash's maintainer hasn't been cooperative. As of bash 4.1 (and the corresponding readline 6.1 release), there is now an enable-meta-key readline variable that has the desired effect. Bash and readline have logic (_rl_init_eightbit) to set related variables (convert-meta, input-meta, and output-meta) sanely in eight-bit locales, but always leave enable-meta-key on by default; could you please patch _rl_init_eightbit to set _rl_enable_meta = 0 in eight-bit mode? Thanks! http://invisible-island.net/xterm/xterm.log.html#xterm_21 ITYM http://invisible-island.net/xterm/xterm.log.html#xterm_216 . -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/udlaau5cuta.fsf...@dr-wily.mit.edu
Bug#574396: xterm: meta no longer sends escape even with eightBitInput: false
Package: xterm Version: 256-1 Severity: normal My X resources set XTerm*eightBitInput: false, because (as noted in #326200 and #534192) that's generally a saner choice nowadays. However, a recent upgrade (presumably to xterm itself) broke that; alt-key combinations now yield non-ASCII characters rather than the expected escape sequences, which I have to remind myself to type explicitly. :-/ -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xterm depends on: ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii libfontconfig12.8.0-2generic font configuration library ii libice6 2:1.0.6-1 X11 Inter-Client Exchange library ii libncurses5 5.7+20100313-1 shared libraries for terminal hand ii libutempter0 1.1.5-2A privileged helper for utmp/wtmp ii libx11-6 2:1.3.3-2 X11 client-side library ii libxaw7 2:1.0.7-1 X11 Athena Widget library ii libxft2 2.1.14-2 FreeType-based font drawing librar ii libxmu6 2:1.0.5-1 X11 miscellaneous utility library ii libxt61:1.0.7-1 X11 toolkit intrinsics library ii xbitmaps 1.1.0-1Base X bitmaps Versions of packages xterm recommends: ii x11-utils 7.5+3 X11 utilities ii xutils1:7.5+5X Window System utility programs m Versions of packages xterm suggests: ii xfonts-cyrillic 1:1.0.1Cyrillic fonts for X -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100317220901.25336.37474.report...@tux64.internal.ucko.debian.net
Bug#574396: #574396 xterm: meta no longer sends escape even with eightBitInput: false
Thomas Dickey dic...@his.com writes: The feature seems to work here (compiled myself...). I'd assume it's a resource setting; the output of appres XTerm might show it. Thanks for the quick response! I wondered about that too, but didn't notice anything suspicious in the (attached) output. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu *SimpleMenu*menuLabel.font: -adobe-helvetica-bold-r-normal--*-120-*-*-*-*-iso8859-* *SimpleMenu*menuLabel.vertSpace:100 *SimpleMenu*Sme.height: 16 *SimpleMenu*background: AntiqueWhite *SimpleMenu*borderWidth:2 *SimpleMenu*Cursor: left_ptr *SimpleMenu*BackingStore: NotUseful *SimpleMenu*foreground: gray15 *SimpleMenu*HorizontalMargins: 16 *fontMenu*font-packed*Label:Packed Font *fontMenu*font4*Label: Medium *fontMenu*allow-window-ops*Label: Allow Window Ops *fontMenu*render-font*Label:TrueType Fonts *fontMenu*font5*Label: Large *fontMenu*utf8-mode*Label: UTF-8 *fontMenu*font6*Label: Huge *fontMenu*utf8-title*Label: UTF-8 Titles *fontMenu*fontdefault*Label:Default *fontMenu*fontescape*Label: Escape Sequence *fontMenu*allow-color-ops*Label:Allow Color Ops *fontMenu*font1*Label: Unreadable *fontMenu*fontsel*Label:Selection *fontMenu*font-linedrawing*Label: Line-Drawing Characters *fontMenu*allow-font-ops*Label: Allow Font Ops *fontMenu*font-doublesize*Label:Doublesized Characters *fontMenu*font2*Label: Tiny *fontMenu*allow-tcap-ops*Label: Allow Termcap Ops *fontMenu*font-loadable*Label: VT220 Soft Fonts *fontMenu*font3*Label: Small *fontMenu*allow-title-ops*Label:Allow Title Ops *fontMenu.Label:VT Fonts *fontMenu*background: AntiqueWhite *fontMenu*foreground: gray15 *XmText*translations: #override KeyBackSpace: delete-previous-character() \n\ KeyDelete: delete-next-character() \n\ KeyosfBackSpace: delete-previous-character() \n\ KeyosfDelete: delete-next-character() *XmTextField*translations: #override KeyBackSpace: delete-previous-character() \n\ KeyDelete: delete-next-character() \n\ KeyosfBackSpace: delete-previous-character() \n\ KeyosfDelete: delete-next-character() *XmtInputField*translations:#override KeyBackSpace: delete-previous-character() \n\ KeyDelete: delete-next-character() \n\ KeyosfBackSpace: delete-previous-character() \n\ KeyosfDelete: delete-next-character() *tek4014*fontLarge: 9x15 *tek4014*font2: 8x13 *tek4014*font3: 6x13 *tek4014*fontSmall: 6x10 *vtMenu*scrollttyoutput*Label: Scroll to Bottom on Tty Output *vtMenu*jumpscroll*Label: Enable Jump Scroll *vtMenu*cursorblink*Label: Enable Blinking Cursor *vtMenu*vthide*Label: Hide VT Window *vtMenu*allow132*Label: Allow 80/132 Column Switching *vtMenu*reversevideo*Label: Enable Reverse Video *vtMenu*titeInhibit*Label: Enable Alternate Screen Switching *vtMenu*altscreen*Label:Show Alternate Screen *vtMenu*keepSelection*Label:Keep Selection *vtMenu*autowrap*Label: Enable Auto Wraparound *vtMenu*activeicon*Label: Enable Active Icon *vtMenu*selectToClipboard*Label:Select to Clipboard *vtMenu*reversewrap*Label: Enable Reverse Wraparound *vtMenu*softreset*Label:Do Soft Reset *vtMenu*cursesemul*Label: Enable Curses Emulation *vtMenu*autolinefeed*Label: Enable Auto Linefeed *vtMenu*hardreset*Label:Do Full Reset *vtMenu*visualbell*Label: Enable Visual Bell *vtMenu*appcursor*Label:Enable Application Cursor Keys *vtMenu*clearsavedlines*Label: Reset and Clear Saved Lines *vtMenu*bellIsUrgent*Label: Enable Bell Urgency *vtMenu*appkeypad*Label:Enable Application Keypad *vtMenu*tekshow*Label: Show Tek Window *vtMenu*poponbell*Label:Enable Pop on Bell *vtMenu*scrollbar*Label:Enable Scrollbar *vtMenu*scrollkey*Label:Scroll to Bottom on Key Press *vtMenu*tekmode*Label: Switch to Tek Mode *vtMenu.Label: VT Options *vtMenu*background: AntiqueWhite *vtMenu*foreground: gray15 *mainMenu*delete-is-del*Label: Delete is DEL *mainMenu*print-redir*Label:Redirect to Printer *mainMenu*continue*Label: Send CONT Signal *mainMenu*oldFunctionKeys*Label:Old Function-Keys *mainMenu*interrupt*Label: Send INT Signal *mainMenu*sunFunctionKeys*Label:Sun Function-Keys *mainMenu*toolbar*Label:Toolbar *mainMenu*8-bit control*Label: 8-Bit Controls *mainMenu*hangup*Label: Send HUP Signal *mainMenu*sunKeyboard*Label:VT220 Keyboard *mainMenu*securekbd*Label: Secure Keyboard *mainMenu*terminate*Label: Send TERM Signal *mainMenu*hpFunctionKeys*Label: HP Function-Keys *mainMenu*allowsends*Label: Allow SendEvents *mainMenu*backarrow key*Label: Backarrow Key (BS/DEL) *mainMenu*kill*Label: Send KILL Signal *mainMenu*num-lock*Label: Alt/NumLock Modifiers *mainMenu*redraw*Label: Redraw Window *mainMenu
Bug#574396: #574396 xterm: meta no longer sends escape even with eightBitInput: false
Thomas Dickey dic...@his.com writes: But in the past couple of weeks, I've been installing a new machine, and noticed -on a couple of other Linux's- that there's some breakage in luit which may be related (if you didn't happen to have the Latin-1 locale installed, for instance). I use a UTF-8 locale, so luit isn't involved. Further investigation revealed that the relevant upgrade was not of xterm (from version 255, FTR) but of ncurses-base; the addition of rmm and smm settings to xterm's terminfo entry somehow caused xterm to ignore the eightBitInput resource. (There are some other differences as well, mostly in k* settings, but those look most likely to be the culprit.) I'm leaving this bug assigned to xterm anyway, both because I'm not convinced that that change should have had such an effect and because ncurses gets its xterm terminfo definition from xterm's sources. (The latest update claims to have taken xterm-246's definition.) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/udliq8uwa19@dr-wily.mit.edu
Bug#574396: #574396 xterm: meta no longer sends escape even with eightBitInput: false
u...@debian.org (Aaron M. Ucko) writes: FTR) but of ncurses-base; the addition of rmm and smm settings to It belatedly occurred to me that the issue is likelier indirect, with bash for some reason picking up on that and forcing xterm into the wrong mode. :-/ I don't have time to investigate further tonight, though. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/udlociml05o@dr-wily.mit.edu
Bug#538094: mesa-utils: dominated by redundant changelog.gz
Package: mesa-utils Version: 7.5-2 Severity: minor In general, I'm all for shipping upstream changelogs, as their contents are often of interest. However, in the case of mesa-utils, doing so increased the package's installed footprint by approximately a factor of 15(!). Moreover, it already depends on libgl1-mesa-glx | libgl1, where the only alternative is libgl1-mesa-swx11; either option already contains an identical changelog.gz. (AFAICT, the non-free fglrx-glx and nvidia-glx drivers don't themselves provide libgl1, so they're not a consideration here.) In fact, most of the sixteen binary packages mesa builds depend on other mesa packages; the only exceptions appear to be libgl1-mesa-dri, libgl1-mesa-glx, libosmesa6, and mesa-common-dev, so I'd generally suggest leaving extra copies of changelog.gz out of the remainder. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mesa-utils depends on: ii libc6 2.9-21 GNU C Library: Shared libraries ii libgl1-mesa-glx [libgl1] 7.5-2 A free implementation of the OpenG ii libx11-6 2:1.2.2-1 X11 client-side library mesa-utils recommends no packages. mesa-utils suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535952: xprint: Xprt can't find symbol PrinterFontRegisterFpeFunctions and fails to start
Julien Cristau jcris...@debian.org writes: xprint support was removed from libXfont. We should add a Breaks: xprint to the libxfont1 package, as it doesn't look like xprint will be coming back. Strictly speaking, shouldn't that have called for an soname bump? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534890: xserver-xorg-core: Graphics output garbled after update from 2:1.6.1.901-2
Jakob Haufe su...@sur5r.net writes: I first had it using e17, but it's even garbled with plain twm. Every window is unusable. What's strange to me is, that the xdm login screen displays perfectly ok. xdm's greeter uses Xft nowadays, so that sounds like the same problem with core fonts I reported as http://bugs.debian.org/534766 . -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534766: xserver-xorg-core: font corruption, dri2 no longer working
Brice Goglin brice.gog...@ens-lyon.org writes: This looks strange to me. Are you sure you rebuilt properly? Yes. Can you try my rebuild of the intel driver available at http://people.debian.org/~bgoglin/rebuilds/Xserver1.6-ABIbreak/intel/ ? 2.7.1-2 exhibited the same font corruption (which incidentally affects other character-cell fonts; nothing in xterm's menu came out legible), and presumably also the same failure to enable DRI2 (though I forgot to check and no longer have the log around, sorry). :-/ I normally stay clear of experimental packages, but I gave 2.7.99.901-3 a try, with good results; fonts are back to normal, and DRI2 is working. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534766: xserver-xorg-core: font corruption, dri2 no longer working
u...@debian.org (Aaron M. Ucko) writes: I normally stay clear of experimental packages, but I gave 2.7.99.901-3 a try, with good results; fonts are back to normal, and DRI2 is working. Well, according to the logs, anyway; in practice, I found OpenGL apps to produce garbage and had to revert to -core 2:1.6.1.901-2 + -video-intel 2:2.7.1-1 to get a fully working setup. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534766: xserver-xorg-core: font corruption, dri2 no longer working
u...@debian.org (Aaron M. Ucko) writes: Well, according to the logs, anyway; in practice, I found OpenGL apps to produce garbage and had to revert to -core 2:1.6.1.901-2 + -video-intel 2:2.7.1-1 to get a fully working setup. Sorry to keep following up to myself, but I noticed that my attempts to use OpenGL with the experimental -video-intel resulted in a few thousand kernel messages reading [drm:i915_gem_execbuffer] *ERROR* Object 880033576240 appears more than once in object list (always with that specific object ID [address?]) in addition to display corruption. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534766: xserver-xorg-core: font corruption, dri2 no longer working
Package: xserver-xorg-core Version: 2:1.6.1.901-3 Severity: important I have observed two regressions since upgrading to 2:1.6.1.901-3, despite having taken care to rebuild xserver-xorg-video-intel against current versions of xserver-xorg-dev and x11proto-dri2. (As such, I believe this report to be distinct from #534475.) - As a traditionalist, I make heavy use of the fixed font, which started showing up as unreadable horizontal stripes rather than proper characters. I'm not sure if other fonts were also affected, as I quickly reverted to -2 and the corresponding (unrebuilt) -video-intel. (I have tried to ensure that the data dump below corresponds to my brief run of -3, though.) - While comparing logs of -2 vs. -3 (diff included below), with everything else held the same, I observed that only -2 was able to make use of DRI2. That's not such a big deal to me, as pretty much the only GL apps I run are xscreensaver hacks ;-), but seems worth noting as well. --- /var/log/Xorg.0.log-2 2009-06-26 20:39:12.0 -0400 +++ /var/log/Xorg.0.log-3 2009-06-26 20:32:29.0 -0400 @@ -10,16 +10,16 @@ X.Org X Server 1.6.1.901 (1.6.2 RC 1) Release Date: 2009-5-8 X Protocol Version 11, Revision 0 -Build Operating System: Linux 2.6.26-1-vserver-amd64 x86_64 Debian +Build Operating System: Linux 2.6.30-dsa-amd64 x86_64 Debian Current Operating System: Linux tux64 2.6.30-1-amd64 #1 SMP Sun Jun 14 15:00:29 UTC 2009 x86_64 -Build Date: 14 May 2009 04:42:17PM -xorg-server 2:1.6.1.901-2 (bui...@excelsior.roeckx.be) +Build Date: 23 June 2009 06:28:59PM +xorg-server 2:1.6.1.901-3 (buildd@) Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. -(==) Log file: /var/log/Xorg.0.log, Time: Fri Jun 26 20:38:32 2009 +(==) Log file: /var/log/Xorg.0.log, Time: Fri Jun 26 20:30:35 2009 (==) Using config file: /etc/X11/xorg.conf (==) No Layout section. Using the first Screen section. (**) |--Screen Default Screen (0) @@ -44,7 +44,7 @@ (II) Cannot locate a core keyboard device. (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AllowEmptyInput. -(II) Loader magic: 0x7540 +(II) Loader magic: 0x3b40 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 @@ -55,7 +55,7 @@ (WW) xf86OpenConsole: setpgid failed: Operation not permitted (WW) xf86OpenConsole: setsid failed: Operation not permitted -(--) PCI:*(0...@0:2:0) Intel Corporation 82Q35 Express Integrated Graphics Controller rev 2, Mem @ 0xfe98/524288, 0xd000/268435456, 0xfe80/1048576, I/O @ 0xdc00/8 +(--) PCI:*(0:0:2:0) 8086:29b2:1043:8276 Intel Corporation 82Q35 Express Integrated Graphics Controller rev 2, Mem @ 0xfe98/524288, 0xd000/268435456, 0xfe80/1048576, I/O @ 0xdc00/8 (II) Open ACPI successful (/var/run/acpid.socket) (II) System resource ranges: [0] -1 0 0x - 0x (0x1) MX[B] @@ -108,7 +108,7 @@ (II) LoadModule: dri2 (II) Loading /usr/lib/xorg/modules/extensions//libdri2.so (II) Module dri2: vendor=X.Org Foundation - compiled for 1.6.1.901, module version = 1.0.0 + compiled for 1.6.1.901, module version = 1.1.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (==) Matched intel for the autoconfigured driver @@ -116,7 +116,7 @@ (II) LoadModule: intel (II) Loading /usr/lib/xorg/modules/drivers//intel_drv.so (II) Module intel: vendor=X.Org Foundation - compiled for 1.6.1, module version = 2.7.1 + compiled for 1.6.1.901, module version = 2.7.1 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 (II) intel: Driver for Intel Integrated Graphics Chipsets: i810, @@ -332,7 +332,6 @@ [8] -1 0 0x - 0x (0x1) IX[B] [9] 0 0 0x03b0 - 0x03bb (0xc) IS[B] [10] 0 0 0x03c0 - 0x03df (0x20) IS[B] -(II) intel(0): [DRI2] Setup complete (**) intel(0): Framebuffer compression disabled (**) intel(0): Tiling enabled (==) intel(0): VideoRam: -1 KB @@ -345,19 +344,12 @@ (==) intel(0): Backing store disabled (==) intel(0): Silken mouse enabled (II) intel(0): Initializing HW Cursor -(II) intel(0): Fixed memory allocation layout: -(II) intel(0): 0x-0x: DRI memory manager (0 kB) -(II) intel(0): 0x:end of aperture -(II) intel(0): BO memory allocation layout: -(II) intel(0): 0x:start of memory manager -(II) intel(0): 0x0100-0x017f: front buffer (8192 kB) X tiled -(II) intel(0): 0x00d0-0x00d09fff: HW cursors (40 kB) -(II) intel(0): 0x:
Bug#520405: xterm: bell no longer sounds
Julien Cristau jcris...@debian.org writes: Yeah, but the check for XkbBell includes X11/extensions/XKBbells.h which is in libxkbfile-dev. That said, it looks like this check failed in previous versions too, so if 241-1 worked then that's probably not it. Apologies for taking so long to respond; I've been pretty busy in real life. At any rate, I can confirm that Thomas's patch is the way to go; 242-1 is silent whether built with or without libxkbfile-dev installed, but applying the patch lets it beep again. Could you please incorporate it when you get a chance? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520405: xterm: bell no longer sounds
Julien Cristau jcris...@debian.org writes: Can you rebuild xterm with libxkbfile-dev installed I've done so, but I won't be able to see if that makes a difference until I get home. I don't think that's it, though -- AFAICT, XkbBell is in libX11, and my rebuilt xterm doesn't depend on libxkbfile. Rather, I'm sheepishly starting to suspect a configuration error on my side; it seems that one key difference between XkbBell and plain old XBell is that applications can globally hook the former and redirect its output elsewhere, such as to the headphones I generally only wear when I'm actually playing some form of media. (The system on which I observed the problem is a desktop with a dedicated speaker for system beeps.) I'll follow up once I'm actually back in front of the system in question. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520405: xterm: bell no longer sounds
Package: xterm Version: 242-1 Severity: normal Sending ^G to xterm 242 with visual-bell mode off (as it is by default) has no effect. The visual bell still works fine, as do auditory bells from other applications. xterm 241 had no such problem. I don't have time to debug the issue at the moment, but I observe that xterm 242's top changelog entry mentions reworking the relevant logic, in the course of which a bug presumably slipped in: lifix configure check for codeXkbBell/code and provide appropriate parameter for it. Could somebody please take a look? Thanks! -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xterm depends on: ii libc6 2.9-6 GNU C Library: Shared libraries ii libfontconfig12.6.0-3generic font configuration library ii libice6 2:1.0.5-1 X11 Inter-Client Exchange library ii libncurses5 5.7+20090228-1 shared libraries for terminal hand ii libx11-6 2:1.2-1X11 client-side library ii libxaw7 2:1.0.5-2 X11 Athena Widget library ii libxft2 2.1.13-3 FreeType-based font drawing librar ii libxmu6 2:1.0.4-1 X11 miscellaneous utility library ii libxt61:1.0.5-3 X11 toolkit intrinsics library ii xbitmaps 1.0.1-2Base X bitmaps Versions of packages xterm recommends: ii x11-utils 7.4+1 X11 utilities ii xutils1:7.3+18 X Window System utility programs m Versions of packages xterm suggests: ii xfonts-cyrillic 1:1.0.0-6 Cyrillic fonts for X -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: getting X resolution from ~/.xsession?
Louis-David Mitterrand vindex+lists-debia...@apartia.org writes: Is there a way to get at the X screen resolution from inside the ~/.xsession script? Maybe with xrandr? Or a better tool? Yes. My script, which predates xrandr, uses xwininfo: eval `xwininfo -root |\ sed -ne 's/.*geometry \([0-9]*\)x\([0-9]*\).*/XWIDTH=\1; XHEIGHT=\2/p'` -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#484180: mesa: some ASM optimizations must be disabled for non-AMD 64-bit
tags 484180 + confirmed thanks Tormod Volden [EMAIL PROTECTED] writes: This was reported in Ubuntu https://bugs.launchpad.net/bugs/87661 and I don't have the hardware to reproduce it, but I think this will be the same in Debian: Indeed, polytopes crashes on my Intel x86_64 system running up-to-date sid unless I run it with MESA_NO_ASM set. I would of course prefer a real fix (that wouldn't require giving up all the optimizations), but I acknowledge that that may not be so easy. :-/ -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443227: fixed upstream
Jay Berkenbilt [EMAIL PROTECTED] writes:
Turns out this bug has already been fixed upstream. The upstream fix
includes the missing set of braces from my patch and also fixes
another error found inside the block. Best bet would be to pull the
patch from upstream. If you'd like, I'll generate a diff and post it
here.
Thanks for reviving this bug, Jay! The patch you sent still yields
incorrect geometry in my original use case, but upstream HEAD works
for me, as does a revised patch (attached) incorporating an additional
logic fix per upstream.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED]
Index: x11-apps-7.3+1.0/xclock/Clock.c
===
--- x11-apps-7.3+1.0.orig/xclock/Clock.c 2008-05-12 19:43:06.0 -0400
+++ x11-apps-7.3+1.0/xclock/Clock.c 2008-05-12 20:29:19.0 -0400
@@ -656,46 +656,48 @@
2 * w-clock.padding;
}
else
+ {
#endif
#ifndef NO_I18N
- if (!no_locale) {
- XFontSetExtents *fse;
+ if (!no_locale) {
+ XFontSetExtents *fse;
- if(w-clock.fontSet == NULL) {
- char **missing, *default_str;
- int n_missing;
- w-clock.fontSet = XCreateFontSet( XtDisplay(w),
- XtDefaultFontSet,
- missing,
- n_missing,
- default_str);
- }
- if (w-clock.fontSet != NULL)
- {
- /* don't free this... it's freed with the XFontSet. */
- fse = XExtentsOfFontSet(w-clock.fontSet);
-
- min_width = XmbTextEscapement(w-clock.fontSet,str,
- len)
- + 2 * w-clock.padding;
- min_height = fse-max_logical_extent.height +
- 3 * w-clock.padding;
- } else {
- no_locale = True;
- }
- }
+ if(w-clock.fontSet == NULL) {
+ char **missing, *default_str;
+ int n_missing;
+ w-clock.fontSet = XCreateFontSet( XtDisplay(w),
+ XtDefaultFontSet,
+ missing,
+ n_missing,
+ default_str);
+ }
+ if (w-clock.fontSet != NULL)
+ {
+ /* don't free this... it's freed with the XFontSet. */
+ fse = XExtentsOfFontSet(w-clock.fontSet);
+
+ min_width = XmbTextEscapement(w-clock.fontSet,str,
+ len)
+ + 2 * w-clock.padding;
+ min_height = fse-max_logical_extent.height +
+ 3 * w-clock.padding;
+ } else {
+ no_locale = True;
+ }
+ }
- if (!no_locale)
-#endif /* NO_I18N */
- {
- if (w-clock.font == NULL)
- w-clock.font = XQueryFont( XtDisplay(w),
- XGContextFromGC(
- DefaultGCOfScreen(XtScreen(w))) );
- min_width = XTextWidth(w-clock.font, str, len) +
- 2 * w-clock.padding;
- min_height = w-clock.font-ascent +
- w-clock.font-descent + 2 * w-clock.padding;
+ if (no_locale)
+ #endif /* NO_I18N */
+ {
+ if (w-clock.font == NULL)
+ w-clock.font = XQueryFont( XtDisplay(w),
+ XGContextFromGC(
+ DefaultGCOfScreen(XtScreen(w))) );
+ min_width = XTextWidth(w-clock.font, str, len) +
+ 2 * w-clock.padding;
+ min_height = w-clock.font-ascent +
+ w-clock.font-descent + 2 * w-clock.padding;
+ }
}
}
if (w-core.width == 0)
Bug#443227: fixed upstream
[Accidentally sent directly to -x at first; apologies for the goof and
resulting duplication.]
Thanks for reviving this bug, Jay! The patch you sent still yields
incorrect geometry in my original use case, but upstream HEAD works
for me, as does a revised patch (attached) incorporating an additional
logic fix per upstream.
Index: x11-apps-7.3+1.0/xclock/Clock.c
===
--- x11-apps-7.3+1.0.orig/xclock/Clock.c 2008-05-12 19:43:06.0 -0400
+++ x11-apps-7.3+1.0/xclock/Clock.c 2008-05-12 20:29:19.0 -0400
@@ -656,46 +656,48 @@
2 * w-clock.padding;
}
else
+ {
#endif
#ifndef NO_I18N
- if (!no_locale) {
- XFontSetExtents *fse;
+ if (!no_locale) {
+ XFontSetExtents *fse;
- if(w-clock.fontSet == NULL) {
- char **missing, *default_str;
- int n_missing;
- w-clock.fontSet = XCreateFontSet( XtDisplay(w),
- XtDefaultFontSet,
- missing,
- n_missing,
- default_str);
- }
- if (w-clock.fontSet != NULL)
- {
- /* don't free this... it's freed with the XFontSet. */
- fse = XExtentsOfFontSet(w-clock.fontSet);
-
- min_width = XmbTextEscapement(w-clock.fontSet,str,
- len)
- + 2 * w-clock.padding;
- min_height = fse-max_logical_extent.height +
- 3 * w-clock.padding;
- } else {
- no_locale = True;
- }
- }
+ if(w-clock.fontSet == NULL) {
+ char **missing, *default_str;
+ int n_missing;
+ w-clock.fontSet = XCreateFontSet( XtDisplay(w),
+ XtDefaultFontSet,
+ missing,
+ n_missing,
+ default_str);
+ }
+ if (w-clock.fontSet != NULL)
+ {
+ /* don't free this... it's freed with the XFontSet. */
+ fse = XExtentsOfFontSet(w-clock.fontSet);
+
+ min_width = XmbTextEscapement(w-clock.fontSet,str,
+ len)
+ + 2 * w-clock.padding;
+ min_height = fse-max_logical_extent.height +
+ 3 * w-clock.padding;
+ } else {
+ no_locale = True;
+ }
+ }
- if (!no_locale)
-#endif /* NO_I18N */
- {
- if (w-clock.font == NULL)
- w-clock.font = XQueryFont( XtDisplay(w),
- XGContextFromGC(
- DefaultGCOfScreen(XtScreen(w))) );
- min_width = XTextWidth(w-clock.font, str, len) +
- 2 * w-clock.padding;
- min_height = w-clock.font-ascent +
- w-clock.font-descent + 2 * w-clock.padding;
+ if (no_locale)
+ #endif /* NO_I18N */
+ {
+ if (w-clock.font == NULL)
+ w-clock.font = XQueryFont( XtDisplay(w),
+ XGContextFromGC(
+ DefaultGCOfScreen(XtScreen(w))) );
+ min_width = XTextWidth(w-clock.font, str, len) +
+ 2 * w-clock.padding;
+ min_height = w-clock.font-ascent +
+ w-clock.font-descent + 2 * w-clock.padding;
+ }
}
}
if (w-core.width == 0)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED]
Bug#443227: xclock: wrong geometry when running -d -norender with LANG=C
Brice Goglin [EMAIL PROTECTED] writes: Did you manage to find more details about this? No, sorry, I've been (and remain) busy with other matters. Thanks for asking, though. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442316: Xorg hotplugging problems
Julien Cristau [EMAIL PROTECTED] writes: Then it's a totally different issue, please don't mix them. Hm? AFAICT from reviewing the bug log, it's a longstanding issue that users simply didn't notice (for the most part) until hal briefly attempted to make everyone's keyboard use the evdev driver. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448770: FTBFS: missing build-dep on x11proto-kb-dev
Package: xserver-xorg-input-joystick Version: 1:1.3.0-2 Severity: serious Justification: no longer builds from source xserver-xorg-input-joystick generally fails to build from source; http://buildd.debian.org/fetch.cgi?pkg=xserver-xorg-input-joystick;ver=1%3A1.3.0-2;arch=amd64;stamp=1193584943 is a typical report, complete with the following errors: ../../src/jstk_key.c:32:32: error: X11/extensions/XKB.h: No such file or directory ../../src/jstk_key.c:33:35: error: X11/extensions/XKBstr.h: No such file or directory ../../src/jstk_key.c:34:35: error: X11/extensions/XKBsrv.h: No such file or directory ../../src/jstk_key.c: In function 'jstkInitKeys': ../../src/jstk_key.c:53: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xkbnames' [etc.] AFAICT, x11proto-kb-dev ships the relevant headers; could you please add it to Build-Depends:? Thanks! -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22.10 (SMP w/2 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443227: xclock: wrong geometry when running -d -norender with LANG=C
Package: x11-apps Version: 7.3+1 Severity: minor Running xclock -d(igital) -norender with LANG=C recently started yielding a square window with a lot of extra vertical space and not quite enough horizontal space (at least with my customary font), as if I had instead wanted an analog display. This bug appeared between xclock 1.0.2 (xbase-clients 1:7.2) and 1.0.3 (x11-apps 7.3), and does not affect other usages AFAICT. In particular, working around #352967 by specifying a strftime format rather than tweaking locale settings yields sane geometry (as does allowing Xft, but I happen to prefer core fonts here). Could you please look into it? Thanks! -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22.6 (SMP w/2 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages x11-apps depends on: ii cpp 4:4.2.1-6 The GNU C preprocessor (cpp) ii libc6 2.6.1-5GNU C Library: Shared libraries ii libfontconfig12.4.2-1.2 generic font configuration library ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library ii libpng12-01.2.15~beta5-2 PNG library - runtime ii libsm62:1.0.3-1+b1 X11 Session Management library ii libx11-6 2:1.0.3-7 X11 client-side library ii libxaw7 2:1.0.4-1 X11 Athena Widget library ii libxcursor1 1:1.1.9-1 X cursor management library ii libxext6 1:1.0.3-2 X11 miscellaneous extension librar ii libxft2 2.1.12-2 FreeType-based font drawing librar ii libxkbfile1 1:1.0.4-1 X11 keyboard file manipulation lib ii libxmu6 1:1.0.3-1 X11 miscellaneous utility library ii libxmuu1 1:1.0.3-1 X11 miscellaneous micro-utility li ii libxrender1 1:0.9.4-1 X Rendering Extension client libra ii libxt61:1.0.5-3 X11 toolkit intrinsics library ii x11-common1:7.3+2X Window System (X.Org) infrastruc x11-apps recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443227: xclock: wrong geometry when running -d -norender with LANG=C
Aaron M. Ucko [EMAIL PROTECTED] writes: In particular, working around #352967 by specifying a strftime format rather than tweaking locale settings yields sane geometry. Never mind, this doesn't appear to work reliably after all. :-/ -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443227: xclock: wrong geometry when running -d -norender with LANG=C
Brice Goglin [EMAIL PROTECTED] writes: I can't reproduce the problem here. There are very few commits between Interesting, as I can reproduce it 100% reliably with both i386 and amd64 binaries. I do have some extra resource settings I neglected to mention earlier, XClock*background: lightgray XClock*font:fixed XClock*geometry:-0+0 XClock*padding: 1 XClock*update: 1 but only *font is at all likely to be relevant. 1.0.2 and 1.0.3, so it should be very easy to locate where the breakage occurred. Could you try to git bisect the upstream xclock repository? Sure, no problem. I get $ git bisect log git-bisect start # bad: [1ea56dd7d67cef80f364fafcf985fb4a6846109d] Version bump: 1.0.3 git-bisect bad 1ea56dd7d67cef80f364fafcf985fb4a6846109d # good: [d335cefbbe5d23c410f8e8b7af0692559b649e67] Bump to 1.0.2 git-bisect good d335cefbbe5d23c410f8e8b7af0692559b649e67 # good: [41503ac2d7c84502074b3b6528478fe017060ef7] Add pointer to Xft/fontconfig font name format to man page git-bisect good 41503ac2d7c84502074b3b6528478fe017060ef7 # bad: [6f845b1d5516864e143113ca074e98b7be194adb] Change xclock_CFLAGS to AM_CFLAGS to make automake-1.10 happier git-bisect bad 6f845b1d5516864e143113ca074e98b7be194adb # bad: [a450fbb0f93f8bcdaabfb623fe49ddbb12468287] Man page: add missing options to synopsis section git-bisect bad a450fbb0f93f8bcdaabfb623fe49ddbb12468287 # bad: [8476e5fbddafc17190347e86a68f66dc3958] Don't segfault if unable to load a usable fontset git-bisect bad 8476e5fbddafc17190347e86a68f66dc3958 Please let me know if there's any other information you'd like me to provide. Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442897: xserver-xorg-video-dummy: please bump build-dep on xserver-xorg-dev
Package: xserver-xorg-video-dummy Version: 1:0.2.0-6 Severity: grave Justification: renders package unusable xserver-xorg-video-dummy still depends merely on xserver-xorg-dev (= 2:1.2.99.902); at least on amd64, the autobuilder consequently wound up building it against xserver 1.3, yielding a binary that will not (or at least claims not to) work with 1.4. Could you please bump the build-dependency appropriately? Thanks! -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22.6 (SMP w/2 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#437961: xdm: loading Xresources fails because bindir/xrdb does not exist
Package: xdm Version: 1:1.1.5-1 Severity: normal The latest xdm upload introduced a nasty regression: the DisplayManager.xrdb xdm-config resource defaults to bindir/xrdb (sic) rather than /usr/bin/xrdb. As a result, xdm fails to load /etc/X11/xdm/Xresources, defaulting to a relatively unattractive configuration. Could you please fix it? Thanks! -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22.1 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xdm depends on: ii cdebconf [debconf-2.0] 0.119Debian Configuration Management Sy ii cpp 4:4.1.2-3The GNU C preprocessor (cpp) ii debconf [debconf-2.0] 1.5.14 Debian configuration management sy ii libc6 2.6.1-1 GNU C Library: Shared libraries ii libfontconfig1 2.4.2-1.2generic font configuration library ii libice6 2:1.0.3-3X11 Inter-Client Exchange library ii libpam0g0.79-4 Pluggable Authentication Modules l ii libselinux1 2.0.15-2+b1 SELinux shared libraries ii libsm6 2:1.0.3-1+b1 X11 Session Management library ii libx11-62:1.0.3-7X11 client-side library ii libxau6 1:1.0.3-2X11 authorisation library ii libxaw7 1:1.0.3-3X11 Athena Widget library ii libxdmcp6 1:1.0.2-2X11 Display Manager Control Protoc ii libxext61:1.0.3-2X11 miscellaneous extension librar ii libxft2 2.1.12-2 FreeType-based font drawing librar ii libxinerama11:1.0.2-1X11 Xinerama extension library ii libxmu6 1:1.0.3-1X11 miscellaneous utility library ii libxpm4 1:3.5.6-3X11 pixmap library ii libxrender1 1:0.9.2-1X Rendering Extension client libra ii libxt6 1:1.0.5-3X11 toolkit intrinsics library ii lsb-base3.1-24 Linux Standard Base 3.1 init scrip ii x11-common 1:7.2-5 X Window System (X.Org) infrastruc ii xbase-clients 1:7.2.ds2-2 miscellaneous X clients xdm recommends no packages. -- debconf information: * shared/default-x-display-manager: xdm xdm/stop_running_server_with_children: false xdm/daemon_name: /usr/bin/xdm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Splitting/reorganizing xbase-clients xutils
Timo Aaltonen [EMAIL PROTECTED] writes: xfs (Fedora:xorg-x11-xfs) - # why not bundle these together? fslsfonts (xutils) fstobdf (xbase-clients) showfont (xutils) xfs (xfs) xfsinfo (xutils) FWIW, I'd prefer to see the clients in separate (binary) packages from the server, which may be running on some other host. Also, in general, do the programs in each new package all have similar dependencies now? IIRC, one motivation for refactoring was complaints about xbase-clients depending on a lot of libraries that only a handful of the programs it contains actually needs, so it would be unfortunate if such dependency pollution were still present. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420506: DRI fails
Esteban Paz Freire [EMAIL PROTECTED] writes: VideoRam65536 I ran into this myself (though I have an i915 rather than an i855) and found that commenting out the VideoRam directive helped. (X proceeded to claim a whopping 256M, though, which strikes me as excessive. :-/) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420506: DRI fails
Michel Dänzer [EMAIL PROTECTED] writes: It probably doesn't really use that much memory up front. The log file Thanks for clarifying; I had hoped that might be the case. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Bug#420240: xserver-xorg-video-intel: binary-arch target builds architecture-independent package
Package: xserver-xorg-video-intel Version: 2:2.0.0-1 Severity: normal Greetings! Having run a binary-only build of xserver-xorg-video-intel for personal use (rather than waiting for the buildd), I was surprised to observe that I wound up with both the desired architecture-dependent -video-intel package and the architecture-independent transitional -video-i810 package. As I understand it, this situation annoys the buildd maintainers, who have to clean up the extraneous arch-all packages manually. Anyway, the fix should be pretty straightforward: add -a to the binary-arch target's main block of dh_* calls (all but dh_test*) and add dh_* -i calls under binary-indep. As it ships nothing but a small handful of files under /usr/share/doc, I expect the following set should suffice (though I haven't actually bothered to test it). dh_testdir dh_testroot dh_installdocs -i dh_installchangelogs -i ChangeLog dh_compress -i dh_fixperms -i dh_installdeb -i dh_gencontrol -i dh_md5sums -i dh_builddeb -i [Package-specific info snipped (my configuration details are irrelevant)] -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.20.7 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xserver-xorg-video-intel depends on: ii libc6 2.5-3GNU C Library: Shared libraries ii libdrm2 2.3.0-4 Userspace interface to kernel DRM ii xserver-xorg-core 2:1.3.0.0.dfsg-1 X.Org X server -- core server xserver-xorg-video-intel recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415646: sarge etch dist-upgrade fails, x11-common fails overwrite /usr/X11R6/bin
Scott Raun [EMAIL PROTECTED] writes: dpkg: error processing /var/cache/apt/archives/xcursor-themes_1.0.1-5_all.deb (--unpack): trying to overwrite `/etc/X11/cursors/core.theme', which is also in package xlibs-data Running dpkg -i --force-overwrite /var/cache/apt/archives/xcursor-themes_1.0.1-5_all.deb should let apt-get -f install continue (though xcursor-themes already declares appropriate versioned Conflicts: and Replaces:, so that theoretically shouldn't have been necessary). -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415646: sarge etch dist-upgrade fails, x11-common fails overwrite /usr/X11R6/bin
Scott Raun [EMAIL PROTECTED] writes: emacs21: error while loading shared libraries: libXaw3d.so.6: cannot That should be in the xaw3dg package; please make sure it's properly installed, and that /etc/ld.so.conf still lists /usr/X11R6/lib if you still have a version that installs into there. !!! ERROR! The map file `antt.map' has not been found at all. Some file in /etc/texmf/updmap.d probably has a dangling reference to antt.map; please comment the line out (with a leading #) or move the file out of that directory altogether. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xorg override disparity
Julien Cristau [EMAIL PROTECTED] writes: I think the override should be changed for these packages. They are now dummy packages, provided for upgrades from sarge. Is the correct section for these oldlibs, or something different? I'd say oldlibs. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404079: display problem with xterm + screen and bold characters
Thomas Dickey [EMAIL PROTECTED] writes: agree - I was not thinking of the search list (though I'm aware of it). The description I read did not mention it, either... Mac OS's approach to dynamic libraries is ... somewhat unusual. AFAICT, the way things work there is that each library hard-codes a (single) canonical installation location, which the static linker then embeds in any executables (or other dynamic libraries) that link to it. The runtime linker then proceeds to search for each required library in, in order, DYLD_LIBRARY_PATH, the hardcoded per-library path, and DYLD_FALLBACK_LIBRARY_PATH. (It's actually slightly more complicated than that because there's also the concept of frameworks, but I don't believe it concerns ncurses.) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392567: libx11-data: Dead keys breakage
I see this too; Ubuntu's 017_en_US_UTF-8_XI18N_OBJS.diff (attached, and only partially applied upstream AFAICT) corrects the references to nonexistent shared objects, which look like an accidental regression on upstream's part incurred when switching to git. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. --- /usr/share/X11/locale/en_US.UTF-8/XI18N_OBJS 2006-08-24 12:19:22.0 +0200 +++ libx11-1.0.0/nls/en_US.UTF-8/XI18N_OBJS 2006-06-22 23:22:22.0 +0200 @@ -2,7 +2,6 @@ # # XI18N objects table for euro locales # -XLC common/xlcUTF-8 _XlcUnicodeLoader # XLC_open -XOM common/xomLTRTTB _XomGenericOpenOM # XOM_open -XIM common/xiiimp _SwitchOpenIM # XIM_open -XIM common/xiiimp _XimpLocalOpenIM # XIM_open +XLCcommon/xlcUTF8Load _XlcUtf8Loader # XLC_open +XOM common/xomGeneric _XomGenericOpenOM # XOM_open +XIM common/ximcp_XimOpenIM _XimRegisterIMInstantiateCallback _XimUnRegisterIMInstantiateCallback # XIM_openXIM_register XIM_unregister
Re: Help compiling 4.3.0 for 3.1 stable
Robin Whittle [EMAIL PROTECTED] writes: I installed packages dbs (0.34), debhelper (4.2.3), build-essential (10.1), debian-builder (1.3-5), devscripts (2.8.14). dbs is Doogies Build System: You will almost certainly need to install a number of additional packages; apt-get build-dep xfree86 should take care of that step. /zz/xfree86_4.3.0.dfsg.1.orig.tar.gz /zz/xfree86_4.3.0.dfsg.1-14sarge1.diff.gz I would advise additionally downloading xfree86_4.3.0.dfsg.1-14sarge1.dsc and then running dpkg-source -x xfree86_4.3.0.dfsg.1-14sarge1.dsc which will take care of verifying checksums, unpacking the upstream tarball, applying the debian patch, and marking debian/rules as executable. make debian/rules unpacked make debian/rules setup Your usage is slightly off: either run debian/rules directly (after marking it as executable if you extracted everything by hand) or else run make -f debian/rules ... ^^ to tell make that debian/rules is a makefile rather than a target of the default makefile. Incidentally, none of this advice is particularly specific to X, so I'd suggest directing further questions of this nature to [EMAIL PROTECTED] -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X Strike Force X.Org X11 SVN commit: r3393 - in trunk/app/compiz: debian debian/patches gnome/window-decorator include plugins src
X Strike Force SVN Repository Admin [EMAIL PROTECTED] writes: +/usr/bin/compiz.real --strict-binding --indirect-rendering --use-cow $@ gconf $@ requires double quotes to DTRT: /usr/bin/compiz.real --strict-binding --indirect-rendering --use-cow $@ gconf -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#368972: libgl1-mesa-directfb-dev should not provide libgl-dev: ITNMU
Steve Langasek [EMAIL PROTECTED] writes: I will also be fixing this bug and bug #386185 in the process. Thanks for taking care of this; as an i915 user, I've been looking forward to having a more consistent set of packages in unstable. Any chance of addressing #369895 while you're at it? The fix is a one-liner, and upstream applied it three months ago: http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/tnl/t_vb_render.c?r1=1.49r2=1.50view=patch Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384204: 32-bit biarch support
Please take a look at http://wiki.debian.org/multiarch . -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X40 direct rendering
Kai Hendry [EMAIL PROTECTED] writes:
ERROR! sizeof(I830DRIRec) does not match passed size from device driver
This is a known problem and due to version skew, which you can
straighten out by grabbing libgl1-mesa-{dri,glx} from experimental
(along with libgl1-mesa-dev and mesa-common-dev if relevant).
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: FTBFS imake
Kai Hendry [EMAIL PROTECTED] writes: I've built xtel on two different unstable machines successfully, though Fabio can't on his unstable machine. His machine is up to date. Why does his fail and mine doesn't? What's at fault here? Because xutils-dev doesn't *pre*-depend on x11-common (= 1:7.0.0), it's entirely possible that it wound up misinstalled on his system. To wit, dpkg may have unpacked xutils-dev with /usr/lib/X11 still a symlink to /usr/X11R6/lib/X11, inadvertently stranding imake's database there. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364233: mesa-swx11-source: indirect rendering broken on 64-bit platforms
Aaron M. Ucko [EMAIL PROTECTED] writes: [XSF: when this patch is in, please bump xorg-server's build dependency on mesa-swx11-source accordingly in order to pick up the fixes.] Marcelo recently uploaded a fixed version of Mesa (thanks!); as such, please go ahead and version xorg-server's build dependency on mesa-swx11-source to mesa-swx11-source (= 6.4.2-1), mesa-swx11-source ( 6.5) Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mesa 6.4.2 and 6.5, Release Candidates
Marcelo E. Magallon [EMAIL PROTECTED] writes: I was trying to be cautious since I don't really understand which parts of Mesa are needed for the X bits build. My guess is the rasterizer. Fair enough; it's definitely better to err on the side of inclusion. At any rate, although I'm not entirely clear on X's needs either, I can confirm that current xorg-server sources build cleanly against this morning's version of mesa-swx11-source 6.4.2-1. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mesa 6.4.2 and 6.5, Release Candidates
For the most part, your release candidates look good, and I'm pleased to report that they build without errors on my amd64 box. However, I found the autogenerated mesa-swx11-source.install files to be a bit off. The main problem is one of formatting: dh_install always interprets destination paths as *directories*, so repeating filenames backfires badly, yielding unusable binary packages. In addition, the new approach seems to be major overkill -- whereas 6.4.1-0.4 shipped 349 files totalling ~7.6M, 6.4.2-1 ships 1060 files totalling ~18.3M. I would suggest either maintaining the .install file directly, but with wildcarded source paths (cutting the contents down to a reasonable 31 lines by my count) or else fixing the logic as follows: diff -u mesa-6.4.2/debian/rules mesa-6.4.2/debian/rules --- mesa-6.4.2/debian/rules +++ mesa-6.4.2/debian/rules @@ -225,7 +225,8 @@ debian/mesa-swx11-source.install: ( find src/mesa src/glx/x11 include/GL/internal -name '*.[ch]' ; \ find include/GL -name 'xmesa*' ) | \ - perl -lne 'print $$_, , usr/share/mesa-source/ . $$_' $@ + while read x; do echo $$x usr/share/mesa-source/`dirname $$x`; done \ +$@ binary: binary-indep binary-arch .PHONY: build clean binary-indep binary-arch binary install configure debian/mesa-swx11-source.install With that packaging issue out of the way, I was able to confirm that bug #364228 is no more; thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366994: xfonts-encodings: Absolute_path patch makes it out of work
Hongzheng Wang [EMAIL PROTECTED] writes: But the upgrade of package xfonts-encodings results in a simliar bug again. It seems that the absolute_path patch may not work, since it makes X11 applications cannot find a proper encodings file even when libfontenc1 does provide a right encoding-path. The problem seems to be that the absolute paths are broken, lacking crucial slashes that mkfontdir does *not* automatically supply: -p Specify a prefix that is prepended to the encoding file path names when they are written to the encodings.dir file. The prefix is prepended as-is. If a `/' is required between the prefix and the path names, it must be supplied explicitly as part of the prefix. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X Strike Force X.Org X11 SVN commit: r2001 - trunk/debian/xorg/debian
David Nusinow [EMAIL PROTECTED] writes: No, because we really just want to get rid of these things. They're functionally replicated in x11-common anyway now. Sure, but in that case you shouldn't be testing $1 for purge, as the postinst will never be invoked that way. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X Strike Force X.Org X11 SVN commit: r2001 - trunk/debian/xorg/debian
X Strike Force SVN Repository Admin [EMAIL PROTECTED] writes: Added: trunk/debian/xorg/debian/xfree86-common.postinst.in Modified: trunk/debian/xorg/debian/changelog trunk/debian/xorg/debian/control Log: [...] * Remove xfree86-common stuff from /etc/X11/Xsession.d when the new xfree86-common package is purged. Thanks Joe Drew. (closes: #318294) Shouldn't that logic go in the post*rm*? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343389: rxvt won't start
[Resending due to typo in original headers] Russ Cook [EMAIL PROTECTED] writes: I'm running gnome. From a xterminal, I try to start rxvt, and get this message: rxvt: can't load color Black rxvt: can't load color Black rxvt: aborting Has anyone seen this problem, and can you tell me what I should check? You may have managed to hit http://bugs.debian.org/343389 . Try reinstalling the x11-common package with dpkg --force-confmiss: dpkg -i --force-confmiss /var/cache/apt/archives/x11-common_*.deb -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: HELP!! Re: Bug#365126: wmrack - FTBFS: error: WMRack needs X Windows!!!
Chris Waters [EMAIL PROTECTED] writes:
CFLAGS=$CFLAGS -I${x_includes}
LIBS=$LIBS -L${x_libraries} -lX11
x_includes and x_libraries now expand to the empty string, biting
anything that assumed otherwise. Accounting for that isn't too hard,
though:
CFLAGS=$CFLAGS ${x_includes:+-I$x_includes}
LIBS=$LIBS ${x_libraries:+-L$x_libraries} -lX11
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X Strike Force X.Org X11 SVN commit: r1952 - tags/driver/xserver-xorg-video-i810
David Nusinow [EMAIL PROTECTED] writes: It was rejected because of cruft still hanging around in experimental. Ah, yeah, I see how that could have happened. I've written ftpmaster to hopefully clear it out so I can re-upload. Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X Strike Force X.Org X11 SVN commit: r1952 - tags/driver/xserver-xorg-video-i810
X Strike Force SVN Repository Admin [EMAIL PROTECTED] writes: Tag upload of xserver-xorg-video-i810-2:1.4.1.3-1 to unstable Are you sure you actually uploaded this? I see no sign of it. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364113: x11-common: more conflicts needed: beaver, lsb-core, yank
Package: x11-common Version: 1:7.0.10 Severity: serious Justification: Policy 6.5(4) At least on amd64, the following packages ship /usr/X11R6/bin as a directory (but don't actually populate it): beaver 0.2.5-2 lsb-core 3.1-4 yank 0.2.1-7.2 As in http://bugs.debian.org/364007, x11-common should therefore conflict with those versions. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (300, 'unstable'), (300, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.9 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages x11-common depends on: ii cdebconf [debconf-2.0]0.100 Debian Configuration Management Sy ii debconf [debconf-2.0] 1.4.72 Debian configuration management sy ii debianutils 2.15.6 Miscellaneous utilities specific t ii lsb-base 3.1-4 Linux Standard Base 3.1 init scrip x11-common recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363359: xserver-xorg: Resolution has changed from 100 dpi, to 75 dpi
Michel Dänzer [EMAIL PROTECTED] writes: Hmm indeed, it's not in /var/cache/apt/archives/xbase-clients_1% 3a7.0.0-4_powerpc.deb, so how come it's in /var/lib/dpkg/info/xbase-clients.list here? *shrug* Because it used to be a conffile, and nothing automatically cleans up old conffiles. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Bug#364228: mesa-swx11-source: indirect rendering broken on 64-bit platforms
Package: mesa-swx11-source
Version: 6.4.1-0.4+ucko1
Severity: important
Tags: patch upstream
[XSF: when this patch is in, please bump xorg-server's build dependency
on mesa-swx11-source accordingly in order to pick up the fixes.]
As reported at https://bugs.freedesktop.org/show_bug.cgi?id=5835 and
https://bugs.freedesktop.org/show_bug.cgi?id=6419, the X server's
indirect rendering code (built from mesa-swx11-source) falls over on
64-bit systems, with the server reporting errors of the form
No matching visual for __GLcontextMode with visual class = N (N), nplanes = N
and libGL reporting corresponding errors of the form
3D driver claims to not support visual 0xN
The underlying problem seems to be data type mismatches (some due to
Mesa defaulting to the wrong thing in the absence of dix-config); I
was able to correct it with the small attached patch, merged from
three single-file Gentoo patches. Could you please apply it, or one
of those cited in fd.o bug #5835 (which I didn't run across until
later)?
Thanks!
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (300, 'unstable'), (300,
'testing')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.9
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
-- no debconf information
--- mesa-6.4.1.orig/src/glx/x11/indirect_vertex_array.c
+++ mesa-6.4.1/src/glx/x11/indirect_vertex_array.c
@@ -530,7 +530,7 @@
emit_DrawArrays_header_old( __GLXcontext * gc,
struct array_state_vector * arrays,
size_t * elements_per_request,
- size_t * total_requests,
+ unsigned int * total_requests,
GLenum mode, GLsizei count )
{
size_t command_size;
--- mesa-6.4.1.orig/src/mesa/main/glheader.h
+++ mesa-6.4.1/src/mesa/main/glheader.h
@@ -46,6 +46,9 @@
#ifndef GLHEADER_H
#define GLHEADER_H
+#ifdef HAVE_DIX_CONFIG_H
+#include dix-config.h
+#endif
#if defined(XFree86LOADER) defined(IN_MODULE)
#include xf86_ansic.h
--- mesa-6.4.1.orig/src/mesa/drivers/dri/common/glcontextmodes.c
+++ mesa-6.4.1/src/mesa/drivers/dri/common/glcontextmodes.c
@@ -39,6 +39,9 @@
# include imports.h
# define __glXMemset memset
#else
+# if defined (HAVE_DIX_CONFIG_H)
+# include dix-config.h
+# endif
# include X11/X.h
# include GL/glx.h
# include GL/glxint.h
Bug#362129: xbase-clients: FTBFS: Missing Build-Depends
Daniel Schepler [EMAIL PROTECTED] writes: It looks like this possibly means that libxcursor-dev needs to have Depends: libxfixes-dev. If that's correct, feel free to reassign the bug. Well, xbase-clients still has missing build dependencies either way, as xdpyinfo, xsetmode, and xsetpointer all need libxi-dev. (I do agree that it might make sense for libxcursor-dev to depend on libxfixes-dev, though.) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 6.8.2 packages available anywhere?
Greg Stark [EMAIL PROTECTED] writes: I've pretty much come to the conclusion that I have to downgrade my system to 6.8.2 to overcome a few problems (primarily x.org buzilla id 5443). But now I Yeah, this bit me too. :-/ can't find xserver-xorg 6.8.2 anywhere. I seem to recall a server that contained old Debian packages. Or failing that does anyone have xserver-xorg 6.8.2 somewhere? Is it likely to work with the rest of 6.9.0 X or am I going to have to downgrade everything? You'll run into DRI version skew, and consequently be stuck with software rendering, unless you downgrade (and hold back) xlib(os)mesa-* in addition to xserver-xorg(-dbg). Apart from that, I haven't encountered any problems with mixing and matching versions. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359023: xterm: Xft support missing on amd64
AFAICT, xterm wound up getting built against a buggy version of libxft-dev (namely, 2.1.8.2-5) on amd64 and should therefore be binNMUed for that platform. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X Strike Force X.Org X11 SVN commit: r1265 - branches/modular/debian/xorg/debian
X Strike Force SVN Repository Admin [EMAIL PROTECTED] writes: * Provide a compatibility symlink to /usr/lib/X11/fonts (their new home) at /usr/X11R6/lib/X11/fonts. This will let external fonts work as expected. Thanks Eugene Konev. I thought they were moving to /usr/share/fonts/X11? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X Strike Force X.Org X11 SVN commit: r1308 - branches/modular/debian/xorg/debian
X Strike Force SVN Repository Admin [EMAIL PROTECTED] writes: +Package: xlibmesa-dri +Section: libdevel +Architecture: any +Depends: libgl1-mesa-dri This will probably be more effective if you version libgl1-mesa-dri's conflict with xlibmesa-dri. :-) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347791: upgrade resets x-terminal-emulator alternative
This is presumably a side effect of xterm's move from /usr/X11R6/bin to /usr/bin, which involves dropping the old alternatives and adding new ones. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345393: x-window-system-core: missing alternate dependency on libgl1-mesa-dri
Package: x-window-system-core Version: 6.9.0.dfsg.1-1 Severity: normal Happy holidays, and congratulations on getting 6.9.0 out the door! That said, I'm afraid I have a bug to report: As noted in #334721, which I believe it's too late to reopen :-/, the libgl1-mesa-dri should be an alternative *both* to xlibmesa-gl *and* to xlibmesa-dri, the latter coming from the substvar XWSC-Special-Depends, defined via XWSC_SPECIAL_DEPENDS in debian/scripts/vars.*. x-window-system-dev is another matter, as not all of the -dbg packages it depends on *have* Mesa equivalents; perhaps those dependencies could be downgraded to recommendations (and alternatives added where possible, including in XWSD-Special-Depends)? Thanks! -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'sarge-unsupported') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343129: xemacs / libX11 / NVIDIA crashes on opteron under kernel 2.6.14-2
[EMAIL PROTECTED] writes: OK, see the backtrace with the dbg version of libx11-6 below. We now we know what xemacs passed, and where the libx11 died, and the error is no such file or directory . Looking at the source for that file (ChkIfEv.c) doesn't show any obvious (to me) place where a file or directory is being referenced. I've added the maintainer of that file I'm pretty sure the message just means that gdb can't find ChkIfEv.c to show you the actual contents of its line 57 -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X Strike Force X.Org X11 SVN commit: r890 - in trunk/debian: . patches patches/general
X Strike Force SVN Repository Admin [EMAIL PROTECTED] writes: Added: trunk/debian/patches/general/032_fix_matrox_display.diff Modified: trunk/debian/changelog trunk/debian/patches/series Log: * Change ls to /bin/ls in Xsession to prevent login problems if ls is locally aliased to ls --color=auto. Thanks January Weiner, David Vernazobres. (closes: #340443, #337650) You seem to have put the wrong changelog entry here... + * Add general/032_fix_matrox_display.diff to fix corruption on some cards. +Thanks Julien Wajsberg. (closes: #320328) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X Strike Force XFree86 SVN commit: r2289 - /
X Strike Force SVN Repository Admin [EMAIL PROTECTED] writes: Modified: NEWS.xhtml === (Binary files differ) It would be nice if svn could be told that this is a text file, and as such reasonable to diff conventionally. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [i915 x.org patch] suppress debugging spewage on non-i386
David Nusinow [EMAIL PROTECTED] writes: Sorry for not getting back to you earlier. I like the patch, and I would No problem; it's perfectly understandable given that the audit was still going on the first time around (and rightly took priority). like to roll it in to the first round of packages for unstable, I just haven't gotten to it yet. If it doesn't get in to the first round (although it's so harmless I don't see why it won't) I'll make certain it gets in to the second round. Thank you for the patch! Great, thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [i915 x.org patch] suppress debugging spewage on non-i386
Now that the patch audit is complete (yay!) and I've had more time to
test the driver (mostly via xscreensaver hacks ;-)), I would like to
resubmit the following patch; as far as I can tell, there's really no
need for such debugging, particularly not mandatorily.
As it stands, attempting to use the i915 DRI driver on non-i386
hardware (such as my EM64T system or perhaps certain ia64 systems)
produces a flood of debugging output on standard error, making the
driver relatively useless for practical purposes. The patch below,
stolen from Mesa's trunk, disables this output; I'd greatly appreciate
it if it could make its way into Debian's official packages.
(Other than that, the driver seems to work fine, and to give a visible
performance boost over the unaccelerated 3D I had with XFree86.)
For the record, the associated upstream log message was
Disable leftover debug statements
Thanks.
http://cvs.freedesktop.org/mesa/Mesa/src/mesa/drivers/dri/i915/intel_tris.c?r1=texttr1=1.5r2=texttr2=1.6makepatch=1diff_format=u
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/i915/intel_tris.c,v
rcsdiff: /cvs/mesa/Mesa/src/mesa/drivers/dri/i915/intel_tris.c,v: warning:
Unknown phrases like `commitid ...;' are present.
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- intel_tris.c2005/05/09 17:59:13 1.5
+++ intel_tris.c2005/05/17 22:21:08 1.6
@@ -63,9 +63,9 @@
#else
#define COPY_DWORDS( j, vb, vertsize, v ) \
do { \
- if (1) fprintf(stderr, \n); \
+ if (0) fprintf(stderr, \n); \
for ( j = 0 ; j vertsize ; j++ ) {\
- if (1) fprintf(stderr,-- v(%d): %x/%f\n,j, \
+ if (0) fprintf(stderr,-- v(%d): %x/%f\n,j, \
((GLuint *)v)[j], \
((GLfloat *)v)[j]); \
vb[j] = ((GLuint *)v)[j];\
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[i915 x.org patch] suppress debugging spewage on non-i386
As it stands, attempting to use the i915 DRI driver on non-i386
hardware (such as my EM64T system or perhaps certain ia64 systems)
produces a flood of debugging output on standard error, making the
driver relatively useless for practical purposes. The patch below,
stolen from Mesa's trunk, disables this output; I'd greatly appreciate
it if it could make its way into Debian's official packages.
(Other than that, the driver seems to work fine, and to give a visible
performance boost over the unaccelerated 3D I had with XFree86, though
I haven't had time to test it too extensively yet.)
For the record, the associated upstream log message was
Disable leftover debug statements
Thanks.
http://cvs.freedesktop.org/mesa/Mesa/src/mesa/drivers/dri/i915/intel_tris.c?r1=texttr1=1.5r2=texttr2=1.6makepatch=1diff_format=u
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/i915/intel_tris.c,v
rcsdiff: /cvs/mesa/Mesa/src/mesa/drivers/dri/i915/intel_tris.c,v: warning:
Unknown phrases like `commitid ...;' are present.
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- intel_tris.c2005/05/09 17:59:13 1.5
+++ intel_tris.c2005/05/17 22:21:08 1.6
@@ -63,9 +63,9 @@
#else
#define COPY_DWORDS( j, vb, vertsize, v ) \
do { \
- if (1) fprintf(stderr, \n); \
+ if (0) fprintf(stderr, \n); \
for ( j = 0 ; j vertsize ; j++ ) {\
- if (1) fprintf(stderr,-- v(%d): %x/%f\n,j, \
+ if (0) fprintf(stderr,-- v(%d): %x/%f\n,j, \
((GLuint *)v)[j], \
((GLfloat *)v)[j]); \
vb[j] = ((GLuint *)v)[j];\
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X Strike Force X.Org X11 SVN commit: r259 - trunk/debian
[EMAIL PROTECTED] (Aaron M. Ucko) writes: Cool. Could you please also post the .orig.tar.gz when you get a chance, to allow builds for non-i386 architectures (amd64 in my case)? Now that this has materialized (thanks!), I'm pleased to report that my amd64 build ran without errors (and even passed the manifest test). I haven't yet actually tried the resulting binaries, though. I should also note that I was building in my standard development environment, which is hardly minimal, so I can't speak for the sufficiency of the official build dependencies. I'm glad to see the X.Org packaging coming along so nicely, and appreciate the effort that went into it. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315315: xserver-xfree86: accel disabled on ct69000
Dan Christensen [EMAIL PROTECTED] writes: I won't have a chance to try that until tomorrow, but I don't think it will help. The first reason is that the XF86Config-4 man page says that the two forms are equivalent. The second reason is that the The chips(4) manpage gave me the impression that it might be asymmetric, with the general rule being that settings for (e.g.) NoAccel automatically translate into settings for Accel but not vice versa; however, a bit of digging through the source tree reveals that it is always fully symmetric and you're consequently out of luck. :-/ -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315315: xserver-xfree86: accel disabled on ct69000
Dan Christensen [EMAIL PROTECTED] writes: That URL seems to only show one user with a problem, whereas my old laptop with that chip has uptimes of over a year. It might make sense to have acceleration disabled by default, but it would be nice if I could insist on acceleration by putting Option Accel You may need to use a double negative here; does Option NoAccel off work any better? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X Strike Force Xrender SVN commit: r109 - trunk/debian
X Strike Force SVN Repository Admin [EMAIL PROTECTED] writes: # New symbols have been added in libXrender 0.9.0. -DEB_DH_MAKESHLIBS_ARGS_libxrender1 = -V 'libxrender1 ( 1.3.0)' +DEB_DH_MAKESHLIBS_ARGS_libxrender1 = -V libxrender1 ( 1.3.0) Shouldn't the version string be ( 1:0.9.0)? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X Strike Force X.Org X11 SVN commit: r108 - trunk/debian
X Strike Force SVN Repository Admin [EMAIL PROTECTED] writes: Adding xserver-xorg.bug.presubj from xserver-xfree86.bug.presubj in xfree trunk. Please don't forget to rebrand it. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#287608: Missing dependency on lesstif2-dev?
Marcelo E. Magallon [EMAIL PROTECTED] writes: I'm willing to say that the following packages use GLw: Package: libvibrant6 Package: ncbi-tools-x11 For the record, these don't; there may be other false positives too. Anyway, it looks like libGLw's object files are independent of each other, so code that pulls in GLwDrawA.h rather than GLwMDrawA.h should be able to link against libGLw without needing any Motif or Lesstif libraries, though it will still generally need Xt (unless it limits itself to a couple of lower-level utility functions, which is pretty unlikely). As such, I'd say that whatever package contains libGLw should merely Suggest lesstif2-dev | lesstif-dev, though it ought to Recommend, if not Depend on, libxt-dev. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: enforcing xautolock
martin f krafft [EMAIL PROTECTED] writes: My first thought was that this is related to `set -e`, which would prevent the subshell to ever execute kill, since the killing of xautolock would be a failure. However, shell options do not propagate to subshells, so the xautolock-containing shell is +e by default. My experiments indicate otherwise: $ for sh in sh bash dash posh ksh zsh; do $sh -e -c '(false; echo foo)'; done $ for sh in sh bash dash posh ksh zsh; do $sh -c '(false; echo foo)'; done foo foo foo foo foo foo $ for sh in sh bash dash posh ksh zsh; do $sh -e -c '(set +e; false; echo foo)'; done foo foo foo foo foo foo -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Bug#281203: SEGV in XftCharIndex at if (!font-hash_value) return 0
[Oops, I accidentally sent the previous reply only to -x.] bear [EMAIL PROTECTED] writes: I run a problem which use fltk and SEGV at the beginning of XftCharIndex If this is an ITK application that also uses VTK, you're probably running into http://bugs.debian.org/277602 . -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Bug#281203: SEGV in XftCharIndex at if (!font-hash_value) return 0
bear [EMAIL PROTECTED] writes: I run a problem which use fltk and SEGV at the beginning of XftCharIndex If this is an ITK application that also uses VTK, you're probably running into http://bugs.debian.org/277602 . -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Bug#275034: xserver-xfree86: lynx is a build dependency (missing)
Luke Kenneth Casson Leighton [EMAIL PROTECTED] writes: it's not a matter of belief: i saw the error, i manually did an apt-get install lynx, the error went away. Hm, perhaps you're running into an apt bug then, since lynx definitely appears to be in the current (4.3.0.dfsg.1-8) build-deps. Yes, you need to surround it with double quotes; otherwise it's no better than $*. ah _ha_. thank you v. much. No problem. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Bug#275034: xserver-xfree86: lynx is a build dependency (missing)
Luke Kenneth Casson Leighton [EMAIL PROTECTED] writes: ... why did it not get installed when i did an apt-get build-dep then?? Why do you believe it's not installed? Do you perhaps instead have one of the packages that provide it (lynx-cur or the old lynx-ssl package)? #!/bin/sh ccache /usr/bin/gcc-3.4 -O3 -march=athlon-xp -funroll-loops -fomit-frame-pointer -ffast-math $@ ... am i doing something silly [with the [EMAIL PROTECTED] Yes, you need to surround it with double quotes; otherwise it's no better than $*. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Still having lots of trouble with Alt/Meta keys
Daniel Jacobowitz [EMAIL PROTECTED] writes: All I want is for my Windows keys to send Meta, and xterm to treat that like Escape. This requires XTerm*metaSendsEscape: true. [For some reason, I have to start an xterm, run xrdb in it, and start a new xterm for this to take effect. I can't run it from a VT with $DISPLAY set; it just switches to the X server instead of merging resources. Huh.] Try running xrdb with the -retain option: -retain This option indicates that the server should be instructed not to reset if xrdb is the first client. This never be necessary (sic.) under normal conditions, since xdm and xinit always act as the first client. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Everything gtk is crashing!
Your laptop has a Transmeta processor, right? If so, I believe you're running into Bug#216933 (aka #234556 and #261251)... -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Bug#257730: xserver-xfree86: enviroment variable LD_LIBRARY_PATH unset in XFree86
Jan Gregor [EMAIL PROTECTED] writes: You mean to put export LD_LIBRARY_PATH= ... into .xinitrc ? Of course I tried it but again other exports are ok but this is ignored. Workaround xterm is setgid utmp, and therefore triggers the same (justified) dynamic loader paranoia. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Bug#234556: xlibs: many clients get BadLength error from X_ChangeProperty request
Emmanuel Fleury [EMAIL PROTECTED] writes: Does anybody know how to catch these packets ? You might find xmon (which is packaged and has an extensive man page) of interest. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: X Strike Force XFree86 SVN commit: r1229 - in trunk/debian: . local
Yep, kibitzing again X Strike Force SVN Repository Admin [EMAIL PROTECTED] writes: +will have to do so by hand (with \(oqinvoke-rc.d restart xdm\(cq, or by I believe you have restart and xdm swapped (but xfs and restart in the correct order below). -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: X Strike Force XFree86 SVN commit: r1195 - trunk/debian
X Strike Force SVN Repository Admin [EMAIL PROTECTED] writes: +environments where lixbext-dev is not installed, since the Xft1 library ^^ *cough* -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Bug#215831: CPU Detections code still buggy for some P4's ?
Michel Dänzer [EMAIL PROTECTED] writes: Not strictly; something like dlopen could also be used. I thought this Technically, yes. was the case here because linking libGL statically doesn't make much sense to me. NCBI links a lot of libraries statically into binaries we distribute to minimize dependencies users will have to install. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Bug#215831: CPU Detections code still buggy for some P4's ?
Michel Dänzer [EMAIL PROTECTED] writes: Then I don't understand why you link GTK dynamically though. Hm, yeah, that does seem backwards; I'm not sure why it worked out that way. The libGL ABI is very stable, but the implementations are platform specific; this binary won't be capable of using direct rendering with nVidia cards, e.g., and even with the cards supported by free DRI drivers, direct rendering will only work if the user has those drivers installed, in which case he is very likely to have libGL as well. Probably whoever made that binary (not my doing, I can assure you) was unaware of this. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Bug#215831: CPU Detections code still buggy for some P4's ?
Christian Guggenberger [EMAIL PROTECTED] writes: Today, I stumpled upon on a software called Cn3D - downloaded from ftp://ftp.ncbi.nih.gov/cn3d/Cn3D-4.1.Linux.tar.gz . This binary is statically linked against an old version of libGL that evidently had buggy CPU detection code; please file a bug with NCBI. FWIW, you can find Cn3D 3.0 in the ncbi-tools-x11 package. I eventually plan to package the NCBI C++ Toolkit, complete with a newer Cn3D, but can't commit to doing so anytime soon. (See http://bugs.debian.org/150636 and http://bugs.debian.org/225651 .) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Bug#215831: CPU Detections code still buggy for some P4's ?
[Oops, I originally sent this directly to debian-x by mistake. Resending to the correct addresses.] Christian Guggenberger [EMAIL PROTECTED] writes: Today, I stumpled upon on a software called Cn3D - downloaded from ftp://ftp.ncbi.nih.gov/cn3d/Cn3D-4.1.Linux.tar.gz . This binary is statically linked against an old version of libGL that evidently had buggy CPU detection code; please file a bug with NCBI. FWIW, you can find Cn3D 3.0 in the ncbi-tools-x11 package. I eventually plan to package the NCBI C++ Toolkit, complete with a newer Cn3D, but can't commit to doing so anytime soon. (See http://bugs.debian.org/150636 and http://bugs.debian.org/225651 .) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Bug#215831: CPU Detections code still buggy for some P4's ?
Christian Guggenberger [EMAIL PROTECTED] writes: Thanks for clarification, Aaron! No problem. I had some (private) discussion with Michel Dänzer about this issue. After thinking more about this, I supposed the problem to be in a buggy statically linked in libGL, as well. For the record, you can use ldd to determine a binary's dynamic dependencies; anything it doesn't list is necessarily static. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: X Strike Force XFree86 SVN commit: r1134 - trunk/debian
X Strike Force SVN Repository Admin [EMAIL PROTECTED] writes: --- trunk/debian/xlibs.bug2004-03-05 01:24:14 UTC (rev 1133) +++ trunk/debian/xlibs.bug2004-03-05 02:49:28 UTC (rev 1134) @@ -7,9 +7,8 @@ if [ -n $XFREE86_LOGS ]; then for LOG in $XFREE86_LOGS; do if [ -f $LOG ]; then -printf Keyboard-related contents of XFree86 X server log file\n \ - 3 -printf %s:\n $LOG 3 +printf Keyboard-related contents of XFree86 X server log \ + file\n%s:\n $LOG 3 egrep -5i '(keyboard|xkb|kbd)' $LOG 3 printf \n 3 fi As far as I can tell, the previous usage was correct (despite having long lines), and this change *introduces* a second format-string argument. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Bug#233707: xbase-clients: Cannot change font for xclock
Hugo Haas [EMAIL PROTECTED] writes: I have a very similar issue. I can change the background and foreground, but not the font: xclock -digital -fg cyan -bg black -update 1 -geometry +0-0 -fn fixed All of those arguments are taken into account except the -fn one. Trying to set the font with Xresources doesn't work better. I have found with some help from editres that it now only responds to the face resource or the corresponding -fa flag (a change that seems to be undocumented); on my desktop, XClock*face: fixed-9:width=semicondensed yields the same font I got with XClock*font: fixed under 4.2.1. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Bug#234320: xbase-clients: [glxinfo] missing libXxf86vm.so.1
Nik A. Melchior [EMAIL PROTECTED] writes: Note the last line of ldd: Libraries listed after libc are almost always indirect dependencies. In this case, I suspect the culprit to be your unofficial libgl package: ii xlibmesa-gl1-dri-trunk [x 2003.10.05-2 Mesa 3D graphics library [DRI trun -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
