Bug#235701: Norton AntiVirus detected a virus in a message you sent. The inf ected attachment was deleted.
Recipient of the infected attachment: Clienti GeniaLLOYD\Posta in arrivo Subject of the message: Re: A!p$ghsa One or more attachments were deleted Attachment details03.zip was Deleted for the following reasons: Virus [EMAIL PROTECTED] was found. Virus [EMAIL PROTECTED] was found in data.rtf .scr. <>
Bug#273655: xserver-xfree86: [ati/radeon] blender crash
Package: xserver-xfree86 Version: 4.3.0.dfsg.1-4 Severity: normal Hello here is my lspci: :00:00.0 Host bridge: Intel Corp. 82855PM Processor to I/O Controller (rev 03) :00:01.0 PCI bridge: Intel Corp. 82855PM Processor to AGP Controller (rev 03) :00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) :00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) :00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) :00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 EHCI Controller (rev 01) :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 81) :00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 01) :00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage Controller (rev 01) :00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) :00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) :00:1f.6 Modem: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01) :01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] :02:00.0 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01) :02:00.1 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01) :02:08.0 Ethernet controller: Intel Corp. 82801BD PRO/100 VE (MOB) Ethernet Controller (rev 81) when I started Blender and tried to render a scene it crashed with: blender-bin: radeon_vtxfmt.c:1061: radeonVtxfmtUnbindContext: Assertion `vb.context == ctx' failed. it seems that this bug was solve in xfree4.4 http://bugs.xfree86.org/show_bug.cgi?id=1113 is it possible to backport the patch into xfree4.3 thanks -- Package-specific info: -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] Versions of packages xserver-xfree86 depends on: ii debconf [debconf-2.0] 1.4.30.5 Debian configuration management sy ii libc6 2.3.2.ds1-16 GNU C Library: Shared libraries an ii xserver-common4.3.0.dfsg.1-4 files and utilities common to all ii zlib1g1:1.2.1.1-7compression library - runtime -- debconf information: xserver-xfree86/config/device/identifier: Generic Video Card xserver-xfree86/config/monitor/screen-size: 17 inches (430 mm) xserver-xfree86/config/device/use_fbdev: * xserver-xfree86/config/monitor/selection-method: Advanced xserver-xfree86/config/doublequote_in_string_error: shared/default-x-server: xserver-xfree86 xserver-xfree86/config/inputdevice/mouse/emulate3buttons: true xserver-xfree86/config/device/bus_id: * xserver-xfree86/config/inputdevice/keyboard/layout: ca_enhanced * xserver-xfree86/config/monitor/horiz-sync: 28-50 xserver-xfree86/config/monitor/identifier: Generic Monitor * shared/no_known_x-server: xserver-xfree86/autodetect_mouse: true xserver-xfree86/config/device/video_ram: xserver-xfree86/config/monitor/mode-list: 1280x960 @ 60Hz * xserver-xfree86/config/monitor/lcd: true xserver-xfree86/config/inputdevice/keyboard/internal: * xserver-xfree86/config/inputdevice/keyboard/rules: xfree86 xserver-xfree86/multiple_possible_x-drivers: * xserver-xfree86/config/inputdevice/keyboard/model: pc105 xserver-xfree86/config/write_dri_section: true * xserver-xfree86/config/device/driver: ati * xserver-xfree86/config/monitor/vert-refresh: 43-75 * xserver-xfree86/config/display/default_depth: 24 xserver-xfree86/config/inputdevice/mouse/zaxismapping: true * xserver-xfree86/config/display/modes: 1024x768, 800x600, 640x480 xserver-xfree86/config/device/bus_id_error: xserver-xfree86/config/modules: GLcore, bitmap, dbe, ddc, dri, extmod, freetype, glx, int10, record, speedo, type1, vbe * xserver-xfree86/config/inputdevice/keyboard/options: xserver-xfree86/config/nonnumeric_string_error: * xserver-xfree86/config/inputdevice/mouse/protocol: PS/2 shared/multiple_possible_x-servers: xserver-xfree86/config/null_string_error: xserver-xfree86/config/monitor/range_input_error: * xserver-xfree86/autodetect_video_card: true * xserver-xfree86/config/inputdevice/keyboard/variant: * xserver-xfree86/config/inputdevice/mouse/port: /dev/psaux xserver-xfree86/config/write_files_section: true xserver-xfree86/autodetect_monitor: true
Bug#269025: new nv driver that should fix Xv extensions: please test!
On Fri, Sep 24, 2004 at 11:05:42AM +0200, Fabio Massimo Di Nitto <[EMAIL PROTECTED]> wrote: > Lucas Nussbaum wrote: > | On Wed, Sep 22, 2004 at 12:02:42PM +0200, Fabio Massimo Di Nitto > <[EMAIL PROTECTED]> wrote: > | > |>Hi guys, > |>this is my last desperate attempt to fix this Xv extensions issue. > |> > |>Test in the usual way and let me know.. > | > | > | Sorry, it still doesn't work with mplayer -vo xv. mplayer -vo > xv:port=54 works though. > > Was the mplayer -vo xv:port=54 option working before upgrading to 7+SVN? Yes. We found this option during a debugging session on IRC, if you remember. -- | Lucas Nussbaum | [EMAIL PROTECTED][EMAIL PROTECTED]GPG: 1024D/023B3F4F | | jabber: [EMAIL PROTECTED] http://www.lucas-nussbaum.net | | fingerprint: 075D 010B 80C3 AC68 BD4F B328 DA19 6237 023B 3F4F |
Bug#271235: Starting xine and mplayer makes mplayer work
Fabio Massimo Di Nitto wrote: Xavier Bestel wrote: | Le dim 26/09/2004 à 17:07, Fabio Massimo Di Nitto a écrit : | | |>I have been discussing this issue with other people. We believe, at this |>point in time, that the bug is in mplayer since all the others players |>work fine at the first shot. But there are no doubts that the changes to |>the driver (that now supports much more hardware) have introduced this |>change. | | | One thing that may help: mplayer uses AUTOPAINT (the Xv window is | painted with the transparent color automatically) whereas xine paints | the window itself. Maybe just the AUTOPAINT method is broken in the | driver, i.e. the drivers paints the window with the wrong color. | | HTH, | | Xav This is a really great catch! Please guys.. another round of tests. New driver is up here: http://people.no-name-yet.com/~fabbione/nv/i386/ You should know the drill by now. Hello Fabio, the new driver works with both 1-7 and 1-7+SVN! No problems in mplayer whatsoever. Thank you for the work! Andrei -- [EMAIL PROTECTED] # http://movzx.net # ICQ: 52641547 signature.asc Description: OpenPGP digital signature
X Strike Force XFree86 SVN commit: r1871 - in trunk/debian: . patches
Author: fabbione Date: 2004-09-27 14:51:33 -0500 (Mon, 27 Sep 2004) New Revision: 1871 Modified: trunk/debian/CHANGESETS trunk/debian/patches/000_stolen_from_freedesktop.org.diff trunk/debian/patches/911_debian_XF86Config_to_XF86Config-4.diff Log: Re-Add patch headers. Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-09-27 15:47:30 UTC (rev 1870) +++ trunk/debian/CHANGESETS 2004-09-27 19:51:33 UTC (rev 1871) @@ -72,7 +72,7 @@ 1851 Backport nv driver from X.org (merged from people/fabbione/nv-driver-backport) -1867 +1867, 1871 Update Czech debconf template translations (thanks, Miroslav Kure). 1868 Modified: trunk/debian/patches/000_stolen_from_freedesktop.org.diff === --- trunk/debian/patches/000_stolen_from_freedesktop.org.diff 2004-09-27 15:47:30 UTC (rev 1870) +++ trunk/debian/patches/000_stolen_from_freedesktop.org.diff 2004-09-27 19:51:33 UTC (rev 1871) @@ -1,3 +1,23 @@ +$Id$ + +xc/programs/Xserver/hw/xfree86/drivers/chips/ct_driver.c @ 1.3 + * programs/Xserver/hw/xfree86/drivers/chips/ct_driver.c: + (chipsClockSelect), (chipsClockFind), (chipsModeInitHiQV), + (chipsModeInitWingine), (chipsModeInit655xx): + Fixed Segfault on video mode switching when pScrn->currentMode did + not contain a valid mode. +2004-05-24 Egbert Eich <[EMAIL PROTECTED]> + +xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.c +xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.h +xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhwstub.c +xc/programs/Xserver/hw/xfree86/xaa/xaaFallback.c +xc/programs/Xserver/hw/xfree86/xaa/xaaROP.c +xc/programs/Xserver/hw/xfree86/xaa/xaalocal.h +xc/programs/Xserver/hw/xfree86/xaa/xaarop.h +xc/programs/Xserver/hw/xfree86/common/xf86str.h + * Import minimum bits required to compile nv driver from X.org + diff -Naurd xc.orig/programs/Xserver/hw/xfree86/common/xf86str.h xc/programs/Xserver/hw/xfree86/common/xf86str.h --- xc.orig/programs/Xserver/hw/xfree86/common/xf86str.h 2004-09-15 10:05:46.0 + +++ xc/programs/Xserver/hw/xfree86/common/xf86str.h2004-09-15 10:14:05.0 + Modified: trunk/debian/patches/911_debian_XF86Config_to_XF86Config-4.diff === --- trunk/debian/patches/911_debian_XF86Config_to_XF86Config-4.diff 2004-09-27 15:47:30 UTC (rev 1870) +++ trunk/debian/patches/911_debian_XF86Config_to_XF86Config-4.diff 2004-09-27 19:51:33 UTC (rev 1871) @@ -1,3 +1,19 @@ +$Id$ + +[Do not recode this file!] + +Debian preferentially uses the name XF86Config-4 for the XFree86 4.x X +server configuration file. This is for two reasons: + 1) The XF86Config file format changed from XFree86 3.x to 4.x, and it's + not a good practice to change the format of a configuration file while + leaving its name the same. + 2) Debian used to support XFree86 3.x and 4.x in parallel, including the + simultaneous installation of XFree86 3.x and 4.x X servers; + consequently, each version of the X server needed to be able to read its + own particular configuration file -- they could not be named the same. + +This patch by Branden Robinson. + diff -Naurd xc.orig/programs/Xserver/hw/xfree86/XF86Config.man xc/programs/Xserver/hw/xfree86/XF86Config.man --- xc.orig/programs/Xserver/hw/xfree86/XF86Config.man 2004-09-15 11:46:54.0 + +++ xc/programs/Xserver/hw/xfree86/XF86Config.man 2004-09-15 11:45:00.0 +
X Strike Force XFree86 SVN property change: propchange - r1851 svn:log
Author: branden Revision: 1851 Property Name: svn:log New Property Value: Add security fix (patch #087). Resolves the following issues: + CAN-2004-0687: stack overflows in libXpm + CAN-2004-0688: integer overflows in libXpm
X Strike Force XFree86 SVN property change: propchange - r1862 svn:log
Author: branden Revision: 1862 Property Name: svn:log New Property Value: Update items for -8 and -9, as discussed on IRC.
X Strike Force XFree86 SVN property change: propchange - r1867 svn:log
Author: branden Revision: 1867 Property Name: svn:log New Property Value: Backport nv driver from X.Org CVS (merged from people/fabbione/nv-driver-backport).
X Strike Force XFree86 SVN property change: propchange - r1869 svn:log
Author: branden Revision: 1869 Property Name: svn:log New Property Value: Add bug-closer for #272493 (libXpm vulnerabilities). (cosmetic) Fix indentation of nv driver bug-closers.
X Strike Force XFree86 SVN property change: propchange - r1871 svn:log
Author: branden Revision: 1871 Property Name: svn:log New Property Value: Fix regression in r1867 that clobbered patch annotations.
X Strike Force XFree86 SVN commit: r1872 - in trunk/debian: . patches
Author: branden Date: 2004-09-27 15:48:55 -0500 (Mon, 27 Sep 2004) New Revision: 1872 Modified: trunk/debian/CHANGESETS trunk/debian/patches/000_stolen_from_HEAD_nv_driver.diff Log: Add annotations to nv driver backport from X.Org CVS. Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-09-27 19:51:33 UTC (rev 1871) +++ trunk/debian/CHANGESETS 2004-09-27 20:48:55 UTC (rev 1872) @@ -72,7 +72,7 @@ 1851 Backport nv driver from X.org (merged from people/fabbione/nv-driver-backport) -1867, 1871 +1867, 1871, 1872 Update Czech debconf template translations (thanks, Miroslav Kure). 1868 Modified: trunk/debian/patches/000_stolen_from_HEAD_nv_driver.diff === --- trunk/debian/patches/000_stolen_from_HEAD_nv_driver.diff2004-09-27 19:51:33 UTC (rev 1871) +++ trunk/debian/patches/000_stolen_from_HEAD_nv_driver.diff2004-09-27 20:48:55 UTC (rev 1872) @@ -1,3 +1,15 @@ +$Id$ + +Backport nv driver from X.Org CVS as of 2004-09-15. + +* Removed 2 references to XORG_VERSION_CURRENT since it is not defined. + +Also see patch #000_stolen_from_freedesktop.org.diff and +#030_Xserver_and_driver_region_primitive_fixups for further changes that +allow this patch to build. + +This patch backported by Fabio Massimo Di Nitto. + diff -Naurd xc.orig/programs/Xserver/hw/xfree86/drivers/nv/Imakefile xc/programs/Xserver/hw/xfree86/drivers/nv/Imakefile --- xc.orig/programs/Xserver/hw/xfree86/drivers/nv/Imakefile 2003-02-17 17:06:43.0 + +++ xc/programs/Xserver/hw/xfree86/drivers/nv/Imakefile2004-09-15 08:16:34.0 +
X Strike Force XFree86 SVN commit: r1873 - in trunk/debian: . patches
Author: branden Date: 2004-09-27 15:53:22 -0500 (Mon, 27 Sep 2004) New Revision: 1873 Modified: trunk/debian/CHANGESETS trunk/debian/patches/315_arm_is_not_x86_and_has_no_vga.diff Log: Set svn:keywords property to "Id" in patch file that was missing it (the only one so afflicted, at present). Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-09-27 20:48:55 UTC (rev 1872) +++ trunk/debian/CHANGESETS 2004-09-27 20:53:22 UTC (rev 1873) @@ -9,7 +9,7 @@ files anywhere.) Miscellaneous cosmetic fixes. -1811, 1812, 1815, 1816, 1828, 1829, 1830, 1842, 1846, 1869 +1811, 1812, 1815, 1816, 1828, 1829, 1830, 1842, 1846, 1869, 1873 Update Danish debconf template translations (thanks, Claus Hindsgaul). 1806 Property changes on: trunk/debian/patches/315_arm_is_not_x86_and_has_no_vga.diff ___ Name: svn:keywords + Id
X Strike Force XFree86 SVN commit: r1874 - trunk/debian
Author: branden Date: 2004-09-27 16:28:06 -0500 (Mon, 27 Sep 2004) New Revision: 1874 Modified: trunk/debian/CHANGESETS trunk/debian/changelog Log: (cosmetic) Resync changelog and CHANGESETS files with each other and with commit logs. Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-09-27 20:53:22 UTC (rev 1873) +++ trunk/debian/CHANGESETS 2004-09-27 21:28:06 UTC (rev 1874) @@ -9,7 +9,7 @@ files anywhere.) Miscellaneous cosmetic fixes. -1811, 1812, 1815, 1816, 1828, 1829, 1830, 1842, 1846, 1869, 1873 +1811, 1812, 1815, 1816, 1828, 1829, 1830, 1842, 1846, 1869, 1873, 1874 Update Danish debconf template translations (thanks, Claus Hindsgaul). 1806 @@ -66,15 +66,38 @@ cosmetic issues in recent translation updates. 1844 -Security update. Resolves the following issues: -CAN-2004-0687: stack overflows in libXpm -CAN-2004-0688: integer overflows in libXpm +Security update (patch #087). Resolves the following issues: ++ CAN-2004-0687: stack overflows in libXpm ++ CAN-2004-0688: integer overflows in libXpm +(Closes: #272493) 1851 -Backport nv driver from X.org (merged from people/fabbione/nv-driver-backport) +Update nv driver and some support code, and grab an XVideo bugfix from +X.Org CVS as of 2004-09-15: ++ Update 000_post430.diff: + - Drop nv_setup.c bits. ++ Update 000_stolen_from_HEAD.diff: + - Include xf86xv.c Xv fix for little-endian machines. ++ Update 000_stolen_from_HEAD_nv_driver.diff: + - Full nv driver from X.org. + - Removed 2 references to XORG_VERSION_CURRENT since it is not defined. ++ Update 000_stolen_from_freedesktop.org.diff: + - Add xaa bits required to compile the new nv driver. + - Add fbdevhw bits required to compile the new nv driver. ++ Update 030_Xserver_and_driver_region_primitive_fixups.diff: + - REGION_EQUAL backport from X.org. + - Fix call to REGION_EQUAL in Xv autopaint initialization error +introduced in 4.3.0.dfsg.1-7. ++ Drop 098_nv_xvideo_fullscreen_fix.diff: + - Now included upstream. ++ Rediff 911_debian_XF86Config_to_XF86Config-4.diff. ++ Update MANIFEST and xserver-xfree86.install files to reflect the new + riva128.o submodule. +(Closes: #269025, #268759, #271235, #270228, #271071, #270714) 1867, 1871, 1872 Update Czech debconf template translations (thanks, Miroslav Kure). +(Closes: #273516) 1868 vim:set ai et sts=4 sw=4 tw=80: Modified: trunk/debian/changelog === --- trunk/debian/changelog 2004-09-27 20:53:22 UTC (rev 1873) +++ trunk/debian/changelog 2004-09-27 21:28:06 UTC (rev 1874) @@ -46,19 +46,17 @@ * Create debian/tmp/usr/X11R6/lib/X11/doc when NOT_BUILDING_XFREE86_X_SERVER is defined. Fixes FTBFS on s390. - * Security update. Resolves the following issues: + * Security update (patch #087). Resolves the following issues: + CAN-2004-0687: stack overflows in libXpm + CAN-2004-0688: integer overflows in libXpm -+ Add debian/patches/087_SECURITY_libXpm_vulnerabilities.diff (Closes: #272493) - * Update nv driver from X.org: -+ Update MANIFEST and xserver-xfree86.install files to reflect the new - riva128.o submodule. + * Update nv driver and some support code, and grab an XVideo bugfix from +X.Org CVS as of 2004-09-15: + Update 000_post430.diff: - Drop nv_setup.c bits. + Update 000_stolen_from_HEAD.diff: - - Include xf86xv.c Xv fix for little endian machines. + - Include xf86xv.c Xv fix for little-endian machines. + Update 000_stolen_from_HEAD_nv_driver.diff: - Full nv driver from X.org. - Removed 2 references to XORG_VERSION_CURRENT since it is not defined. @@ -72,6 +70,8 @@ + Drop 098_nv_xvideo_fullscreen_fix.diff: - Now included upstream. + Rediff 911_debian_XF86Config_to_XF86Config-4.diff. ++ Update MANIFEST and xserver-xfree86.install files to reflect the new + riva128.o submodule. (Closes: #269025, #268759, #271235, #270228, #271071, #270714) * Update Czech debconf template translations (thanks, Miroslav Kure).
X Strike Force XFree86 SVN commit: r1876 - in trunk/debian: . patches
Author: barbier
Date: 2004-09-27 16:54:08 -0500 (Mon, 27 Sep 2004)
New Revision: 1876
Modified:
trunk/debian/CHANGESETS
trunk/debian/patches/099z_xkb_fix_rules_xfree86.diff
Log:
tr_f is both an old style layout and a variant of a 'tr' new style
layout. The latter is preferred over the former, so revert the
bogus change in rules/xfree86.xml.
Modified: trunk/debian/CHANGESETS
===
--- trunk/debian/CHANGESETS 2004-09-27 21:52:00 UTC (rev 1875)
+++ trunk/debian/CHANGESETS 2004-09-27 21:54:08 UTC (rev 1876)
@@ -47,7 +47,7 @@
altwin:meta_hyper with the correct names altwin:super_win and
altwin:hyper_win. (Closes: #271259)
+ rules/xfree86.{lst,xml}: Synchronize these files.
-1822, 1825, 1826
+1822, 1825, 1826, 1876
Add FAQ entry: My keyboard configuration worked with XFree86 4.2; why is
it messed up now? (Closes: #259740)
Modified: trunk/debian/patches/099z_xkb_fix_rules_xfree86.diff
===
--- trunk/debian/patches/099z_xkb_fix_rules_xfree86.diff2004-09-27
21:52:00 UTC (rev 1875)
+++ trunk/debian/patches/099z_xkb_fix_rules_xfree86.diff2004-09-27
21:54:08 UTC (rev 1876)
@@ -246,34 +246,6 @@
it
Italian
италианска
-@@ -2085,16 +2160,17 @@
- турска
- Турецкая
-
--
--
--
--tr_f
--Turkish (F)
--турска (F)
--Турецкая (F)
--
--
--
-+
-+
-+
-+
-+tr_f
-+tr_f
-+Turkish (F)
-+турска (F)
-+Турецкая (F)
-+
-+
-
-
-
@@ -2168,52 +2244,6 @@
X Strike Force XFree86 SVN commit: r1877 - in trunk/debian: . patches
Author: branden Date: 2004-09-27 17:15:25 -0500 (Mon, 27 Sep 2004) New Revision: 1877 Modified: trunk/debian/TODO trunk/debian/patches/000_stolen_from_HEAD.diff Log: Add item which unfortunately blocks the release of -8. Modified: trunk/debian/TODO === --- trunk/debian/TODO 2004-09-27 21:54:08 UTC (rev 1876) +++ trunk/debian/TODO 2004-09-27 22:15:25 UTC (rev 1877) @@ -14,6 +14,14 @@ scheduled. However, the package release manager can put an explicit freeze on those by marking the package version section accordingly. +4.3.0.dfsg.1-8 +-- +* Determine the copryright-status and licensing of the little-endian fix to + xf86xv.c (revision 1.38) in 000_stolen_from_HEAD.diff; or obtain the same fix + from a source not contaminated by the XFree86 1.1 license (perhaps the author, + Rene Rabe); or have the patch clean-room reimplemented (it's fairly trivial) + and place the patch in an appropriate file. + 4.3.0.dfsg.1-9 -- Modified: trunk/debian/patches/000_stolen_from_HEAD.diff === --- trunk/debian/patches/000_stolen_from_HEAD.diff 2004-09-27 21:54:08 UTC (rev 1876) +++ trunk/debian/patches/000_stolen_from_HEAD.diff 2004-09-27 22:15:25 UTC (rev 1877) @@ -151,8 +151,12 @@ xc/programs/Xserver/hw/xfree86/common/xf86xv.c @ 1.35 156. Fix precision problems in xf86XVClipVideoHelper [...] (Marc La France). -xc/programs/Xserver/hw/xfree86/common/xf86xv.c @ 1.35 + diff -r 1.37:1.38 - Fix general Xv extensions on little endian machine. +xc/programs/Xserver/hw/xfree86/common/xf86xv.c @ 1.38 + 808. Fix big-endian typo in xf86CopyYUV12ToPacked (#6131, Rene Rebe). + [Marc Aurele La France] +[XXX: This patch was applied to XFree86 CVS on 2004-02-19, after the +XFree86 1.1 relicensing. We need to determine the provenance of this +patch.] xc/programs/xdm/access.c @ 3.14 Fix parsing of IPv4 host names in Xaccess (Chisato Yamauchi). [David Dawes]
Bug#272493: libxpm4 security problem
On Tue, Sep 21, 2004 at 08:44:10AM +0200, Moritz Mühlenhoff wrote: > Branden Robinson wrote: > > (In the future, please don't file bugs against unsupported or unreleased > > versions of Debian packages. I have no idea what libxpm4 > > "4.3.0-0pre1v5.49.200406160839" is. Whoever shipped that package is the > > proper recipient of your bug report.) > > It's an internal versioning scheme, sorry for the confusion. I checked > it against sid, although it has been sent off a machine running the > above version. You can edit the reported version number, of course. I'm just trying to reinforce a good habit -- I'm aware that pretty much every version of libXpm ever released has this flaw. However, many bugs reported against XFree86 don't have such universal applicability, so I attempt to reinforce sound bug-reporting practices. :) -- G. Branden Robinson|It may be difficult to to determine Debian GNU/Linux |where religious beliefs end and [EMAIL PROTECTED] |mental illness begins. http://people.debian.org/~branden/ |-- Elaine Cassel signature.asc Description: Digital signature
Bug#234785: libxrender1: quite strange dependencies, also
Package: libxrender1 Version: 0.8.3-5 Followup-For: Bug #234785 it has also some quite strange dependencies: Depends: libc6 (>= 2.3.2.ds1-4), libx11-6 | xlibs (>> 4.1.0) Conflicts: xlibs (<< 4.3.0) isnt it better to specify Depends: xlibs (>= 4.3.0) instead? Greetings Bernd -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8.1 Locale: LANG=C, LC_CTYPE=en_US.ISO-8859-15 Versions of packages libxrender1 depends on: ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an ii xlibs 4.2.1-12.1 X Window System client libraries -- no debconf information
Bug#264792: installation-reports: Installation report debian sarge installer
[xserver-xfree86: [debconf] information from read-edid not really used for configuration] On Fri, Aug 20, 2004 at 12:50:51AM -0500, Branden Robinson wrote: > You persuaded me on IRC that that's a bad idea, though (at this time, > due to the looming freeze). I'll fix as many of the bugs as I can > without rewriting the script totally. This is one of them. Is this going to be fixed in time for -8? It sure looks like a very valuable thing to have WRT user's experience when installing sarge. thanks, Michael
Bug#264557: xlibs-data: No composition sequences in japanese locale
On Thu, Sep 23, 2004 at 07:33:45AM +0900, Mike Hommey wrote: > Okay, I checked all the "testcases" ; they are all okay, now. And as for > the strange behaviour on the non-fresh account, it was due to the use of > uim-anthy as an input method through XMODIFIERS. > > Thus, closing the bug. > > Thanks. Thank *you* for follwing up! I'm glad to hear the problem is resolved. -- G. Branden Robinson|Ambition: an overmastering desire Debian GNU/Linux |to be vilified by enemies while [EMAIL PROTECTED] |living and ridiculed by friends http://people.debian.org/~branden/ |when dead.-- Ambrose Bierce signature.asc Description: Digital signature
Bug#237877: use DisplaySize to set dpi
On Wed, Sep 22, 2004 at 04:05:12PM -0400, Andrew Pimlott wrote: > > > The patch by Gus (if you reverse the second half) looks like an > > > expedient solution, unless you think it will confuse people. > > > > That just changes one hard-coded default for another. I think -softdpi > > would be superior to both. > > Choosing a specific dpi with no knowledge of the display is (finally) > becoming an anachronism, so I don't see the harm in using a hard-coded > hack for this purpose. IOW, I think it should be viewed as a > last-ditch, can't possibly be right but better than nothing, fallback; > and for that, hard-coding is fine. If anyone needs to override it, > there is a much better mechanism: the DisplaySize parameter. The problem with that is that it is XFree86-specific. There are more X servers in the world than just XFree86's. > Besides, I think we're close to being able to do a better job with > debconf. I notice you already ask for screen size in some cases, and > I'm guessing EDID gives it to you when it works. It seems that all you > need to do is have dexconf set DisplaySize, and you can drop -dpi. What > is the obstacle to that? (Well, for the sake of upgraders, you might > want to change the hard-coded default in the X server, so they still > have a fall-back.) You're right. If you look at the package TODO you'll see that further overhaul of the X server debconfage is planned. It's not *quite* as simple as you describe, but it is true that by refactoring the logic of monitor configuration, we could kill more birds with that stone. I expect to be able to work on this in the post-sarge timeframe. If you're interested in helping (whether with code review, testing, or patches), please see: svn://necrotic.deadbeast.net/xfree86/branches/debconf-overhaul/ > Regardless, I'm sure the tide of progress will force you to remove -dpi > soon enough. :-) I can but hope. :) -- G. Branden Robinson| Eternal vigilance is the price of Debian GNU/Linux | liberty. [EMAIL PROTECTED] | -- Wendell Phillips http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#229850: DEFAULT_HORIZ_SYNC and DEFAULT_VERT_REFRESH still ignored (updated patch)
On Thu, Sep 23, 2004 at 10:32:52PM -0400, Jay Berkenbilt wrote: > Reading through the code, I have a couple of quick comments. I'll > also test on a few machines and post additional comments even if they > are limited to saying that it works well. > > * My guess is that several people out there have monitors whose >refresh rates are suboptimal but whose rates will not get fixed >during the upgrade because there are already answers in debconf to >some questions. If my understanding is correct, this could be >partially mitigated by changing the names of the some of the >variables. Yikes; I think *that* is a really bad idea. It's a kludge. >I haven't actually looked to see whether this is the case, but it may >be worth considering if it isn't. Stated differently, it may be worth >seeing whether there is something that could make it possible to >automatically fix suboptimal data left over from older versions of the >package. (I'm going to dpkg -P --force-depends xserver-xfree86 and >reinstall just to be sure.) That's difficult. We don't how to recognize "suboptimal" data when we see it. What you consider "suboptimal" may be what the user saw, accepted, and liked. One big challenge in using debconf as I am is that one has to manage up to three sources of information: 1) what is autodetected 2) what the package falls back to when autodetection fails 3) what the user wants The principle of debconf (and configuration in Debian in general) is that 3) should always trump 1) and 2). The thing is, I think debconf was mainly designed for case 2) -- more specifically, for situations where user preferences are all that matter, and "autodetection" is an inapplicable concept. Sometimes the user wants the wrong thing because he or she is unaware that the defaults came from 1). In re-envisioning the X server debconfage for post-sarge, I am considering a design along the lines of: * Dumbing the interaction down to just the setting of parameters. * Providing fallback question defaults to address 2). * Providing user-invisible templates that "shadow" certain questions, which will exist to let autodetection tools poke values into them. We can then allow for competition in the area of configuration frontends. I'd really like to get that mess out of the X server config scripts. This is an area that needs vigorous development, and X server packages -- even after X.Org's much-vaunted "modularization" takes place, are likely going to be big and slow. A X server debconf configurator package can be small and nimble. > * In the Medium monitor selection code, there are 60Hz and 85Hz >choices for 1280x960 but only a 60Hz choice for 1280x1024. >Personally, my eyes hurt looking at any screen whose refresh rate >is less than about 75Hz (which is what motivated me to post this >bug in the first place). I think it would be best if there were a >75Hz rate at all common resolutions. 1280x1024 is the native >resolution on almost all 17" and 19" flat panels, so it is a pretty >important one to have in there. There is also no option to have >1024x768 at anything higher than 75Hz. I guess, ideally, there >should be a 60Hz, 75Hz, and 85Hz for all resolutions. I agree, but I think you're overlooking the large comment in the code you're talking about. # The mode and range information below is adapted from the built-in # modeline definitions in the XFree86 source tree; specifically # xc/programs/Xserver/hw/xfree86/etc/vesamodes and # xc/programs/Xserver/hw/xfree86/etc/extramodes. The rule of thumb is to # set the sync ranges based on the hsync and vrefresh values used by the # selected mode, plus a little bit of "headroom" to allow other modes to # be used (as long as they don't push the hardware much harder than the # selected one) and a margin of error (e.g., if the video driver or video # card overdrives the monitor just a little bit). I'd supply the choices you're asking for if the built-in mode list supported them. > I should have time in the next day or two to test this on a few different > machines. If I have access to check out from subversion, I'll try > checking out the maintainer scripts and testing with all of them. > Otherwise, I'll just drop this config_monitor into the version in the > current package. (I'm trying to check svn now but alioth is too slow.) Debian's XFree86 SVN repo is not hosted on alioth (fortunately?). It's hosted at necrotic.deadbeast.net. http://necrotic.deadbeast.net/xsf/XFree86/README.txt > I'll try to get back to you after testing on three machines: a laptop > with a Radeon Mobility M6, my desktop machine with a Radeon 9600, and > my work machine with a built-in Intel video. I am no longer using the > Rage Pro card I was using when I posted the original report. I understand. Thanks a lot for your help! -- G. Branden Robinson
Bug#229850: DEFAULT_HORIZ_SYNC and DEFAULT_VERT_REFRESH still ignored (updated patch)
> In re-envisioning the X server debconfage for post-sarge, I am considering > a design along the lines of: > > * Dumbing the interaction down to just the setting of parameters. > * Providing fallback question defaults to address 2). > * Providing user-invisible templates that "shadow" certain questions, which > will exist to let autodetection tools poke values into them. If my understanding is correct (and yours is probably much better than mine), XFree86 4.4.0 (yes, I know about the licensing problems) claims to have an autoconfiguration mechanism, and the X.Org (6.8.1?) forked off (again) of XFree86 pretty late in the pre 4.4.0 days. I wonder whether much of this will just disappear when Debian moves to x.org. (Wishful thinking?) I'm tempted to download Fedora Core 2 or Fedora Core 3 RC 2 (which are both using x.org) and see what their configuration stuff looks like. > Debian's XFree86 SVN repo is not hosted on alioth (fortunately?). It's > hosted at necrotic.deadbeast.net. > > http://necrotic.deadbeast.net/xsf/XFree86/README.txt Yeah, I eventually figured that out ;-) -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Bug#267062: marked as done (xlibs-data: [nls] pl_PL.UTF-8 not really using en_US.UTF-8 Compose map)
Your message dated Mon, 27 Sep 2004 20:19:25 -0500 with message-id <[EMAIL PROTECTED]> and subject line Bug#267062: xlibs: [xkb] wrong Compose file for pl_PL.UTF-8? has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 20 Aug 2004 13:31:27 + >From [EMAIL PROTECTED] Fri Aug 20 06:31:26 2004 Return-path: <[EMAIL PROTECTED]> Received: from chastell.shot.pl [80.55.253.30] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1By9UM-0004Z3-00; Fri, 20 Aug 2004 06:31:26 -0700 Received: by chastell.shot.pl (Postfix, from userid 1000) id 4FBCB3917E; Fri, 20 Aug 2004 15:31:24 +0200 (CEST) Date: Fri, 20 Aug 2004 15:31:24 +0200 From: Shot <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Subject: xlibs: [xkb] wrong Compose file for pl_PL.UTF-8? Message-ID: <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Reportbug-Version: 2.64 Organization: Freelance Shooters X-Operating-System: Debian GNU/Linux, up 35 days, 17:25 User-Agent: Mutt/1.5.6+20040722i Content-Transfer-Encoding: quoted-printable Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2004_03_25 X-Spam-Level: Package: xlibs Version: 4.3.0.dfsg.1-6 Severity: normal Hello. I'm using pl_PL.UTF-8 locale, and would like to be able to type certain characters, like em- and en-dashes, "curly" quotes, ellipsis, etc. I've found out that these characters should be easily obtainable with the compose key, and it seems they are in fact defined properly: [EMAIL PROTECTED]:~$ grep pl /usr/X11R6/lib/X11/locale/compose.dir iso8859-2/Compose pl_PL.ISO8859-2 en_US.UTF-8/Compose pl_PL.UTF-8 iso8859-2/Compose: pl_PL.ISO8859-2 en_US.UTF-8/Compose:pl_PL.UTF-8 [EMAIL PROTECTED]:~$ grep DASH /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose : "=E2=80=93" U2013 # EN DASH : "=E2=80=94" U2014 # EM DASH Yet when I try to input I get the hyphen character right after the second ; it seems that X is using the iso8859-2/Compose mapping instead of en_US.UTF-8/Compose: [EMAIL PROTECTED]:~$ grep " " /usr/X11R6/lib/X11/locale/iso8859-2= /Compose : "\255"hyphen Additionally, thesequence inputs aogonek, so I'm either using ISO-8859-2, -4 or -13 mappings (I'm betting on -2): [EMAIL PROTECTED]:~$ grep -r " " /usr/X11R6/lib/X11/locale/ /usr/X11R6/lib/X11/locale/iso8859-13/Compose: = : "\340"aogonek /usr/X11R6/lib/X11/locale/iso8859-2/Compose:= : "\261"aogonek /usr/X11R6/lib/X11/locale/iso8859-4/Compose:= : "\261"aogonek Is there a way to set X to use the en_US.UTF-8/Compose mappings? Shouldn't this be the default source for pl_PL.UTF-8 locale? (I tried overwriting iso8859-2/Compose with en_US.UTF-8/Compose and it didn't change anything, so I guess the compose mappings must be defined elsewhere as well.) -- Package-specific info: -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.4.18-bf2.4 Locale: LANG=3Dpl_PL.UTF-8, LC_CTYPE=3Dpl_PL.UTF-8 Versions of packages xlibs depends on: ii libice6 4.3.0.dfsg.1-6 Inter-Client Exchange librar= y ii libsm64.3.0.dfsg.1-6 X Window System Session Mana= gement ii libx11-6 4.3.0.dfsg.1-6 X Window System protocol cli= ent li ii libxext6 4.3.0.dfsg.1-6 X Window System miscellaneou= s exte ii libxft1 4.3.0.dfsg.1-6 FreeType-based font drawing = librar ii libxi64.3.0.dfsg.1-6 X Window System Input extens= ion li ii libxmu6 4.3.0.dfsg.1-6 X Window System miscellaneou= s util ii libxmuu1 4.3.0.dfsg.1-6 lightweight X Window System = miscel ii libxp64.3.0.dfsg.1-6 X Window System printing ext= ension ii libxpm4 4.3.0.dfsg.1-6 X pixmap library ii libxrandr24.3.0.dfsg.1-6 X Window System Resize, Rota= te and ii libxt64.3.0.dfsg.1-6 X Toolkit Intrinsics ii libxtrap6 4.3.0.dfsg.1-6 X Wind
Bug#229850: DEFAULT_HORIZ_SYNC and DEFAULT_VERT_REFRESH still ignored (updated patch)
On Sun, Sep 26, 2004 at 05:23:30PM -0400, Jay Berkenbilt wrote: > I should amend slightly what I said before: > > > at the moment, or at least I don't have correct versions. I used > > viewCVS from necrotic.deadbeast.net to grab the latest > > xserver-xfree86.config.in and xserver-xfree86.preinst.in along with > > shell-lib.sh. I reconstructed config and preinst manually by > > I forgot to say that I was on the debconf-overhaul branch. > > I also forgot to say that I had updated these variables as follows: > > SOURCE_VERSION=4.3.0.dfsg.1-7 > OFFICIAL_BUILD=yes > > to make them match the config file that was already there. Yeah, there is no problem with any of the above. > Also, I sent a separate bug report against discover-data about the > fact that my video card seems not to be mapped properly to an X server > or driver. Okay, cool. -- G. Branden Robinson|I must despise the world which does Debian GNU/Linux |not know that music is a higher [EMAIL PROTECTED] |revelation than all wisdom and http://people.debian.org/~branden/ |philosophy. -- Ludwig van Beethoven signature.asc Description: Digital signature
Bug#229850: DEFAULT_HORIZ_SYNC and DEFAULT_VERT_REFRESH still ignored (updated patch)
On Sun, Sep 26, 2004 at 05:01:40PM -0400, Jay Berkenbilt wrote:
> There's at least one bug in configure_monitor that I found during my
> testing. The place where configure_monitor decides to pre-answer the
> selection method with "Advanced" may be wrong. If I leave it as it
> appears in the original file:
>
> db_subst xserver-xfree86/config/monitor/selection-method default
> "Advanced"
>
> then the horiz-sync and vert-refresh debconf items never get set. If
> I change it to this instead:
>
> db_set xserver-xfree86/config/monitor/selection-method "Advanced"
>
> then everything works -- well, at least I get answers to those
> questions in the debconf database.
I cannot at present remember why I used db_subst default instead of the
latter construction. It may have something to do with auto_answer. I'll
review this, and may very well end up following your recommendation.
> I should point out that preinst and config do not appear to be in sync
> at the moment, or at least I don't have correct versions. I used
> viewCVS from necrotic.deadbeast.net to grab the latest
> xserver-xfree86.config.in and xserver-xfree86.preinst.in along with
> shell-lib.sh. I reconstructed config and preinst manually by
> inserting shell-lib.sh at the right place. Upon doing this, I
> observed that there were no meaningful changes in either preinst or
> shell-lib.sh, which was not surprising since they still had an older
> svn revision.
Yeah, those files have not needed to change on the branch.
> Since the overall structure of config changed quite a
> bit, I couldn't just drop configure_monitor in and instead had to use
> the entire new config file.
Yes, I expected you'd have to. I've really pounded the hell out of it.
> For whatever reason, discover decides that the vesa device, rather
> than the ATI device, is the right one for my card. Even with correct
> settings, my monitor refresh rate is at 60Hz with the vesa driver and
> at 75Hz with the ati driver (which works fine as long as I don't load
> radeonfb). I have a Radeon 9600 card.
As I think you have noted elsewhere, this sounds like a discover-data bug.
> Regardless of my DEBIAN_PRIORITY, I end up with a zero-length
> XF86Config file,
Very bad. (I assume you mean XF86Config-4.)
> and I get asked three times (once in config and twice
> in preinst) whether I wish to try hardware autodetection.
Annoying.
> In the end, apt-get install aborts saying that
> xserver-xfree86/config/monitor/horiz-sync is not set and tells me to run
> dpkg-reconfigure xserver-xfree86. Looking at
> /var/log/xserver-xfree86.config.log, I see this:
>
> 2004-09-26 04:36:36 PM-0400 configure_monitor(): using "" selection
> method
>
> which is what made me decide to try the change I described above.
>
> After I make the change, I get:
>
> 2004-09-26 04:42:11 PM-0400 configure_monitor(): using "Advanced" selection
> method
Sounds like you correctly diagnosed and fixed the problem. The challenge
for me now is to figure out if there's still any justification for using
db_subst default. To be honest I'm not sure that even works.
> I'll admit to not having a deep knowledge of debconf, so I'm not sure
> why the original code is wrong. There is a db_get on
> xserver-xfree86/config/monitor/selection-method before the above
> message, but I never see the question.
db_get doesn't ask questions. Only db_input does that. Well, technically,
db_input enqueues a question for asking, and db_go runs the queue.
> In any case, the comment doesn't say that it wants to change the default:
> it says it wants to pre-answer the question, so I think the db_set is
> probably correct.
Probably so.
> I also can't see what in preinst is causing the autodetect_video_card
> question to be asked twice even though we've been through it already
> in config.
Very annoying. Can you please send me your full config log file with the
db_subst->db-set change made?
> The good news is that, if I make the one-line change I made, at least
> I do eventually get an XF86Config-4 that has the correct refresh
> rates.
Okay, so with your one-line change, the only real problems are:
1) discover-data doesn't know about your video card
2) you get nagged to death about autodetecting the video card
Is that right?
> So obviously, there's some more work to do and I don't know how
> much of my testing problems were the result of my trying to cobble
> together configuration files from subversion.
Well, here's one way to find out. I've just merged the latest changes onto
the trunk onto the debconf-overhaul branch, and run a diff between the two
trees:
$ svn diff ${xfree86_svn}trunk ${xfree86_svn}branches/debconf-overhaul |
diffstat
CHANGESETS| 213 ++-
TODO | 300 -
changelog | 108 +
local/dexconf | 27
rules | 11
xserver-xfree86.bug | 16
xserver-xfree86.config.in | 2564 ++
Re: Bug#149631: [ati/atimisc] DoS attack possible when viewing absurdly huge fonts on Mach64 GT rev 65
On Mon, Sep 13, 2004 at 08:25:59PM +0200, Juliusz Chroboczek wrote: > Hi, Branden, how's tricks? > > > > > This issue should hopefully be fixed upstream in 4.3.0. > > > > Is this really the case? If so, this scary bug should be closed. > > In the default configuration, it should no longer apply to Type 1 > fonts. However, it still applies to CIDFonts. > > CIDFonts are history. I recommend that your XF86Config-4 file should > *not* include `Load "type1"', so as to make sure you don't get bitten > by this bug. What rasterizers have replaced type1 in XFree86 4.3.0? -- G. Branden Robinson| What cause deserves following if Debian GNU/Linux | its adherents must bury their [EMAIL PROTECTED] | opposition with lies? http://people.debian.org/~branden/ | -- Noel O'Connor signature.asc Description: Digital signature
X Strike Force XFree86 SVN commit: r1879 - trunk/debian
Author: branden Date: 2004-09-27 21:17:27 -0500 (Mon, 27 Sep 2004) New Revision: 1879 Modified: trunk/debian/TODO Log: Add item. Modified: trunk/debian/TODO === --- trunk/debian/TODO 2004-09-28 01:44:18 UTC (rev 1878) +++ trunk/debian/TODO 2004-09-28 02:17:27 UTC (rev 1879) @@ -26,6 +26,9 @@ -- * Add FAQ entry describing what has become of the XFree86 3.x packages. +* Update xlibs's package description to imply that *no* packages have up-to-date + dependencies on it (xbase-clients does, due to xkbcomp, which is statically + linked against libxkbfile). * Rewrite xserver-xfree86 debconfage. Joey Hess, Eduard Bloch, and David Nusinow have provided good input. + udev users will have "/dev/input/mousen" -- configure that as only mouse
Bug#251088: xdm: remove pam_setcred() call from session.c so libpam-heimdal will work with xdm
On Fri, May 28, 2004 at 07:37:07AM -0400, [EMAIL PROTECTED] wrote: > On Fri, 28 May 2004, Branden Robinson wrote: > > > > I guess we'll need to coordinate application of this fix with the > > heimdal maintainer? > > The package that's affected is libpam-heimdal. The maintainer is > Brian May <[EMAIL PROTECTED]>. I've swapped a couple of emails with him > on other topics; I will try to reach him about this and see what the > relevant mailing lists are. Just checking in after a few months. Have you made any headway on this? -- G. Branden Robinson| There's no trick to being a Debian GNU/Linux | humorist when you have the whole [EMAIL PROTECTED] | government working for you. http://people.debian.org/~branden/ | -- Will Rogers signature.asc Description: Digital signature
Bug#273771: xdm: daemon can hang due to race condition in policy.c:Willing() when trying to run Xwilling sript
Package: xdm
Version: 4.3.0.dfsg.1-7
Severity: normal
Note to self: set submitter to Chip Coldwell <[EMAIL PROTECTED]>
once an ack is recived for this bug.
I don't think there are any security implications to this bug, since
unprivileged users cannot kill the (root-owned) Xwilling process (which is
a script that lives in /etc/X11 on Debian, and is not writable by users).
Since the only people who could use this vector to DoS xdm have root
privileges anyway, this bug merits severity "normal".
For a more direct method of DoSsing xdm as root, try:
kill -STOP $(pidof xdm)
:-/
- Forwarded message from Chip Coldwell <[EMAIL PROTECTED]> -
From: Chip Coldwell <[EMAIL PROTECTED]>
To: Branden Robinson <[EMAIL PROTECTED]>
Cc: Debian X Strike Force
Subject: xdm race condition
Date: Thu, 24 Jun 2004 13:58:06 -0400 (EDT)
Message-ID: <[EMAIL PROTECTED]>
X-Mailing-List: archive/latest/19682
X-Spam-Status: No, hits=-5.0 required=4.0 tests=LDOSUBSCRIBER autolearn=no
version=2.63-lists.debian.org_2004_06_20_05
I found another xdm bug. This time it's a race condition in
xc/programs/xdm/policy.c:Willing
around line numbers 140--145, which reads
if ((fd = popen(willing, "r")))
{
char *s = NULL;
while(!(s = fgets(statusBuf, 256, fd)) && errno == EINTR)
;
Here's the problem. The "popen" call creates a child process and a
pipe to communicate with it. If the child process exits during the
"fgets" call without generating any output, the parent process
receives SIGCHLD and the read system call gets interrupted. Therefore
errno == EINTR, and since the child has exited the pipe never returns
any data. xdm goes into an infinite loop. I think the problem is
that fgets doesn't reset errno to zero; we have to do that manually.
The fix is the trivial patch attached to this email.
(The child process is the "Xwilling" script; in the case of the default
Debian configuration it is
"su nobody -c /usr/X11R6/lib/X11/xdm/Xwilling")
Chip
--
Charles M. "Chip" Coldwell
System Administrator
Harvard Physics Department
617-495-3388
Content-Description: xdm race condition fix
--- xc/programs/xdm/policy.c~ 2002-12-07 15:31:04.0 -0500
+++ xc/programs/xdm/policy.c2004-06-24 09:56:19.0 -0400
@@ -140,8 +140,9 @@
if ((fd = popen(willing, "r")))
{
char *s = NULL;
+ errno = 0;
while(!(s = fgets(statusBuf, 256, fd)) && errno == EINTR)
- ;
+ errno = 0;
if (s && strlen(statusBuf) > 0)
statusBuf[strlen(statusBuf)-1] = 0; /* chop newline */
else
- End forwarded message -
--
G. Branden Robinson| Life is what happens to you while
Debian GNU/Linux | you're busy making other plans.
[EMAIL PROTECTED] | -- John Lennon
http://people.debian.org/~branden/ |
signature.asc
Description: Digital signature
Bug#252895: /usr/X11R6/bin/xfontsel: [xfontsel] crash
[replying to submitter and two people who have also seen this bug] On Thu, Jul 15, 2004 at 10:45:01PM +0200, Markus Schaber wrote: > Well, currently, I cannot reproduce the font match number (as I recently > deinstalled xfs - it seems that most fonts were served twice, by xfs and > the X server itself). Now, "xlsfonts | wc -l" tell me I have 15285 > fonts, while xfontsel has 20889 matches, which still seems to be a lot. > > It still crashes when selecting monospaced. So this is independent from > the possible 32767 issue. On Sat, Jul 24, 2004 at 02:42:24PM -0700, Vassilis Papadimos wrote: > I can reproduce this bug, both for xfontsel and emacs. Removing > msttcorefonts doesn't seem to make a difference. xlsfonts reports > 7258 fonts, xfontsel reports 9930 names. > > One potentially interesting data point is that, for me, this only happens > for locales other than C or en_US (i.e. "LC_ALL=C xfontsel" works, but > "LC_ALL=el_GR xfontsel" does not). On Tue, Jul 27, 2004 at 04:11:03PM +0200, François Girault wrote: > Hi, I've got the same problem with emacs since last monday but no > problems with xfontsel. > The same problem appears with sylpheed-claws and other programs. Let's try to nail down if these are all really the same problem. Mr. Schaber, Mr. Girault: Does the problem go away if you invoke xfontsel as follows?: LC_ALL=C xfontsel ? -- G. Branden Robinson|You can have my PGP passphrase when Debian GNU/Linux |you pry it from my cold, dead [EMAIL PROTECTED] |brain. http://people.debian.org/~branden/ |-- Adam Thornton signature.asc Description: Digital signature
Bug#254563: xsm: does not see any clients
On Fri, Jul 09, 2004 at 09:26:33AM +0200, Yann Dirson wrote: > On Thu, Jul 08, 2004 at 01:19:30PM -0500, Branden Robinson wrote: > > Can you please provide some more information about this problem? > > > > 1) Can you determine at least a ballpark figure of when this functionality > >broke? The XSF hasn't been messing with session management, so my best > >guess would be that this broke upstream in 4.3.0. > > I'm suspecting something like this, yes. > > >The last 4.2.1 > >packages are available for most architectures at snapshot.debian.net. > > > > http://snapshot.debian.net/archive/2004/02/14/debian/pool/main/x/xfree86/ > > > >Please downgrade to that version (or install it in a chroot). > > I'll try this, but will not have time this next week. I haven't had more time to look into this yet -- sorry. Have you had a chance to, by trying some 4.2.1 packages? > > 2) Can you provide a recipe for reproducing this problem? I have to admit > >I don't use xsm myself. > > Set your .xsession or whatever so that it runs eg. fvwm in the > backround, then xsm as session program. > > Then when you run session-aware programs, you should see them in the > window open when you click on "client list" in the xsm button. This > includes at least xterm, xemacs, galeon, xchat - I guess all gnome and > kde programs should be seen as well. I will try to give this shot. I apologize, it's just that many "more important" bugs have piled up ahead of this one. -- G. Branden Robinson| When I die I want to go peacefully Debian GNU/Linux | in my sleep like my ol' Grand [EMAIL PROTECTED] | Dad...not screaming in terror like http://people.debian.org/~branden/ | his passengers. signature.asc Description: Digital signature
Processed: Re: Bug#255439: Bug#255689: Bug#255439: d-i report
Processing commands for [EMAIL PROTECTED]: > clone 255439 -1 -2 Bug#255439: d-i report Bug 255439 cloned as bugs 273774-273775. > submitter -1 Sven Luther <[EMAIL PROTECTED]> Bug#273774: d-i report Changed Bug submitter from [EMAIL PROTECTED] to Sven Luther <[EMAIL PROTECTED]>. > submitter -2 Sven Luther <[EMAIL PROTECTED]> Bug#273775: d-i report Changed Bug submitter from [EMAIL PROTECTED] to Sven Luther <[EMAIL PROTECTED]>. > retitle -1 xserver-xfree86: [debconf] set subarchitecture-based Macintosh > defaults for keyboard on m68k and powerpc Macs Bug#273774: d-i report Changed Bug title. > retitle -2 xserver-xfree86: [debconf] permit blank answers for monitor sync > ranges Bug#273775: d-i report Changed Bug title. > reassign -1 xserver-xfree86 Bug#273774: xserver-xfree86: [debconf] set subarchitecture-based Macintosh defaults for keyboard on m68k and powerpc Macs Bug reassigned from package `installation-reports' to `xserver-xfree86'. > reassign -2 xserver-xfree86 Bug#273775: xserver-xfree86: [debconf] permit blank answers for monitor sync ranges Bug reassigned from package `installation-reports' to `xserver-xfree86'. > severity -1 wishlist Bug#273774: xserver-xfree86: [debconf] set subarchitecture-based Macintosh defaults for keyboard on m68k and powerpc Macs Severity set to `wishlist'. > severity -2 wishlist Bug#273775: xserver-xfree86: [debconf] permit blank answers for monitor sync ranges Severity set to `wishlist'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Processed: submitter 273771
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.8.4 > submitter 273771 Chip Coldwell <[EMAIL PROTECTED]> Bug#273771: xdm: daemon can hang due to race condition in policy.c:Willing() when trying to run Xwilling sript Changed Bug submitter from Branden Robinson <[EMAIL PROTECTED]> to Chip Coldwell <[EMAIL PROTECTED]>. > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Processed: submitter 258612
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.8.4 > submitter 258612 TJ <[EMAIL PROTECTED]> Bug#258612: xlibs: want gb variant of dvorak and pc/dvorak Changed Bug submitter from TJ <[EMAIL PROTECTED]> to TJ <[EMAIL PROTECTED]>. > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Processed: Re: Bug#258960: XF86Config-4 does not contain TrueType in "Files" Section
Processing commands for [EMAIL PROTECTED]: > severity 250999 wishlist Bug#250999: xserver-xfree86: TrueType font paths missing from default XF86Config-4 Severity set to `wishlist'. > retitle 250999 xserver-xfree86: please add TrueType font path to default > XF86Config-4 Bug#250999: xserver-xfree86: TrueType font paths missing from default XF86Config-4 Changed Bug title. > retitle 258960 xserver-xfree86: please add TrueType font path to default > XF86Config-4 Bug#258960: XF86Config-4 does not contain TrueType in "Files" Section Changed Bug title. > merge 250999 258960 Bug#250999: xserver-xfree86: please add TrueType font path to default XF86Config-4 Bug#258960: xserver-xfree86: please add TrueType font path to default XF86Config-4 Merged 250999 258960. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Processed: Re: Bug#259632: xkb: Unitek KB-2125 multimedia keys not supported
Processing commands for [EMAIL PROTECTED]: > retitle 259632 xlibs: want support for Unitek KB-2125 keyboard's multimedia > keys Bug#259632: xkb: Unitek KB-2125 multimedia keys not supported Changed Bug title. > severity 259632 wishlist Bug#259632: xlibs: want support for Unitek KB-2125 keyboard's multimedia keys Severity set to `wishlist'. > tag 259632 + upstream Bug#259632: xlibs: want support for Unitek KB-2125 keyboard's multimedia keys There were no tags set. Tags added: upstream > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#258960: XF86Config-4 does not contain TrueType in "Files" Section
severity 250999 wishlist
retitle 250999 xserver-xfree86: please add TrueType font path to default
XF86Config-4
retitle 258960 xserver-xfree86: please add TrueType font path to default
XF86Config-4
merge 250999 258960
thanks
On Mon, Jul 12, 2004 at 02:25:55PM +0200, Michelle Konzack wrote:
> I have created some xfonts packages for arabic, farsi and hebrew
> from ttf fonts which are located in "/usr/lib/X11/fonts/TrueType"
>
> Installing and all works fine, but the fonts are not accessibel
> because a missinf "FontPath" Entry in
>
> Section "Files"
> FontPath"/usr/lib/X11/fonts/TrueType"
> EndSection
[The following is a form letter.]
Hello,
You recently filed a duplicate bug report against a Debian package; that
is, the problem had already been reported.
While there is often nothing inherently wrong with doing so, the filing of
duplicate reports can cause Debian package maintainers to spend time
performing triage and maintenance operations on bug reports (e.g.,
instructing the Debian Bug Tracking System to merge the duplicates) that
could otherwise be spent resolving problems and doing other work on the
package.
One very good way to file bugs with the Debian Bug Tracking System is to
use the "reportbug" package and command of the same name. A very nice
feature of reportbug is that, if the machine where you run it has network
access to the World Wide Web, it can query the Debian Bug Tracking System
and show you existing reports. This reduces the chance that you'll file a
duplicate report, and offers you the option of adding follow-up information
to an existing bug report. This is especially valuable if you have unique
information to add to an existing report, because this way information
relevant to the problem is gathered together in one place as opposed to
being scattered among multiple, duplicate bug reports where some facts may
be overlooked by the package maintainers. The reportbug program also does
a lot of automatic information-gathering that helps package maintainers to
understand your system configuration, and also ensures that your message to
the Debian Bug Tracking System is well-formed so that it is processed
correctly by the automated tools that manage the reports. (If you've ever
gotten a "bounce" message from the Debian Bug Tracking System that tells
you your message couldn't be processed, you might appreciate this latter
feature.)
Therefore, I strongly urge you to give "reportbug" a try as your primary
bug reporting tool for the Debian System. (If you already do use
"reportbug", please see below.)
One way to install reportbug is with "apt-get"; for
example:
# apt-get install reportbug
The "reportbug" command has a few different modes that cater to different
levels of user expertise. If this message has contained a lot of jargon
that is unfamiliar to you, you likely want to use reportbug's "novice"
mode; here's one way to do that.
$ reportbug --mode=novice
Please enter the name of the package in which you have found a problem,
or type 'other' to report a more general problem.
>
If you're more sophisticated, or if you are not using the released version
of Debian ("stable"), but instead Debian "testing" or "unstable", you
should use reportbug's standard mode.
$ reportbug
Please enter the name of the package in which you have found a problem,
or type 'other' to report a more general problem.
>
The reportbug command is extensively documented in its usage message and
manual page. Commands to view these pieces of documentation are:
$ reportbug --help | more
$ man reportbug
(The output of the above commands has been omitted from this message.)
If you do use reportbug, but are so daunted by the large number of bugs
already filed against a package that you feel you cannot search for a
duplicate, please note that reportbug has a (f)ilter feature that enables
you to use a keyword search to limit the number of bugs reported. (If
you're feeling ambitious, the filter feature also accepts a regular
expression.) For example, if you'd like to report a SEGV (segfault), you
might filter based on the term "SEGV". If you're having trouble upgrading
a package, you might filter based on "upgrad" (to catch both "upgrade" and
"upgrading"). Some package maintainers retitle bugs to contain keywords so
as to facilitate better filtering and convey more useful information, since
a bug report with a title of "broken" or the like is not very useful to
anyone.
We appreciate you taking the time to help package maintainers serve you
better by reducing the amount of time they need to spend coping with
duplicate bug reports.
Thanks for using the Debian system!
--
G. Branden Robinson| "There is no gravity in space."
Debian GNU/Linux | "Then how could astronauts walk
[EMAIL PROTECTED] | around on the Moon?"
http://people.debian.org/~branden/ | "Because they wore heavy boots."
signature.
Bug#229850: DEFAULT_HORIZ_SYNC and DEFAULT_VERT_REFRESH still ignored (updated patch)
> > I'll admit to not having a deep knowledge of debconf, so I'm not sure > > why the original code is wrong. There is a db_get on > > xserver-xfree86/config/monitor/selection-method before the above > > message, but I never see the question. > > db_get doesn't ask questions. Only db_input does that. Well, technically, > db_input enqueues a question for asking, and db_go runs the queue. Okay, thanks for this clarification. (I figure maybe if I wait long enough to learn debconf, cdebconf will be ready. ;-]) > > I also can't see what in preinst is causing the autodetect_video_card > > question to be asked twice even though we've been through it already > > in config. > > Very annoying. Can you please send me your full config log file with the > db_subst->db-set change made? Attached. > > So obviously, there's some more work to do and I don't know how > > much of my testing problems were the result of my trying to cobble > > together configuration files from subversion. > > Well, here's one way to find out. I've just merged the latest changes onto > the trunk onto the debconf-overhaul branch, and run a diff between the two > trees: By the way, necrotic.deadbeast.net doesn't seem to be answering anonymous svn with the svn:// protocol. % svn ls svn://necrotic.deadbeast.net/xfree86/trunk svn: Can't connect to host 'necrotic.deadbeast.net': Connection refused % telnet necrotic.deadbeast.net svnserve Trying 216.37.46.189... telnet: Unable to connect to remote host: Connection refused hence my use of ViewCVS. >local/dexconf >xserver-xfree86.config.in >xserver-xfree86.templates Looks like all three of these may be relevant, but I only got config.in. I'm packing to leave town for a few days and don't really have time right now to go through my config.log to remove extraneous output from multiple runs. There are logs from at least three configurations, the first one of which definitely didn't work and the last one of which definitely worked with the exception of the multiple questions about autoconfiguration. Since I answered the questions pretty fast you'll be able to tell the differences between the runs trivially by looking at the timestamps, in addition to any other methods that may be more direct. If this doesn't do it for you for some reason, I'd be glad to repeat my trials and save specific config logs from each trial. I'm guessing that probably won't be necessary though. Have fun! -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ 2004-09-26 04:36:23 PM-0400 select_default_x_server(): no stored checksum available for /etc/X11/X 2004-09-26 04:36:23 PM-0400 not configuring default X server; manual modifications have been made -- please see /usr/share/doc/xfree86-common/FAQ.gz or /usr/share/doc/xfree86-common/FAQ.xhtml.gz 2004-09-26 04:36:23 PM-0400 select_default_x_server(): no stored checksum available for /etc/X11/X 2004-09-26 04:36:23 PM-0400 configure_video_device(): no video driver modules found in /usr/X11R6/lib/modules/drivers 2004-09-26 04:36:23 PM-0400 configure_video_device(): available video driver list set to "apm, ark, ati, chips, cirrus, cyrix, fbdev, glide, glint, i128, i740, i810, imstt, mga, neomagic, newport, nsc, nv, rendition, s3, s3virge, savage, siliconmotion, sis, tdfx, tga, trident, tseng, vesa, vga, via, vmware" 2004-09-26 04:36:23 PM-0400 configure_video_device(): user declined video card autodetection 2004-09-26 04:36:23 PM-0400 auto_answer(): running "db_input high xserver-xfree86/config/device/driver" with default "vesa" 2004-09-26 04:36:23 PM-0400 auto_answer(): auto-answering with "vesa" 2004-09-26 04:36:23 PM-0400 auto_answer(): asking xserver-xfree86/config/device/driver 2004-09-26 04:36:25 PM-0400 auto_answer(): value of xserver-xfree86/config/device/driver is now "ati" 2004-09-26 04:36:25 PM-0400 auto_answer(): running "validate_string_db_input low xserver-xfree86/config/device/identifier" with default "Generic Video Card" 2004-09-26 04:36:25 PM-0400 auto_answer(): auto-answering with "Generic Video Card" 2004-09-26 04:36:25 PM-0400 auto_answer(): asking xserver-xfree86/config/device/identifier 2004-09-26 04:36:25 PM-0400 auto_answer(): value of xserver-xfree86/config/device/identifier is now "Generic Video Card" 2004-09-26 04:36:25 PM-0400 configure_video_device(): multihead system detected; setting BusID question priority to high 2004-09-26 04:36:25 PM-0400 PCI:1:0:0 0300: 1002:4152 2004-09-26 04:36:25 PM-0400 auto_answer(): running "validate_bus_id_db_input high xserver-xfree86/config/device/bus_id" with default "PCI:1:0:0" 2004-09-26 04:36:25 PM-0400 auto_answer(): auto-answering with "PCI:1:0:0" 2004-09-26 04:36:27 PM-0400 auto_answer(): asking xserver-xfree86/config/device/bus_id 2004-09-26 04:36:27 PM-0400 auto_answer(): value of xserver-xfree86/config/device/bus_id is now "PCI:1:0:0" 2004-09-26 04:36:27 PM-0400 configure_video_device(): /proc/fb reports frame
Bug#260598: marked as done (xserver-xfree86: [i740] X cursor not updated correctly)
Your message dated Mon, 27 Sep 2004 22:04:46 -0500 with message-id <[EMAIL PROTECTED]> and subject line Bug#260598: Pointer background not updated for i740 X server has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 21 Jul 2004 10:09:39 + >From [EMAIL PROTECTED] Wed Jul 21 03:09:39 2004 Return-path: <[EMAIL PROTECTED]> Received: from dep.oprit.rug.nl [129.125.36.9] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1BnE2c-0008Oy-00; Wed, 21 Jul 2004 03:09:38 -0700 Received: from spark (GN-LC002-COM04-216-207.kabela.oprit.rug.nl [129.125.216.207]) by dep.oprit.rug.nl (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id i6LA95S1007219 for <[EMAIL PROTECTED]>; Wed, 21 Jul 2004 12:09:05 +0200 (MEST) Received: from shevek by spark with local (Exim 3.35 #1 (Debian)) id 1BnE8C-00082F-00 for <[EMAIL PROTECTED]>; Wed, 21 Jul 2004 12:15:24 +0200 Date: Wed, 21 Jul 2004 12:15:23 +0200 From: Bas Wijnen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Pointer background not updated for i740 X server Message-ID: <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8X7/QrJGcKSMr1RN" Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: Bas Wijnen <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-6.1 required=4.0 tests=BAYES_00,HAS_PACKAGE, NORMAL_HTTP_TO_IP autolearn=no version=2.60-bugs.debian.org_2004_03_25 X-Spam-Level: --8X7/QrJGcKSMr1RN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Package: xserver-xfree86 Version: 4.3.0.dfsg.1-6 The background of the pointer on my X, using the i740 server, is not updated when the pointer moves in steps. Nor is the pointer updated, until it moves again. This means that when there is a step move, or an other sudden change (the scroll wheel makes step moves in gnome-terminal, for example. An other change is the mapping of a window under the pointer due to interactive placement), the pointer is not redrawn until it moves. When it does, there= is a square below it which is filled with its old background. An especially b= ig mess can be made when dragging a window: in that case parts of the square under the pointer are copied over themselves. As an example I made a screen shot of an xterm, which shows the background from a "change virtual desktop with hotkey, then move the mouse" situation, where I used the scrollwheel to go up and down several times, and which I dragged a little over the desktop. You can find it at: http://129.125.47.90/~shevek/desktop-bug.png Note that the computer was running GNU/Linux when this screenshot was taken, not GNU/Hurd. It is named hurd because I develop (and run) GNU/Hurd on it, but I wasn't at that moment. My XF86Config-4 is attached. This problem occurs since I upgraded to gnome 2.6, at which time I guess I also upgraded to the dfsg version of X (I got the new pointers after that upgrade anyway.) I checked, and the bug also occurs without gnome (actuall= y, with only X and an xterm, without even a window manager.) $ uname -a Linux hurd 2.6.2 #7 Fri Feb 13 15:35:02 CET 2004 i686 GNU/Linux $ COLUMNS=3D200 dpkg -l | grep xserver ii xserver-common 4.3.0.dfsg.1-6 files and utilities common to all X servers ii xserver-xfree86 4.3.0.dfsg.1-6 the XFree86 X server All problems mentioned can be "solved" by forcing a redraw, for example you switching to and from a different virtual desktop. Having to do that all t= he time is quite annoying though. Thanks, Bas Wijnen --=20 I encourage sending me encrypted e-mail. Please send the central message of e-mails as plain text in the message bod= y, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. for more information, see http://129.125.47.90/e-mail.html --8X7/QrJGcKSMr1RN Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFA/kI6FShl+2J8z5URAh9lAJ4sSPLb9fAkLWXVMdWKCu0qy5WDiQCgtLS5 tqbbczsVGB1lBpqliObUcT4= =xh7+ -END PGP SIGNATURE- --8X7/QrJGcKSMr1
X Strike Force XFree86 SVN commit: r1880 - trunk/debian
Author: branden Date: 2004-09-27 23:42:12 -0500 (Mon, 27 Sep 2004) New Revision: 1880 Modified: trunk/debian/TODO Log: Add item. Modified: trunk/debian/TODO === --- trunk/debian/TODO 2004-09-28 02:17:27 UTC (rev 1879) +++ trunk/debian/TODO 2004-09-28 04:42:12 UTC (rev 1880) @@ -61,6 +61,10 @@ + Use /proc/hardware on m68k architecture to set a reasonable default mouse port. See http://lists.debian.org/debian-68k/2004/08/msg00392.html>. * Add FAQ entry describing Debian's plans in the X department. +* Add Debian-specific patch to uxterm to call validlocale(8) before trying to + launch xterm, per recommendation from Recai Oktas. If a valid locale isn't + set, bail out (would resolve #246398). (This patch would be Debian-specific + because validlocale is a Perl utility provided by base-config.) 4.3.0.dfsg.1-10 --
X Strike Force XFree86 SVN commit: r1882 - trunk/debian
Author: branden Date: 2004-09-27 23:52:27 -0500 (Mon, 27 Sep 2004) New Revision: 1882 Modified: trunk/debian/CHANGESETS Log: Fix incorrect revision number. Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-09-28 04:43:24 UTC (rev 1881) +++ trunk/debian/CHANGESETS 2004-09-28 04:52:27 UTC (rev 1882) @@ -110,6 +110,6 @@ ut_line member. (Closes: #256468) Update XTerm FAQ to revision 1.86 (2004-07-28) from Thomas Dickey's website. -1879 +1881 vim:set ai et sts=4 sw=4 tw=80:
