Bug#229879: marked as done (xserver-xfree86: [savage] savage(4x) manpage refers to nonexistent shadowfb(4x) manpage)
Your message dated Sat, 15 Jan 2005 02:25:38 -0500 with message-id <[EMAIL PROTECTED]> and subject line Bug#229879: Acknowledgement (xserver-xfree86: reopen #100451 [savage] savage(4x) manpage refers to nonexistent shadowfb(4x) 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; 27 Jan 2004 08:33:42 + >From [EMAIL PROTECTED] Tue Jan 27 00:33:42 2004 Return-path: <[EMAIL PROTECTED]> Received: from mx03.gis.net [208.218.130.11] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1AlOfG-0002Sh-00; Tue, 27 Jan 2004 00:33:42 -0800 Received: from arf ([67.75.25.90]) by mx03.gis.net; Tue, 27 Jan 2004 03:33:40 -0500 Received: from alfie by Arf with local (Exim 3.36 #1 (Debian)) id 1AlOhW-0003NN-00; Tue, 27 Jan 2004 03:36:02 -0500 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: A Costa <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Subject: xserver-xfree86: reopen #100451 [savage] savage(4x) manpage refers to nonexistent shadowfb(4x) manpage X-Mailer: reportbug 2.39 Date: Tue, 27 Jan 2004 03:36:01 -0500 Message-Id: <[EMAIL PROTECTED]> Sender: A Costa <[EMAIL PROTECTED]> X-BadReturnPath: [EMAIL PROTECTED] rewritten as [EMAIL PROTECTED] using "From" header Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_01_25 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-5.0 required=4.0 tests=HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2004_01_25 X-Spam-Level: Package: xserver-xfree86 Version: 4.2.1-15 Severity: minor The old bug here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=100451&archive=False&mbox=no ...seems to have come back to life. ~>man savage | grep -A1 -B2 shadowfb Option "ShadowFB" "boolean" Enable or disable use of the shadow framebuffer layer. See shadowfb(4x) for further information. This option disables acceleration. Default: off. ...yet there's no "shadowfb(4x)" man page. Hope this helps... -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux Arf 2.4.24-1-k6 #1 Tue Jan 6 23:45:32 EST 2004 i586 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to C) Versions of packages xserver-xfree86 depends on: ii debconf 1.4.7Debian configuration management sy ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii xserver-common 4.2.1-15 files and utilities common to all ii zlib1g 1:1.2.1-3compression library - runtime -- debconf information excluded --- Received: (at 229879-done) by bugs.debian.org; 15 Jan 2005 07:26:13 + >From [EMAIL PROTECTED] Fri Jan 14 23:26:13 2005 Return-path: <[EMAIL PROTECTED]> Received: from mx03.gis.net (gis.net) [208.218.130.11] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1CpiK5-00012U-00; Fri, 14 Jan 2005 23:26:13 -0800 Received: from arf ([207.7.201.62]) by mx03.gis.net; Sat, 15 Jan 2005 02:26:11 -0500 From: "Alfie Costa" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Sat, 15 Jan 2005 02:25:38 -0500 MIME-Version: 1.0 Subject: Re: Bug#229879: Acknowledgement (xserver-xfree86: reopen #100451 [savage] savage(4x) manpage refers to nonexistent shadowfb(4x) Reply-to: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Priority: normal In-reply-to: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Rcpt-To: <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: It's fixed. Looks OK to close: % man savage | grep -A1 -B2 shadowfb ;echo $? 1 # found nothing, good -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#229850: DEFAULT_HORIZ_SYNC and DEFAULT_VERT_REFRESH still ignored (updated patch)
On Sat, Jan 08, 2005 at 08:53:03PM -0500, Jay Berkenbilt wrote: > I never replied to this. Sorry. It came in at a busy time and then > got buried in my inbox. :-( That's all right. > Anyway, since that time, maybe there have been lots of changes. We've > also seen the introduction of xdebconfigurator which seems to be the > type of tool you imagined -- something that would answer the debconf > questions in advance, at least in some cases. xdebconfigurator is ultimately orthogonal to what I'm trying to achieve with the X server debconf questions. Ideally, the X server debconfage should just expose the most desirable configuration parameters to poke. I'd like to get stuff like the "Simple/Medium/Advanced" monitor selection methods out of there. Tools like xdebconfigurator can potentially do a vastly better job of such things, not necessarily being limited to debconf's user interface tools, and separately maintained I'm hoping they can be more aggressively hacked on and brought up to a standard that will make our users happy. Moreover, by decoupling the user hand-holding and hardware probing, multiple front-ends can spring into being, competing with and complementing each other. > So... I'm just curious on where we are with this. I'm still happy to > do additional testing on the debconf changes in xserver-xfree86, but I > didn't want to just pick up where I left off three months ago since > additional progress or changes in thinking may have happened since > then. For now, I'm just going to file my old email on this bug and > assume that the right thing will happen, but if you'd like me to do > any additional testing or to go ahead and send the config log from my > attempts at configuring from the latest versions of the config > scripts, I'm glad to do so. For now, I don't need you to do anything, but someday soon I may ask for more feedback. :) -- G. Branden Robinson|The word "power" is an obscenity in Debian GNU/Linux |a democracy. [EMAIL PROTECTED] |-- Andy Jacobs, Jr. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#281050: xserver-common: [i810] Memory leak
Hello, I just tried gpdf on a large file with X.Org on Ubuntu Hoary (booted from a live CD). It appears that the problem is still there, but to a lesser extent. The PDF file that made XFree86 suck 200+ MB only expanded the X.Org server to 60-70MB. After a few minutes usage dropped to 45MB. While it is still noticeable, the effect is significantly smaller. Since gpdf is just a very vague and imprecise indicator of the actual problem of X sucking up large amounts of memory over extended periods of time, it would probably be more useful to try to run X.Org in real-life situations. I am contemplating migration to Hoary, but I am not sure that I can find time to do that. I will probably do the migration during the next few months, but I would not bet on it. P.S. Should I continue to send copies of mails to you directly, or will you pick them out from the Debian bug tracker system (I am not sure if it is sending copies to you automatically)? -- Gintautas Miliauskas <[EMAIL PROTECTED]> signature.asc Description: =?iso-8859-2?Q?=A9i?= =?iso-8859-2?Q?_lai=B9ko?= dalis yra =?iso-8859-2?Q?pasira=B9yta?= skaitmeniniu =?iso-8859-4?Q?b=FEdu?=
Bug#284111: xserver-xfree86: Doesn't scan PCI domains above 0000 on startup
> On Thu, 13 Jan 2005 17:14:04 -0700, Bjorn Helgaas <[EMAIL PROTECTED]> > said: Bjorn> The domain changes to /proc/bus/pci are implemented for Bjorn> sparc64, ppc64, ia64, alpha, and mips (see pci_name_bus()). Bjorn> They aren't all identical (sparc64 uses %04x:%02x always, Bjorn> while ia64 uses %04x:%02x only for non-zero domain) Ah, yes, I thought there was something that was done differently from sparc. Only printing non-zero domains seems like the right thing to do, since it preserves backwards-compatibility. Speaking of pci_name_bus(), it's amazing "folks" would introduce new APIs that take a string buffer argument _without_ a size argument... --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]