X Strike Force XFree86 SVN commit: r1383 - trunk/debian
Author: branden Date: 2004-05-11 01:58:35 -0500 (Tue, 11 May 2004) New Revision: 1383 Modified: trunk/debian/TODO Log: Update item. Modified: trunk/debian/TODO === --- trunk/debian/TODO 2004-05-11 06:51:05 UTC (rev 1382) +++ trunk/debian/TODO 2004-05-11 06:58:35 UTC (rev 1383) @@ -12,7 +12,9 @@ These items are listed in descending order of priority; that is, the most important items come first. -* Grab SiS driver from Thomas Winischhofer's website, per his information. +* Grab SiS driver from Thomas Winischhofer's website. Ignore Imakefile and + Makefile in this archive. + http://www.winischhofer.net/sis/sis_drv_src_current.tar.gz Should fix: #245249: xserver-xfree86: [sis] screen "melt" with SiS 630ST and 4.3.0-7 #246087: xserver-xfree86: [sis] immediate system hang with SiS 330 (Xabre)
Special offers on cds, Debian.
Buenos tardes!Adversity makes men, and prosperity makes monsters. Low rates on Software Searching for cheap high-quality software? Our site might be just what you need.http://innovant.oevier.biz/OE017/?affiliate_id=233712&campaign_id=601 We are able to ship worldwide.Nothing more detestable does the earth produce than an ungrateful man.Many a man has fallen in love with a girl in light so dim he would not have chosen a suit by it.
Bug#241566: [xclock]: colored hands cannot be changed
When the manpage is updated, perhaps it can also say why it's a Good Thing that rendering is used, because on the face of it (pun intended) it's only a disadvantage if it disables the old xclock options (I updated my system last night and the xclock's appearance was very different to what it used to be, and no hint on how to fix it again anywhere besides this bug report). Paul Slootman
XFree86 4.3.0 woody backport updated
I updated the XFree86 4.3.0 woody backport to 4.3.0.dfsg.1-1. | deb http://people.debian.org/~nobse/xfree86 woody main As usual, please to not file bugreports against this version to the Debian BTS. Regards, Norbert
Bug#248453: xlibmesa-dri: Segfaults crack-attack on matrox.
Package: xlibmesa-dri Version: 4.3.0.dfsg.1-1 Severity: normal Since I installed XFree86 4.3, crack-attack crashes. It does not crash when direct rendering is disabled, though, so it looks like a bug in direct rendering. In gdb it looks that the stack is corrupt, but I have not recompiled with debugging. However, gdb claims the top frame is mallopt from glibc. I have a MGA450 graphic card and use Matrox driver BETA3.0. I tried both mga_drv.o from Matrox and from XFree, but that makes no difference. The mga_hal_drv.o from Matrox is necessary to get direct rendering. Matrox does not provide dri/mga_drv.so for XFree 4.3, so I now use the one from xlibmesa-dri, while before I used the one from Matrox. I am willing to provide more additional information you may ask for. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.5 Locale: LANG=C, LC_CTYPE=cs_CZ Versions of packages xlibmesa-dri depends on: ii xlibmesa-gl 4.3.0.dfsg.1-1 Mesa 3D graphics library [XFree86] Other relevant packages: ii freeglut3 [libglut3] 2.2.0-6.1 OpenGL Utility Toolkit ii libc6 2.3.2.ds1-12 GNU C Library: Shared libraries an ii libgcc1 1:3.3.3-7 GCC support library ii libglut3 3.7-25 the OpenGL Utility Toolkit ii libice6 4.3.0.dfsg.1-1 Inter-Client Exchange library ii libsm64.3.0.dfsg.1-1 X Window System Session Management ii libstdc++51:3.3.3-7 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-1 X Window System protocol client li ii libxi64.3.0.dfsg.1-1 X Window System Input extension li ii libxmu6 4.3.0.dfsg.1-1 X Window System miscellaneous util ii xlibmesa-gl [libgl1] 4.3.0.dfsg.1-1 Mesa 3D graphics library [XFree86] ii xlibmesa-glu [libglu1]4.3.0.dfsg.1-1 Mesa OpenGL utility library [XFree ii xlibs 4.3.0.dfsg.1-1 X Window System client libraries m -- no debconf information --- Jan 'Bulb' Hudec <[EMAIL PROTECTED]> signature.asc Description: Digital signature
C'ialis - it`s COOL! Xx
Sup:er-Via.gra Sup:er-Lo.w-Pr.ice 2h Take it once and lasts all weekend You can mix Cia.lies with alco.hol without any harm You may also find other good stuff on our website Check out our website with dis-counts and get your f!ree bonus pi11s http://myfb.myph.biz/sv/index.php?pid=eph5120 Off: http://awnr.myph.biz/sv/chair.php Super HGH - HumanGrowthHormone http://dkzk.myph.biz/hgh/index.php?pid=eph5120 Prozac - PrescribedAntiDepressant http://zpc.myph.biz/pr/index.php?pid=eph5120 Q s U crock artichoke calumny singsong method insomniac critique ugh protector elaine corsage administrable
Bug#248480: xserver-fbdev: assumption made that discover will detect video (old thinkpad 380d)
Package: xserver-fbdev Severity: normal branden, hi, on both this and the xserver-svga packages, there is an assumption that if the discover package exists, to search for the video bus, but if that video bus doesn't exist, the dpkg config exits with an error. surely if the video bus does not exist it should be assumed that discover cannot be used and then to proceed as if discover isn't there? sincerely, l. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux highfield 2.6.5-1-686 #1 Sat Apr 24 08:47:10 EST 2004 i686 Locale: LANG=C, LC_CTYPE=C
X Strike Force XFree86 SVN commit: r1385 - trunk/debian
Author: branden Date: 2004-05-11 11:00:24 -0500 (Tue, 11 May 2004) New Revision: 1385 Modified: trunk/debian/TODO Log: Remove duplicate of already-completed item. Modified: trunk/debian/TODO === --- trunk/debian/TODO 2004-05-11 15:40:24 UTC (rev 1384) +++ trunk/debian/TODO 2004-05-11 16:00:24 UTC (rev 1385) @@ -97,9 +97,6 @@ more info] * #245065: xbase-clients: add an option to let setxkbmap ignore current server settings -* #234025: xserver-xfree86: [ati/radeon] display brightness too high when X - server started with S-Video cable connected on Radeon RV200 QW [Radeon 7500] - rev 0 (patch tested by submitter of #245919, merged) * Fix xc/lib/X11/XlcDL.c to not use confusing symbol name "_MACH64_NAME", which has to do with 64-bit machines, not ATI Mach64 video chipsets. Also the corresponding kludge to "if defined(_LP64) && defined(__sparcv9)", as
Processed: tagging 245249
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.7.95.1 > # fixed in Debian X Strike Force XFree86 repository; to view, run "svn diff > -r 1383:1384 svn://necrotic.deadbeast.net/xfree86" > tags 245249 + pending Bug#245249: xserver-xfree86: [sis] screen "melt" with SiS 630ST and 4.3.0-7 Tags were: upstream moreinfo Tags added: pending > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Processed: tagging 246087
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.7.95.1 > # fixed in Debian X Strike Force XFree86 repository; to view, run "svn diff > -r 1383:1384 svn://necrotic.deadbeast.net/xfree86" > tags 246087 + pending Bug#246087: xserver-xfree86: [sis] immediate system hang with SiS 330 (Xabre) There were no tags set. Tags added: pending > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
xfree86_4.3.0.dfsg.1-2 is too long a filename
Hi, I was poking around at: http://www.distrowatch.com/debian I see that due to the length, it trunctuates after the '1' meaning Distrowatch will never be able to report the SID revision unless the name is shortened, or distrowatch's columns are widened. So here's my proposal. Since we know that there'll never be a 4.3.1 because they went to 4.4 it should be renamed: xfree86_4.3.dfsg.1-2 which will take care of the trunctuation until you get into revisions higher than 9. Regards, P.
Re: xfree86_4.3.0.dfsg.1-2 is too long a filename
Hi, On Tue, 11 May 2004, Peter Constantinidis wrote: > Hi, I was poking around at: > > http://www.distrowatch.com/debian > > I see that due to the length, it trunctuates after the '1' meaning > Distrowatch will never be able to report the SID revision unless the name > is shortened, or distrowatch's columns are widened. Probably you didn't realize that distrowatch shows only "upstream" version. The last "-Y" number is missing from all the packages. In the case of Xfree86 our upstream version is 4.3.0.dfsg.1 that is almost 4.4 without all non-free parts stripped out. Thanks Fabio PS If this was a joke, or you are on drugs.. can i have the phone number of your pusher? ;) -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.
your confirmation is needed
When was the last time you got lucky in love? Well, isnt it time to turn your luck around? Love is a sure thing when you click here and its free. http://amomentlikethisagain.com/confirm/?oc=50795989 Click here if you do not wish to be invited again: http://amomentlikethisagain.com/remove/?oc=50795989 lacetonesandusky huxley clyde educate pedigree cleveland into euphemist insincere spin zero marijuana affectate iblubberbarrage portentous jacobean prehistoric dentistry luck cumin magnanimous contemptible bartok beam calculi factor goad astronautic hidalgo shrub letterhead digging mcginnis neither actuarial demultiplex discoid buret dune cumulate swam barracuda performance ballroom bullhide clarendon diction ionic
Re: xfree86_4.3.0.dfsg.1-2 is too long a filename
* Peter Constantinidis wrote: > Hi, I was poking around at: > > http://www.distrowatch.com/debian > > I see that due to the length, it trunctuates after the '1' meaning > Distrowatch will never be able to report the SID revision unless the > name is shortened, or distrowatch's columns are widened. That's distrowatch's problem, not ours. Norbert
clean-room reimplementation revisited, and a couple of EASY exercises for XTerm
Please forgive the long preface. As you should know, an update to XTerm is on the TODO for the next Debian xfree86 package release, 4.3.0.dfsg.1-2. Bad news first: Before I can update the SVN trunk to Thomas Dickey's latest release of XTerm (#187), I need a bit of potential XFree86 1.1 license contamination cleaned up. More bad news next: As has already been noted on this list, David Dawes has asserted on the XFree86 "devel" mailing list that: Assume that anything attributed to me is covered by the 1.1 licence unless explicitly stated otherwise.[1] To the best of my knowledge, Mr. Dawes have never made an explicit statement otherwise under any circumstances. Furthermore, it is my understanding that he does not answer emails inquiring as to whether this policy applies to specific commits (I am not speaking only of mails to Mr. Dawes from myself, either, but from others as well). Moreover, Mr. Dawes feels that it is not necessary to explicitly assert his (or the XFree86 Project, Inc.'s) copyright and license terms in modifications that are made to the XFree86 CVS repository: [In reference to the XFree86's statement on their license policy page[3], "Refer to each source file for specific licence details":] If you interpret that to apply to every revision of every file in an active CVS repository, then you are kidding yourself.[2] (Why it is challenging to add current and accurate copyright and license information to source files in XFree86 CVS is a mystery to me, particularly given past examples of precisely that[4][5].) Fortunately, the changes made to XTerm in XFree86 after the relicensing on 2004-02-13[5] are trivial in nature. They are probably not copyrightable at all, and I suspect the folks at the XFree86 Project, Inc., agree -- but given the difficulty in obtaining answers to straightforward questions, and the XFree86's Project's recent fundraising efforts on their Web site, I'd hate to be mistaken and end up on the wrong side of a copyright infringement suit. (It is possible to infringe clause 3 of the XFree86 1.1 license even if there is no applicable copyright notice or license statement that makes it clear that the XFree86 1.1 actually applies to the file in question. Given that I know of Mr. Dawes's stated intentions[1], even if I don't completely comprehend them, I may be at risk for "willful" infringement under U.S. copyright law, and this is not a risk I am willing to take. The good news is that it should be a piece of cake to reimplement these trivial changes with a clean provenance. This would not merely be advantageous to Debian, but to anyone who wants to distribute an XTerm with a homogeneous copyright license on it (a welcome relief, I am sure, to those who have waded through the smorgasbord of licenses that apply to the various parts of the XFree86 distribution). Last time I asked for a clean-room reimplementation of something from my description, I failed to be strict enough in my demands to satisfy my paranoid mind. So this time, I'd like to ask that clean-room reimplementors quote the following material when they post their changes. * I affirm that this modification is my own work. * I affirm that I have not consulted source code more recent than 2004-02-12 from an XFree86 source code release or repository in the preparation of this modification. * I affirm that I have not consulted source code more recent than 2004-02-12 from Thomas Dickey's source releases of XTerm. [The previous item is only necessary because questionable code from XFree86 made its way back into XTerm; if Mr. Dickey replaces their changes with yours, future reimplementation requests may not need this affirmation.] * I refuse to assert copyright in this modification. If I am unable within a given legal jurisdiction to disclaim copyright in this modification, I hereby place it in the public domain. If I am unable within a given legal jurisdiction to place this modification in the public domain, I release this modification to the public under the following terms: Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE ABOVE LISTED COPYRIGHT HOLDER(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHE
Bug#248539: libxrandr2: No need to conflict with xlibs
Package: libxrandr2 Version: 4.3.0.dfsg.1-1 Severity: minor Hi, libxrandr2 does not need to conflict with xlibs (<< 4.3.0). xlibs 4.2.1-12.1 does only contain libxrandr 1.0 and not 2.0. # dpkg --force-conflicts -i libxrandr2_4.3.0.dfsg.1-1_i386.deb this works very well with my xlibs 4.2.1-12.1 and xlibs-dev 4.2.1-12.1 installed. It gives only a warning about the conflict, but not override-stuff. # dpkg -S libXrandr xlibs: /usr/X11R6/lib/libXrandr.so.1.0 xlibs-dev: /usr/X11R6/lib/libXrandr.a xlibs: /usr/X11R6/lib/libXrandr.so.1 libxrandr2: /usr/X11R6/lib/libXrandr.so.2 libxrandr2: /usr/X11R6/lib/libXrandr.so.2.0 Even that seems to work very well. (I wonder, where libXrandr.so is, but that's out of the scope of this bug and probably covered in some FAQ.) Elrond
Bug#233933: mouse delays on start
I'm seeing delays on start; it seems related to this. I have:
Section "InputDevice"
Identifier "Configured Mouse"
Driver "mouse"
Option "CorePointer"
Option "Device" "/dev/psaux"
Option "Protocol" "PS/2"
Option "Emulate3Buttons" "true"
Option "ZAxisMapping" "4 5"
EndSection
/dev/psaux has nothing attached; the system has no mouse (but for some
strange reason, X demands to have a bogus mouse configured anyway).
strace:
open("/dev/psaux", O_RDWR|O_NONBLOCK|O_EXCL) = 11
ioctl(11, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbb9c) = -1 ENOTTY (Inappropriate
ioctl for device)
ioctl(11, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbb2c) = -1 ENOTTY (Inappropriate
ioctl for device)
ioctl(11, TCFLSH, 0)= -1 ENOTTY (Inappropriate ioctl for
device)
select(1024, [11], NULL, NULL, {0, 0}) = 0 (Timeout)
write(11, "\377", 1)= 1
nanosleep({0, 1000}, NULL) = 0
select(1024, [11], NULL, NULL, {0, 20}) = 0 (Timeout)
ioctl(11, TCFLSH, 0)= -1 ENOTTY (Inappropriate ioctl for
device)
select(1024, [11], NULL, NULL, {0, 0}) = 0 (Timeout)
write(11, "\377", 1)= 1
nanosleep({0, 1000}, NULL) = 0
select(1024, [11], NULL, NULL, {0, 20}) = 0 (Timeout)
ioctl(11, TCFLSH, 0)= -1 ENOTTY (Inappropriate ioctl for
device)
select(1024, [11], NULL, NULL, {0, 0}) = 0 (Timeout)
write(11, "\377", 1)= 1
nanosleep({0, 1000}, NULL) = 0
This didn't happen before the major X upgrade (4.2?).
I worked around this by just pointing Device at a file that doesn't exist.
--
Glenn Maynard
Bug#248564: xbase-clients: Alt key doesn't work(alt-tab,ctrl-alt-f1,etc)
Package: xbase-clients Version: 4.3.0.dfsg.1-1 Severity: normal After upgrading today, the Alt modifier no longer seems to work. Pressing Ctrl-Alt-F1 does not swtich to VT1, and Alt-Tab does not switch windows in Sawfish. Ctrl-Alt-Bksp does shutdown the server. `xev` returns XF86_Switch_VT_1 when i hit ctrl-alt-f1. I'm not sure where else to go to figure out whats going on. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.5 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 Versions of packages xbase-clients depends on: ii cpp 4:3.3.3-2 The GNU C preprocessor (cpp) ii libc6 2.3.2.ds1-12 GNU C Library: Shared libraries an ii libdps1 4.3.0.dfsg.1-1 Display PostScript (DPS) client li ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libfontconfig12.2.2-2generic font configuration library ii libfreetype6 2.1.7-2FreeType 2 font engine, shared lib ii libice6 4.3.0.dfsg.1-1 Inter-Client Exchange library ii libncurses5 5.4-3 Shared libraries for terminal hand ii libpng12-01.2.5.0-6 PNG library - runtime ii libsm64.3.0.dfsg.1-1 X Window System Session Management ii libstdc++51:3.3.3-6 The GNU Standard C++ Library v3 ii libxaw7 4.3.0.dfsg.1-1 X Athena widget set library ii libxcursor1 1.1.3-1X cursor management library ii libxext6 4.3.0.dfsg.1-1 X Window System miscellaneous exte ii libxft2 2.1.2-6FreeType-based font drawing librar ii libxi64.3.0.dfsg.1-1 X Window System Input extension li ii libxmu6 4.3.0.dfsg.1-1 X Window System miscellaneous util ii libxmuu1 4.3.0.dfsg.1-1 lightweight X Window System miscel ii libxpm4 4.3.0.dfsg.1-1 X pixmap library ii libxrandr24.3.0.dfsg.1-1 X Window System Resize, Rotate and ii libxrender1 0.8.3-7X Rendering Extension client libra ii libxt64.3.0.dfsg.1-1 X Toolkit Intrinsics ii libxtrap6 4.3.0.dfsg.1-1 X Window System protocol-trapping ii libxtst6 4.3.0.dfsg.1-1 X Window System event recording an ii libxv14.3.0.dfsg.1-1 X Window System video extension li ii xlibmesa-gl [libgl1] 4.3.0.dfsg.1-1 Mesa 3D graphics library [XFree86] ii xlibmesa-glu [libglu1]4.3.0.dfsg.1-1 Mesa OpenGL utility library [XFree ii xlibs 4.3.0.dfsg.1-1 X Window System client libraries m ii xlibs-data4.3.0.dfsg.1-1 X Window System client data ii zlib1g1:1.2.1-5 compression library - runtime -- no debconf information
