Bug#95555: xserver-xfree86: [s3virge,ati/r128] SIGALRM spinlock between server generations when using Xinerama
On Tue, Jun 19, 2007 at 08:23:46PM +0200, Brice Goglin wrote: About 5 years ago, you replied to a bug in the Debian BTS regarding a SIGALRM spinlock between server generations when using Xinerama on a ATI r128 and a S3 Virge boards. Did any of you guys reproduce this problem recently? With Xorg/Etch? With latest xserver-xorg-core and drivers? If not, I will close this bug in the next weeks. I've never used Xinerama, though I helped Joe analyze the problem when it was happening. I'm not in a position to say whether it is still reproducible or not. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372077: use NEWS.Debian
On Thu, Jun 29, 2006 at 09:09:31PM -0400, David Nusinow wrote: On Fri, Jun 23, 2006 at 04:01:38PM -0400, Joey Hess wrote: One way to fix this would be to promote apt-listchanges to standard priority so it's available everywhere and add a NEWS.Debian entry for the issue. I would love this personally. I feel like apt-listchanges should be standard, and to be honest, I'm sick of telling newbies in #debian to install it. That it would solve this bug is the cherry on top. If it is important that it be displayed prior to the upgrade, and give the user a chance to abort it, then debconf seems more approriate. If it's sufficient to notify the user after the fact that they need to verify their system, then this would be better suited to something like update-notifier. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323270: dexconf: Please add support for reconfiguring X at boot time
On Mon, Aug 15, 2005 at 09:24:21PM +0200, Petter Reinholdtsen wrote: Package: xserver-common Version: 6.8.2.dfsg.1-5 Severity: wishlist Tags: patch When booting live CDs and thin clients, there is a need to (re)configure X automatically at boot time. To make this easier and more convenient with the normal X packages, it would be nice if an init.d script was provided to do call dexconf at boot time to generate a new configuration. Here is a draft init.d script based on the script included in xdebconfigurator and code fetched from the LTSP package in Ubuntu. As discussed with Petter previously, I don't think this is the right approach, and intend to maintain the existing mechanism where the LTSP init script configures X. I see no reason to split this logic over multiple packages. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323270: dexconf: Please add support for reconfiguring X at boot time
On Tue, Aug 16, 2005 at 01:07:57AM +0200, Petter Reinholdtsen wrote: [Matt Zimmerman] As discussed with Petter previously, I don't think this is the right approach, and intend to maintain the existing mechanism where the LTSP init script configures X. I see no reason to split this logic over multiple packages. The logic is already split across several packages. Both knoppix, lessdisks and ltsp need and implement a feature like this, and I believe it is better to have it in the X packages then to spread it across multiple packages. They are all doing different things. The only common part is calling dpkg-reconfigure, and I don't mind one line of duplicate code in favor of adding a new init script to another package. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323270: dexconf: Please add support for reconfiguring X at boot time
On Tue, Aug 16, 2005 at 01:30:30AM +0200, Petter Reinholdtsen wrote: [Matt Zimmerman] They are all doing different things. The only common part is calling dpkg-reconfigure, and I don't mind one line of duplicate code in favor of adding a new init script to another package. Well, as I see it, they all do the same thing, but in a different way. All of them try to configure X automatically at boot time, the as good as they are able to. I can't speak for the others, but the only thing that LTSP does apart from dpkg-reconfigure is to allow its configuration file to override some autodetected values. That isn't code which can be shared. try to configure X automatically at boot time comes down to dpkg-reconfigure. My proposal is to get them to do it the same way, making sure the automatic configuration at boot time get as good as possible by making sure everyone with this need contribute to a common code base. The automatic configuration code is already centralized in xserver-xorg. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#276060: apt: fixed pkgTagFile buffer shortage
On Thu, Mar 24, 2005 at 02:12:32AM +0100, guillaume pernot wrote: Package: apt Version: 0.5.28.6praksys1 Followup-For: Bug #276060 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 xfree86 4.3.0.dfsg.1-12's hits the 32kb/section limitation found in tagfile.h I was also getting the Unable to parse package file /var/lib/dpkg/status (1) messagez and the following patch solved the problem. That's the current version in unstable; I'd expect to receive many more reports if this were the case. Can you send a copy of the relevant stanza in the status file? Which binary package was affected? -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#281050: xserver-common: [i810] Memory leak
On Sun, Jan 16, 2005 at 04:50:04PM -0500, Michel Dänzer wrote: On Fri, 2005-01-14 at 23:22 +0200, Gintautas Miliauskas wrote: 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. You don't have to do a wholesale upgrade to hoary to run X.org from it. Indeed, if you need a Hoary/X.org environment to help with testing/reproducing a bug, one option is to try the (rough, but functional) Hoary live CD: http://cdimage.ubuntu.com/daily-live/current/ -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#263877: Various display artifacts in uxterm
On Wed, Dec 08, 2004 at 12:53:23AM -0500, Branden Robinson wrote: retitle 263877 xterm: various display artifacts thanks On Mon, Nov 22, 2004 at 09:55:41PM -, Thomas Dickey wrote: Matt Zimmerman [EMAIL PROTECTED] wrote: I can't conveniently install that version of the package; perhaps my test was inadvertently invalid. I've just returned from a holiday and don't remember what I did. I'll re-test when I'm a bit more caught up. The last few snapshots of xterm are on my ftp area - should be relatively simple to build. (I reread the bug report yesterday, but don't have any new ideas about reproducing it). XTerm #197, which was released on Monday, 30 November, will be in xterm 4.3.0.dfsg.1-9, which Fabio and I expect to release very soon (there are no more changes pending). Matt, if you could try to reproduce your problems with that package version, I'd appreciate it. I am unable to reproduce the bug with that version (nor with xterm from xorg 6.8.1). -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#263877: Various display artifacts in uxterm
On Wed, Nov 17, 2004 at 05:02:53PM -0500, Branden Robinson wrote: On Mon, Nov 01, 2004 at 06:43:10PM -0800, Matt Zimmerman wrote: Does XTerm #196, in xterm 4.3.0.dfsg.1-8, make either of these any better? I can still reproduce the problem in mutt using the uxterm binary from that package. e2832b71f5e85f1cd4447e7e3f34ee6a uxterm Thanks for following up. I'm sorry to hear the bug is still present. FYI, the MD5 checksum of uxterm is not all that useful for the type of bug you're reporting, as it's just a shell script wrapper around the xterm ELF executable. I generally take people's word for it if they tell me they're running a given version of a package. :) I can't conveniently install that version of the package; perhaps my test was inadvertently invalid. I've just returned from a holiday and don't remember what I did. I'll re-test when I'm a bit more caught up. -- - mdz
Bug#263877: Various display artifacts in uxterm
On Fri, Oct 08, 2004 at 06:28:17PM -0500, Branden Robinson wrote: On Mon, Sep 20, 2004 at 02:33:26PM -0500, Branden Robinson wrote: On Wed, Sep 01, 2004 at 08:53:40AM -0700, Matt Zimmerman wrote: On Wed, Sep 01, 2004 at 04:47:23AM -0500, Branden Robinson wrote: Can someone please help me out with a better explanation of what the bug being reported here actually is? various display artifacts is hopelessly vague. I described the visual effect in my original submission. I'm attaching screenshots of them now. I wasn't really able to follow it, though; thanks for the screenshots. Does XTerm #196, in xterm 4.3.0.dfsg.1-8, make either of these any better? I can still reproduce the problem in mutt using the uxterm binary from that package. e2832b71f5e85f1cd4447e7e3f34ee6a uxterm -- - mdz 263877-2.png Description: PNG image
Bug#263877: Various display artifacts in uxterm
On Wed, Sep 01, 2004 at 04:47:23AM -0500, Branden Robinson wrote: Can someone please help me out with a better explanation of what the bug being reported here actually is? various display artifacts is hopelessly vague. I described the visual effect in my original submission. I'm attaching screenshots of them now. -- - mdz 263877-mutt.png Description: PNG image 263877-manpage.png Description: PNG image
Bug#263877: Various display artifacts in uxterm
On Wed, Sep 01, 2004 at 01:23:31PM -0400, Thomas Dickey wrote: However - the report for 263877 sounds mostly like the bug fixed in patch #194 (from the mention of whitespace): Patch #194 - 2004/7/27 - XFree86 4.4.99.11 fix a repainting bug introduced in patch #180: when using a font lacking line-drawing characters, a repaint of the screen could skip horizontally an extra amount after filling in the missing character (reports by Nicolas George, Hans de Goede, Redhat Bugzilla #128341). Yes, this sounds like precisely the bug. -- - mdz
Bug#263877: Various display artifacts in uxterm
On Wed, Sep 01, 2004 at 03:58:26PM -0400, Thomas Dickey wrote: On Wed, Sep 01, 2004 at 10:45:07AM -0700, Matt Zimmerman wrote: On Wed, Sep 01, 2004 at 01:23:31PM -0400, Thomas Dickey wrote: However - the report for 263877 sounds mostly like the bug fixed in patch #194 (from the mention of whitespace): Patch #194 - 2004/7/27 - XFree86 4.4.99.11 fix a repainting bug introduced in patch #180: when using a font lacking line-drawing characters, a repaint of the screen could skip horizontally an extra amount after filling in the missing character (reports by Nicolas George, Hans de Goede, Redhat Bugzilla #128341). Yes, this sounds like precisely the bug. I'm only about 90% certain (seeing a screenshot would help). If Brandon wants to add the fix, it was rather small (attached). I sent screenshots to the bug: http://bugs.debian.org/263877 http://bugs.debian.org/cgi-bin/bugreport.cgi/263877-mutt.png?bug=263877msg=33att=1 http://bugs.debian.org/cgi-bin/bugreport.cgi/263877-manpage.png?bug=263877msg=33att=2 -- - mdz
Bug#263877: Various display artifacts in uxterm
On Wed, Sep 01, 2004 at 05:06:55PM -0400, Thomas Dickey wrote: On Wed, Sep 01, 2004 at 01:13:25PM -0700, Matt Zimmerman wrote: I sent screenshots to the bug: I'd forgotten about that (sorry). http://bugs.debian.org/263877 http://bugs.debian.org/cgi-bin/bugreport.cgi/263877-mutt.png?bug=263877msg=33att=1 http://bugs.debian.org/cgi-bin/bugreport.cgi/263877-manpage.png?bug=263877msg=33att=2 I don't see the relationship in the first picture, but the second one could be explained by this bug if the right-half of the window were being repainted. The ones I saw were with the dialog program - the shift happened shortly after the vertical lines on the left margin. But it was easily repeated given the font choice. In mutt, the screen is drawn correctly in the first place, but if it is redrawn by uxterm (e.g., switching desktops), I get the effect seen in the first picture. I'm not entirely sure what less(1) is doing in the second instance that is triggering the problem. -- - mdz
Bug#263877: Various display artifacts in uxterm
Package: xterm Version: 4.3.0.dfsg.1-6 Severity: normal This would have been Severity: minor, except that today I ran into a case where it actually lost information (for all practical purposes) which should have been displayed. I originally noticed that threaded mode in mutt was not handled correctly: 1. Open an mbox in mutt with some threads in it: mutt -f mbox file 2. Set threaded mode: 'o', 't' (drawn correctly) 3. Cause uxterm to redraw, e.g. by switching desktops, iconifying/restoring uxterm, etc. (drawn incorrectly, some parts of the screen revert to the uxterm background colour where they had previously been set to a different colour) Today, I noticed a somewhat different situation with hdparm: 1. man hdparm (I happen to have hdparm 5.5-4, and use less(1) as a pager) 2. Scroll to line 44 (in the paragraph describing the '-c' option) 3. Note that part of the sentence A numeric paramter[sic] can be used... is omitted (this is clear from reading the text). It reads: A numeric parameter can be used to enable/disable 32‐bit I/O support: Currently sup‐ ported values include 0 to disable 32‐bit I/O support, [whitespace] enable 32-bit data transfers while the text should read: A numeric parameter can be used to enable/disable 32‐bit I/O support: Currently sup‐ ported values include 0 to disable 32‐bit I/O support, _1_ to enable 32-bit data transfers (_1_ to in place of [whitespace]) Setting LC_ALL=C prevents both these effects (I typically use en_US.UTF-8). -- System Information: Debian Release: unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 Versions of packages xterm depends on: ii libc6 2.3.2.ds1-15 GNU C Library: Shared libraries an ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libfontconfig12.2.3-1generic font configuration library ii libfreetype6 2.1.7-2.1 FreeType 2 font engine, shared lib ii libice6 4.3.0.dfsg.1-6 Inter-Client Exchange library ii libncurses5 5.4-4 Shared libraries for terminal hand ii libsm64.3.0.dfsg.1-6 X Window System Session Management ii libxaw7 4.3.0.dfsg.1-6 X Athena widget set library ii libxext6 4.3.0.dfsg.1-6 X Window System miscellaneous exte ii libxft2 2.1.2-6FreeType-based font drawing librar ii libxmu6 4.3.0.dfsg.1-6 X Window System miscellaneous util ii libxpm4 4.3.0.dfsg.1-6 X pixmap library ii libxrender1 0.8.3-7X Rendering Extension client libra ii libxt64.3.0.dfsg.1-6 X Toolkit Intrinsics hi xlibs 4.3.0.dfsg.1-6 X Window System client libraries m ii xlibs-data4.3.0.dfsg.1-6 X Window System client data -- debconf information excluded -- - mdz
Bug#263877: Various display artifacts in uxterm
On Fri, Aug 06, 2004 at 08:42:17AM -0400, Thomas Dickey wrote: perhaps related (but not with the iso10646 fonts - but I've seen people changing the fonts in uxterm to use TrueType fonts): Patch #194 - 2004/7/27 - XFree86 4.4.99.11 * fix a repainting bug introduced in patch #180: when using a font lacking line-drawing characters, a repaint of the screen could skip horizontally an extra amount after filling in the missing character (reports by Nicolas George, Hans de Goede, Redhat Bugzilla #128341). This does sound similar to the effect that I see. -- - mdz
Bug#263877: Various display artifacts in uxterm
On Fri, Aug 06, 2004 at 12:10:49PM -0400, Thomas Dickey wrote: On Fri, Aug 06, 2004 at 09:05:52AM -0700, Matt Zimmerman wrote: On Fri, Aug 06, 2004 at 08:42:17AM -0400, Thomas Dickey wrote: perhaps related (but not with the iso10646 fonts - but I've seen people changing the fonts in uxterm to use TrueType fonts): Patch #194 - 2004/7/27 - XFree86 4.4.99.11 * fix a repainting bug introduced in patch #180: when using a font lacking line-drawing characters, a repaint of the screen could skip horizontally an extra amount after filling in the missing character (reports by Nicolas George, Hans de Goede, Redhat Bugzilla #128341). This does sound similar to the effect that I see. The fix I made only applies to a case where the font doesn't contain line-drawing characters (so I'm curious if it's the same case you're reporting, or some other corner that has been overlooked). It's easy to check if the line-drawing characters are missing (the control right mouse menu has an entry which can suppress xterm's built-in line-drawing, and use whatever the font actually does). If I check Line-drawing characters when mutt is running, the line-drawing characters it uses for threading are no longer displayed. If I do the same with the hdparm man page, some of the spacing changes (though in odd and varying ways). I have the standard xfonts-* packages installed, and UXTerm*font: 9x15. -- - mdz
Bug#263877: Various display artifacts in uxterm
On Fri, Aug 06, 2004 at 01:17:32PM -0400, Thomas Dickey wrote: On Fri, Aug 06, 2004 at 09:35:57AM -0700, Matt Zimmerman wrote: I have the standard xfonts-* packages installed, and UXTerm*font: 9x15. UXTerm*font: 9x15 could be a different problem. xterm uses two sets of fonts. An * (asterisk) will cause the iso10646 fonts to be ignored since they're given by a path such as uxterm.vt100.utf8fonts.font which would conflict with (what you intend the 9x15 to apply to): uxterm.vt100.font This was copied from my old xterm resources. I just tried changing it to uxterm.vt100.font, but that seems to cause it to revert to the default font. -- - mdz
Bug#263877: Various display artifacts in uxterm
On Fri, Aug 06, 2004 at 04:12:53PM -0400, Thomas Dickey wrote: sorry (I was fumbling around a display bug in PuTTY, should have read my reply more closely). uxterm sets the UXTerm class for xterm, which would mean you'd need UXTerm.vt100.font Has no effect for me. instead. The application name would still be xterm - though I have noticed at least one distributor renaming xterm to something like xterm.real - and referencing it via a symbolic link, breaking all the resource settings. A quick check of the above seems to work for me (ymmv). More generally, I configure xterm with the toolbar, which adds a level. But UXTerm*vt100.font Nor does this. is still more limited than UXTerm*vt100*font But this does. -- - mdz
Bug#261777: Problems handling multiple detected video cards
Package: xserver-xfree86 Version: 4.3.0.dfsg.1-5 Severity: normal On my laptop, discover erroneously detects two video cards, one trident and one s3virge. In reality, there is only one s3virge card. Anyway, this seems to confuse the xserver-xfree86 .config script, which displays xserver-xfree86/multiple_possible_x-drivers, but then defaults to vesa rather than one of the drivers that were chosen by discover. I assume this would affect actual systems with more than one video card as well. Here is the output with DEBUG_XFREE86_PACKAGE set: debian:/home/mdz# dpkg-reconfigure -plow -ftext xserver-xfree86 Configuring xserver-xfree86 --- Accept this option if you would like to attempt to autodetect the recommended X server and driver module for your video card. If autodetection fails, you will be asked to specify the desired X server and/or driver module. If autodetection succeeds, further debconf questions about your video hardware will be pre-answered. If you would rather select the X server and driver module yourself, decline this option. You will not be asked to select the X server if there is only one available. Attempt to autodetect video hardware? yes xserver-xfree86 config note: 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 xserver-xfree86 config note: could not autodetect X server driver: multiple drivers for video cards xserver-xfree86 config note: Detected Video Card Suggested driver module . Toshiba America Info Systems 601 trident S3 Inc. ViRGE/MX s3virge . Multiple potential default XFree86 server drivers for your hardware. Multiple video cards have been detected, and different drivers are required to support the various devices. It is thus not possible to automatically select a default XFree86 server driver. Please configure the device that will serve as your computer's primary head; this is generally the video card and monitor to which the computer displays when it first boots. At the present time, only a single-headed setup is supported by debconf; however, the X server configuration files can be edited to support a multi-head configuration. For the X Window System graphical user interface to operate correctly, it is necessary to select a video card driver for the X server. Drivers are typically named for the video card or chipset manufacturer, or for a specific model or family of chipsets. 1. apm 8. glide 15. neomagic 22. savage 29. vesa 2. ark 9. glint 16. newport23. siliconmotion 30. vga [More] 3. ati 10. i128 17. nsc24. sis31. via 4. chips 11. i740 18. nv 25. tdfx 32. vmware 5. cirrus 12. i810 19. rendition 26. tga 6. cyrix 13. imstt 20. s3 27. trident 7. fbdev 14. mga21. s3virge28. tseng Select the desired X server driver. [running reportbug on a different system] -- - mdz
Re: Future of X packages in Debian
On Fri, Jun 18, 2004 at 10:34:09AM -0700, Keith Packard wrote: I'd also like to see the fonts moved to arch any, I got side tracked attempting to switch from .pcf.gz to .ttf format, but there's no reason we can't simply compile to .pcf.gz on i386 and ship them from there -- every arch can load that format and the overhead is minimal (bitswapping on big-endian boxes). When upstream moves to .ttf, we will be ready. Point of Debian order here; what you (and I) want is arch all (build once for all arches), rather than any (built for any one arch). This has been a long-standing wishlist request, which was languished because (as I understand it), nobody wanted to futz with the imake build system enough to make it possible, and I can't blame anyone for that. If the X.Org build system makes this possible, then that's great. -- - mdz
Re: Future of X packages in Debian
On Fri, Jun 18, 2004 at 09:49:44PM +0200, Wouter Verhelst wrote: On Fri, Jun 18, 2004 at 09:02:50AM +0200, Fabio Massimo Di Nitto wrote: Our questions to the community are: * What kinds of X packages would you like to see in the future? Working ones. With as few (upstream and debian-specific) bugs as possible. Case at hand: I have yet to see the first XFree86 (server|module) and graphics board combination that * supports the full potential of the board * does not reproducably receive SIGSEGV * is free This is, of course, not the fault of the Debian X strike force, but it's painful none the less. I don't think that Fabio's message was an invitation to complain about X, but a request for input on maintaining Debian's X packages in the future. -- - mdz
XDM chooserFd vulnerability
According to the information I have seen, this bug probably does not affect woody, but I would appreciate confirmation, and to bring it to your attention for unstable: http://bugs.xfree86.org/show_bug.cgi?id=1376 http://www.openbsd.org/errata.html#xdm https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124900 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0419 -- - mdz
Bug#224757: Patch
tags 224757 patch
thanks
I thought it was obvious.
--
- mdz
--- /usr/include/X11/extensions/Xinerama.h 2003-11-13 14:37:21.0
-0800
+++ /tmp/Xinerama.h 2003-12-27 12:03:15.0 -0800
@@ -5,6 +5,8 @@
#include X11/Xlib.h
+_XFUNCPROTOBEGIN
+
typedef struct {
int screen_number;
short x_org;
@@ -42,5 +44,7 @@
int *number
);
+_XFUNCPROTOEND
+
#endif /* _Xinerama_h */
Bug#224757: X11/extensions/Xinerama.h missing extern C
On Mon, Dec 22, 2003 at 01:34:17PM +1100, Daniel Stone wrote:
#ifdef __cplusplus
extern C {
#endif
[...]
#ifdef __cplusplus
}
#endif
There seem to be macros in place for this already, in Xfuncproto.h:
#ifndef _XFUNCPROTOBEGIN
#if defined(__cplusplus) || defined(c_plusplus) /* for C++ V2.0 */
#define _XFUNCPROTOBEGIN extern C { /* do not leave open across includes */
#define _XFUNCPROTOEND }
#else
#define _XFUNCPROTOBEGIN
#define _XFUNCPROTOEND
#endif
#endif /* _XFUNCPROTOBEGIN */
The other headers wrap their declarations in these macros.
--
- mdz
Bug#224757: X11/extensions/Xinerama.h missing extern C
Package: xlibs-dev
Version: 4.2.1-14
Severity: normal
I'm not certain where it's supposed to come from, but there should be an
extern C in there somewhere if magic C++ compiler macro is defined.
Currently, this header is unusable in C++ programs.
mizar:[/tmp] cat test.cc
#include X11/extensions/Xinerama.h
int main() {
XineramaQueryExtension(NULL,NULL,NULL);
return 0;
}
mizar:[/tmp] gcc -x c++ -o test test.cc -L/usr/X11R6/lib -lXinerama -lX11
-lXext
/tmp/cci2yPT9.o(.text+0x28): In function `main':
: undefined reference to `XineramaQueryExtension(_XDisplay*, int*, int*)'
/tmp/cci2yPT9.o(.eh_frame+0x11): undefined reference to
`__gxx_personality_v0'
collect2: ld returned 1 exit status
zsh: exit 1 gcc -x c++ -o test test.cc -L/usr/X11R6/lib -lXinerama -lX11
-lXext
mizar:[/tmp] gcc -x c -o test test.cc -L/usr/X11R6/lib -lXinerama -lX11
-lXext
mizar:[/tmp]
-- System Information:
Debian Release: unstable
Architecture: i386
Kernel: Linux mizar 2.4.21-evms2.1.0-skas-3 #1 Thu Jul 17 09:01:34 EDT 2003 i686
Locale: LANG=en_US, LC_CTYPE=en_US
Versions of packages xlibs-dev depends on:
ii libc6-dev [libc-dev]2.3.2.ds1-10 GNU C Library: Development Librari
ii xlibs 4.2.1-14 X Window System client libraries
-- no debconf information
--
- mdz
Bug#210695: xlibmesa3 from security.d.o tries to overwrite libGLU.so.1.3 from xlibmesa3-glu
tags 210695 - security thanks On Sat, Sep 13, 2003 at 01:45:28AM +0200, Michael Below wrote: Package: xlibmesa3 Version: 4.1.0-16 Severity: important Tags: security I just tried installing the latest security fixes from security.debian.org. This failed for xlibmesa3: Entpacke Ersatz-xlibmesa3 ... dpkg: Fehler beim Bearbeiten von /var/cache/apt/archives/xlibmesa3_4.1.0-16woody1_i386.deb (--unpack): versuche /usr/X11R6/lib/libGLU.so.1.3 zu ?berschreiben, welches auch in Paket xlibmesa3-glu ist dpkg-deb: Unterprozess paste get?tet mit Signal (Daten?bergabe unterbrochen (broken pipe)) In english: error processing xlibmesa3: trying to overvrite libGLU.so.1.3 which is also in xlibmesa3-glu. Paste subprocess killed. The package information for xlibmesa3-glu reads: ii xlibmesa3-glu 4.2.1-6Mesa OpenGL utility library [XFree86] You are trying to install a security update for Debian stable on a system running Debian testing. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#210695: xlibmesa3 from security.d.o tries to overwrite libGLU.so.1.3 from xlibmesa3-glu
tags 210695 - security thanks On Sat, Sep 13, 2003 at 01:45:28AM +0200, Michael Below wrote: Package: xlibmesa3 Version: 4.1.0-16 Severity: important Tags: security I just tried installing the latest security fixes from security.debian.org. This failed for xlibmesa3: Entpacke Ersatz-xlibmesa3 ... dpkg: Fehler beim Bearbeiten von /var/cache/apt/archives/xlibmesa3_4.1.0-16woody1_i386.deb (--unpack): versuche /usr/X11R6/lib/libGLU.so.1.3 zu ?berschreiben, welches auch in Paket xlibmesa3-glu ist dpkg-deb: Unterprozess paste get?tet mit Signal (Daten?bergabe unterbrochen (broken pipe)) In english: error processing xlibmesa3: trying to overvrite libGLU.so.1.3 which is also in xlibmesa3-glu. Paste subprocess killed. The package information for xlibmesa3-glu reads: ii xlibmesa3-glu 4.2.1-6Mesa OpenGL utility library [XFree86] You are trying to install a security update for Debian stable on a system running Debian testing. -- - mdz
Re: xfree86_4.1.0-16woody1_ia64.changes REJECTED
On Tue, Sep 09, 2003 at 01:49:41PM -0500, Branden Robinson wrote: On Mon, Sep 08, 2003 at 06:02:24PM -0400, Debian Installer wrote: Mapping stable-security to proposed-updates. Rejected: no source found for xfree86 4.1.0-16woody1 (xlibmesa3_4.1.0-16woody1_ia64.deb). [etc.] I was told on IRC by mdz and elmo that I didn't need to upload an .orig.tar.gz to the SecurityQueue. Or does this even have anything to do with that? Is there something I can do to resolve this? This was something different; since I didn't get the build log, I asked bdale to upload the package for me, and neglected to mention that it was headed for stable-security rather than stable. It was rejected because there was no source package for it in proposed-updates (thankfully). This wasn't due to a missing .orig.tar.gz; this was a binary-only upload for a package where there was no source package (yet). It's now on stable-security and everything is fine. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xfree86_4.1.0-16woody1_ia64.changes REJECTED
On Tue, Sep 09, 2003 at 01:49:41PM -0500, Branden Robinson wrote: On Mon, Sep 08, 2003 at 06:02:24PM -0400, Debian Installer wrote: Mapping stable-security to proposed-updates. Rejected: no source found for xfree86 4.1.0-16woody1 (xlibmesa3_4.1.0-16woody1_ia64.deb). [etc.] I was told on IRC by mdz and elmo that I didn't need to upload an .orig.tar.gz to the SecurityQueue. Or does this even have anything to do with that? Is there something I can do to resolve this? This was something different; since I didn't get the build log, I asked bdale to upload the package for me, and neglected to mention that it was headed for stable-security rather than stable. It was rejected because there was no source package for it in proposed-updates (thankfully). This wasn't due to a missing .orig.tar.gz; this was a binary-only upload for a package where there was no source package (yet). It's now on stable-security and everything is fine. -- - mdz
Re: solved (was Re: project/experimental)
On Wed, Aug 13, 2003 at 10:22:10PM -0600, Bruce Sass wrote: [...problem installing XFree86-4.3.0-0pre1v1...] I needed: --- apt.conf --- APT::Default-Release experimental; --- (from a post to -user by Greg Folkert) It doesn't look like this is documented anywhere, anymore? Used to be in apt_preferences(5), from: http://lists.debian.org/debian-devel/2003/debian-devel-200303/msg01076.html It's documented in apt-get(8) and has been for as long as it has existed. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: solved (was Re: project/experimental)
On Wed, Aug 13, 2003 at 10:22:10PM -0600, Bruce Sass wrote: [...problem installing XFree86-4.3.0-0pre1v1...] I needed: --- apt.conf --- APT::Default-Release experimental; --- (from a post to -user by Greg Folkert) It doesn't look like this is documented anywhere, anymore? Used to be in apt_preferences(5), from: http://lists.debian.org/debian-devel/2003/debian-devel-200303/msg01076.html It's documented in apt-get(8) and has been for as long as it has existed. -- - mdz
Bug#15277: 15277: potato/default xaw library
On Tue, May 20, 2003 at 12:34:29PM +0200, Bill Allombert wrote: Bug 15277 against xaw3dg,xlib6g,xaw95 potato/default xaw library is tagged potato and is probably obsolete. It would be a decidedly good idea to send this information to the bug itself, so that it is recorded for anyone examining it, and so that the maintainer himself receives this information and can act appropriately. -- - mdz
Bug#171294: Fixed in CVS
In case you hadn't noticed already, there was a CVS change which claims to fix this. http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/xkb/ddxBeep.c.diff?r1=3.8r2=3.9 -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#171294: Fixed in CVS
In case you hadn't noticed already, there was a CVS change which claims to fix this. http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/xkb/ddxBeep.c.diff?r1=3.8r2=3.9 -- - mdz
Re: Configuration file handling (Re: [desktop] Unix configuration nightmare)
So I got to prototyping this, just to play around with it and see what worked. Then I was reading a thread on debian-mentors about Apache configuration, and I remembered how much of a pain that is currently. It occurred to me that a merging system could perhaps be used to make this sane. I'd like to think about this a bit and see if it affects any design decisions, so that this could be supported in the future at least. The basic idea would be for the package to modify a copy of the saved config file, rather than basing its modifications on the installed file. Example: - Package P wants to add a stanza to /etc/shared.conf - P asks for a copy of /etc/shared.conf to modify; we give it the installed copy - P makes its modifications and provides the resulting config file - We present the result as a proposed config file merge, as in the simple case discussed in previous messages in this thread - We store /etc/shared.conf as the last known revision for P - we apply the changes ...time passes... - A new version of package P comes along and wants to apply the same changes to /etc/shared.conf, not knowing if they are already present - P asks for a copy of /etc/shared.conf to modify, we give it the last known revision - P finds its changes already present, and no changes are made ...time passes, the admin decides he needs to change something that was added by P, and does so... - A new version of package P is installed. the above scenario repeats; it knows that it has already added its changes, without regard for whether they are actually present in the current /etc/shared.conf. The admin's changes are preserved, and disaster averted. ...time passes, and package P's needs change... - A new version of package P needs to make a different change to /etc/shared.conf, perhaps even one overlapping with the old change - P asks for the last known revision of /etc/shared.conf, applies its changes - We attempt to merge those changes into /etc/shared.conf. If they do not overlap with the admin's changes, then we present the result as a merge. If they do overlap, then a conflict results, and we resolve it as for the usual case. - We apply the changes requested by P to the last known revision, indicating that they have been resolved. Future releases of P find their changes already applied, and are satisfied. Similar actions would take place independently for each package which modifies the configuration file. Each package would be modifying its own view of the config file as it last saw it, and the changes merged into the installed version. Each new change made by the package only needs to be resolved once This scheme would provide for shared configuration files with the same user experience as configuration files which are owned by a single package. The only implementation detail is that we keep track of a separate revision of the config file for each package which modifies it. This does not seem like a high price to pay. This leads into a continuation of the question of how to store these files. Warn me now if using RCS in this application would bother you, because it's starting to look like it might be a good fit. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Configuration file handling (Re: [desktop] Unix configuration nightmare)
So I got to prototyping this, just to play around with it and see what worked. Then I was reading a thread on debian-mentors about Apache configuration, and I remembered how much of a pain that is currently. It occurred to me that a merging system could perhaps be used to make this sane. I'd like to think about this a bit and see if it affects any design decisions, so that this could be supported in the future at least. The basic idea would be for the package to modify a copy of the saved config file, rather than basing its modifications on the installed file. Example: - Package P wants to add a stanza to /etc/shared.conf - P asks for a copy of /etc/shared.conf to modify; we give it the installed copy - P makes its modifications and provides the resulting config file - We present the result as a proposed config file merge, as in the simple case discussed in previous messages in this thread - We store /etc/shared.conf as the last known revision for P - we apply the changes ...time passes... - A new version of package P comes along and wants to apply the same changes to /etc/shared.conf, not knowing if they are already present - P asks for a copy of /etc/shared.conf to modify, we give it the last known revision - P finds its changes already present, and no changes are made ...time passes, the admin decides he needs to change something that was added by P, and does so... - A new version of package P is installed. the above scenario repeats; it knows that it has already added its changes, without regard for whether they are actually present in the current /etc/shared.conf. The admin's changes are preserved, and disaster averted. ...time passes, and package P's needs change... - A new version of package P needs to make a different change to /etc/shared.conf, perhaps even one overlapping with the old change - P asks for the last known revision of /etc/shared.conf, applies its changes - We attempt to merge those changes into /etc/shared.conf. If they do not overlap with the admin's changes, then we present the result as a merge. If they do overlap, then a conflict results, and we resolve it as for the usual case. - We apply the changes requested by P to the last known revision, indicating that they have been resolved. Future releases of P find their changes already applied, and are satisfied. Similar actions would take place independently for each package which modifies the configuration file. Each package would be modifying its own view of the config file as it last saw it, and the changes merged into the installed version. Each new change made by the package only needs to be resolved once This scheme would provide for shared configuration files with the same user experience as configuration files which are owned by a single package. The only implementation detail is that we keep track of a separate revision of the config file for each package which modifies it. This does not seem like a high price to pay. This leads into a continuation of the question of how to store these files. Warn me now if using RCS in this application would bother you, because it's starting to look like it might be a good fit. -- - mdz
Re: Configuration file handling (Re: [desktop] Unix configuration nightmare)
On Mon, Oct 28, 2002 at 11:54:54PM -0500, Branden Robinson wrote: On Wed, Oct 23, 2002 at 08:10:43PM -0400, Matt Zimmerman wrote: I don't think that existing .config handling necessarily needs to change at this point, unless we want to provide a standard way to suppress all attempts at automatic configuration for a particular config file. Well, Joey Hess is of the opinion that manage this config file with debconf-style questions are Evil and Wrong. So, assuming I want to get with the Debconf orthodoxy, I would be changing my config scripts to eliminate this sort of prompting. I can't speak for joeyh, but I think his beef is that maintainers use this kind of question to be lazy about preserving changes. I'm guilty of this myself, because I do not want to parse some arbitrary config format using shell commands to seed debconf with the appropriate responses. We're all about preserving changes here, so the light of the One True Way should guide us to salvation. I was thinking of things more similar to --force-confnew/--force-confold than to manage this config file with debconf questions. In other maintainer scripts, we need to be able to say I have generated a configuration file /tmp/blah as a possible replacement for /etc/foo/bar. At that point, the maintainer script is done with the file, and passes control to us. Here we run into a problem: * For most packages, the other maintainer script is going to be the postinst. In fact it's difficult for me to imagine a scenario when anything but the postinst would be generating a config file.[1] From my perspective, the tool doesn't care from which maintainer script it's called. postinst would seem to be the only useful place to call it, I agree. * The postinst, by definition, runs during the configuration phase. Your proposal is going to pull us farther away from the utopia of being able to handle all interactivity before packages are even unpacked, a la dpkg-preconfigure. While dpkg's conffile prompts already violate this, they *can* be replaced with pre-unpack prompting, because dpkg-preconfigure can suck new conffiles out of a package just as well as it can config and templates files. Non-conffile config files cannot enjoy this luxury, because they don't exist within the package. Right. As we discussed on IRC, there seems to be a fundamental conflict between preconfiguration and generated configuration files because the package is by definition not configured yet (for the new version) at preconfiguration time. Packages with simple requirements could theoretically generate a configuration in .config, but that is not the right place for it, and packages with simple requirements can use conffiles. I had not considered that one day dpkg could prompt about conffiles ahead of time. That weakens my no worse than conffiles argument considerably. Preconfiguration should remain unchanged in (IMO) the two most important cases: initial installation, and novice user. In the former case, we will never need to prompt in postinst, and in the latter, we should have a reasonable default for them. * On the other hand, if we're doing an upgrade instead of an install, the tool(s) we use to generate the config file may already be on the system at pre-configure time. However, if those tools change, and a package's .config script needs to be able to use the config-generation tool that's in the corresponding version of the package, you'd need to have a way of declaring this requirement so that config file generation could be deferred to package configuration. Not to mention the fact that the runtime dependencies of the tools used to generate the configuration files would need to be present at pre-configure time. Oy vey. Yes, this would be a mess. Upgrades from one Debian release to the next would be fragile and difficult to maintain and test effectively. We check again whether the file has been modified since last time by comparing it to a saved copy or checksum (the copy is optional, but gives much more flexibility than storing only a checksum). Why not just a checksum? Do you have a specific application in mind, or do you think the copy is a good idea for the sake of people cleverer than we? :) The copy makes it possible to calculate the merge. Since I am pretty confident that we will want merges, I think we should go ahead and use the copy for the comparison as well. It might be marginally more efficient to cache checksums for the comparison, but I doubt it will be worth worrying about. [prompts for various cases] In the common cases, this should be possible with a single prompt, though it could be split into two phases or selected from either a simple or advanced method, or even suppressed entirely for novice users if a sane default action sequence could be decided (always preserve? merge, and if that fails, preserve? warn?). As you
Re: Configuration file handling (Re: [desktop] Unix configuration nightmare)
On Mon, Oct 28, 2002 at 11:54:54PM -0500, Branden Robinson wrote: On Wed, Oct 23, 2002 at 08:10:43PM -0400, Matt Zimmerman wrote: I don't think that existing .config handling necessarily needs to change at this point, unless we want to provide a standard way to suppress all attempts at automatic configuration for a particular config file. Well, Joey Hess is of the opinion that manage this config file with debconf-style questions are Evil and Wrong. So, assuming I want to get with the Debconf orthodoxy, I would be changing my config scripts to eliminate this sort of prompting. I can't speak for joeyh, but I think his beef is that maintainers use this kind of question to be lazy about preserving changes. I'm guilty of this myself, because I do not want to parse some arbitrary config format using shell commands to seed debconf with the appropriate responses. We're all about preserving changes here, so the light of the One True Way should guide us to salvation. I was thinking of things more similar to --force-confnew/--force-confold than to manage this config file with debconf questions. In other maintainer scripts, we need to be able to say I have generated a configuration file /tmp/blah as a possible replacement for /etc/foo/bar. At that point, the maintainer script is done with the file, and passes control to us. Here we run into a problem: * For most packages, the other maintainer script is going to be the postinst. In fact it's difficult for me to imagine a scenario when anything but the postinst would be generating a config file.[1] From my perspective, the tool doesn't care from which maintainer script it's called. postinst would seem to be the only useful place to call it, I agree. * The postinst, by definition, runs during the configuration phase. Your proposal is going to pull us farther away from the utopia of being able to handle all interactivity before packages are even unpacked, a la dpkg-preconfigure. While dpkg's conffile prompts already violate this, they *can* be replaced with pre-unpack prompting, because dpkg-preconfigure can suck new conffiles out of a package just as well as it can config and templates files. Non-conffile config files cannot enjoy this luxury, because they don't exist within the package. Right. As we discussed on IRC, there seems to be a fundamental conflict between preconfiguration and generated configuration files because the package is by definition not configured yet (for the new version) at preconfiguration time. Packages with simple requirements could theoretically generate a configuration in .config, but that is not the right place for it, and packages with simple requirements can use conffiles. I had not considered that one day dpkg could prompt about conffiles ahead of time. That weakens my no worse than conffiles argument considerably. Preconfiguration should remain unchanged in (IMO) the two most important cases: initial installation, and novice user. In the former case, we will never need to prompt in postinst, and in the latter, we should have a reasonable default for them. * On the other hand, if we're doing an upgrade instead of an install, the tool(s) we use to generate the config file may already be on the system at pre-configure time. However, if those tools change, and a package's .config script needs to be able to use the config-generation tool that's in the corresponding version of the package, you'd need to have a way of declaring this requirement so that config file generation could be deferred to package configuration. Not to mention the fact that the runtime dependencies of the tools used to generate the configuration files would need to be present at pre-configure time. Oy vey. Yes, this would be a mess. Upgrades from one Debian release to the next would be fragile and difficult to maintain and test effectively. We check again whether the file has been modified since last time by comparing it to a saved copy or checksum (the copy is optional, but gives much more flexibility than storing only a checksum). Why not just a checksum? Do you have a specific application in mind, or do you think the copy is a good idea for the sake of people cleverer than we? :) The copy makes it possible to calculate the merge. Since I am pretty confident that we will want merges, I think we should go ahead and use the copy for the comparison as well. It might be marginally more efficient to cache checksums for the comparison, but I doubt it will be worth worrying about. [prompts for various cases] In the common cases, this should be possible with a single prompt, though it could be split into two phases or selected from either a simple or advanced method, or even suppressed entirely for novice users if a sane default action sequence could be decided (always preserve? merge, and if that fails, preserve? warn?). As you
Configuration file handling (Re: [desktop] Unix configuration nightmare)
On Wed, Oct 23, 2002 at 02:02:12PM -0500, Branden Robinson wrote: Yes, now that I've written this mail, I've pretty much made up my mind. I like your idea. If the user dicks with the autogenerated file, we slam on the brakes and toss him into the manual configuration ghetto where he belongs. His changes are respected and he gets to RTF XF86Config-4(5) page. [...] Matt, I'd be more than happy to use xfree86 in unstable as a testbed for your proposal. If you agree, let's migrate this subthread over to debian-x. OK, let's spec things out a bit, then. I don't think that existing .config handling necessarily needs to change at this point, unless we want to provide a standard way to suppress all attempts at automatic configuration for a particular config file. In other maintainer scripts, we need to be able to say I have generated a configuration file /tmp/blah as a possible replacement for /etc/foo/bar. At that point, the maintainer script is done with the file, and passes control to us. We check again whether the file has been modified since last time by comparing it to a saved copy or checksum (the copy is optional, but gives much more flexibility than storing only a checksum). If it has not been modified, we overwrite the existing config with the new one, and update the saved copy to match. If the generated configuration file is identical to the existing one, then by some miracle, the user has made changes identical to what we would have made, and we update our saved copy of the config file and exit. If the files are different, then we attempt a merge, check whether it was successful, and interact with the user via debconf, explaining the situation and the result of the merge attempt (displaying a diff if the user cares about such things). At the end of the interaction, we should have decided on one of these courses of action: - Throw away the admin's changes to the file and replace it with the new one entirely (conffile 'y') - Ignore the package maintainer's changes to the file and keep the existing one (conffile 'n') - Merge the package maintainer's changes and give the user a chance to fix things up manually before continuing - (this option is only available if the merge was successful) Merge the package maintainer's changes and continue without further interaction In the common cases, this should be possible with a single prompt, though it could be split into two phases or selected from either a simple or advanced method, or even suppressed entirely for novice users if a sane default action sequence could be decided (always preserve? merge, and if that fails, preserve? warn?). At package build time, the source package machinery only needs to indicate which binary packages will be making use of the infrastructure, and a helper will ensure that the necessary templates are included and generate dependency substitutions. Rebuilding a package will automatically pull in the latest, best-translated templates from the helper. Open questions: - What should happen at preconfiguration time to minimize interaction for novice users? - What sort of preferences would be useful, either at a global scope or a per-package scope? always leave my foobar config alone always merge my changes if there are no merge conflicts Implementation issues: - How to store the saved config files, so that it is intuitively obvious to which package they belong, and their installed location, so that they are conveniently available to the admin? This should be a public interface. - Will it be necessary or desirable to modify debhelper so that there is a substitution interface for templates, similar to what is done for maintainer scripts? -- - mdz
Configuration file handling (Re: [desktop] Unix configuration nightmare)
On Wed, Oct 23, 2002 at 02:02:12PM -0500, Branden Robinson wrote: Yes, now that I've written this mail, I've pretty much made up my mind. I like your idea. If the user dicks with the autogenerated file, we slam on the brakes and toss him into the manual configuration ghetto where he belongs. His changes are respected and he gets to RTF XF86Config-4(5) page. [...] Matt, I'd be more than happy to use xfree86 in unstable as a testbed for your proposal. If you agree, let's migrate this subthread over to debian-x. OK, let's spec things out a bit, then. I don't think that existing .config handling necessarily needs to change at this point, unless we want to provide a standard way to suppress all attempts at automatic configuration for a particular config file. In other maintainer scripts, we need to be able to say I have generated a configuration file /tmp/blah as a possible replacement for /etc/foo/bar. At that point, the maintainer script is done with the file, and passes control to us. We check again whether the file has been modified since last time by comparing it to a saved copy or checksum (the copy is optional, but gives much more flexibility than storing only a checksum). If it has not been modified, we overwrite the existing config with the new one, and update the saved copy to match. If the generated configuration file is identical to the existing one, then by some miracle, the user has made changes identical to what we would have made, and we update our saved copy of the config file and exit. If the files are different, then we attempt a merge, check whether it was successful, and interact with the user via debconf, explaining the situation and the result of the merge attempt (displaying a diff if the user cares about such things). At the end of the interaction, we should have decided on one of these courses of action: - Throw away the admin's changes to the file and replace it with the new one entirely (conffile 'y') - Ignore the package maintainer's changes to the file and keep the existing one (conffile 'n') - Merge the package maintainer's changes and give the user a chance to fix things up manually before continuing - (this option is only available if the merge was successful) Merge the package maintainer's changes and continue without further interaction In the common cases, this should be possible with a single prompt, though it could be split into two phases or selected from either a simple or advanced method, or even suppressed entirely for novice users if a sane default action sequence could be decided (always preserve? merge, and if that fails, preserve? warn?). At package build time, the source package machinery only needs to indicate which binary packages will be making use of the infrastructure, and a helper will ensure that the necessary templates are included and generate dependency substitutions. Rebuilding a package will automatically pull in the latest, best-translated templates from the helper. Open questions: - What should happen at preconfiguration time to minimize interaction for novice users? - What sort of preferences would be useful, either at a global scope or a per-package scope? always leave my foobar config alone always merge my changes if there are no merge conflicts Implementation issues: - How to store the saved config files, so that it is intuitively obvious to which package they belong, and their installed location, so that they are conveniently available to the admin? This should be a public interface. - Will it be necessary or desirable to modify debhelper so that there is a substitution interface for templates, similar to what is done for maintainer scripts? -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: woody : X install
On Mon, Oct 21, 2002 at 05:21:00PM -0500, Branden Robinson wrote: On Mon, Oct 21, 2002 at 05:21:00PM -0400, Colin Walters wrote: Speaking with my Debian Desktop hat on, I would prefer it if you took the approach of just trying what the autodetection tools said, and only if that fails, offer the user a choice of options. The Debconf spec won't let me do that. If DEBIAN_PRIORITY is low, I need to grind to a halt and wait for the user to confirm, e.g., the usage of the XFree86 server and tdfx driver for his Voodoo3 3000 card. If DEBIAN_PRIORITY is low, then this is exactly what the user is asking for. They want to see everything, even questions that have an appropriate default. If the autodetection tools give incorrect information, then that's a bug in those tools we should fix. If the X server doesn't get enough information from the autodetection tools, then we should fix that. I agree, but there is simply no way to completely eliminate the interactivity, *even if* the autodetection tools work perfectly, and still play the Debconf game. Anyone who is bewildered by technical questions should have their priority set to high. Nearly everything should be non-interactive at that point, unless something goes wrong. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: testers wanted for xfree86 4.1.0-14pre15v1
On Fri, Mar 08, 2002 at 05:17:13PM -0500, Branden Robinson wrote: crass bribeThe sooner I can put this release to bed, the sooner I can work on 4.2.0./crass bribe Experimental versions of the X packages are available at my repository. Please test these so that 4.1.0-15 can be a solid release, worthy of the woody release. Please direct feedback to the debian-x list. I upgraded to these packages on a relatively full-featured desktop system with xinerama, GNOME, etc. Installation proceeded without incident, and everything continued to be functional. I thought that the system needed the fix for #127749 due to weirdly scaled truetype fonts. Unfortunately, even though the DPI values are now correctly calculated, the fonts are still tall and skinny. Must be something else... -- - mdz
Re: XFree 4.0.3 and 4.1 on s390
On Sun, Jul 01, 2001 at 07:19:33AM +0200, Gerhard Tonn wrote: The following links are broken. I don't know if it's s390 specific. These are normal. libfoo-dev will contain a symlink libfoo.so, which points to the shared library in the libfoo package. See http://www.debian.org/doc/debian-policy/ch-sharedlibs.html for more information. The manual pages are mostly symlinks to undocumented(7). How much of XFree86 are you building? I assume you don't have an S/390 with a graphics adapter. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree 4.0.3 and 4.1 on s390
On Sun, Jul 01, 2001 at 07:19:33AM +0200, Gerhard Tonn wrote: The following links are broken. I don't know if it's s390 specific. These are normal. libfoo-dev will contain a symlink libfoo.so, which points to the shared library in the libfoo package. See http://www.debian.org/doc/debian-policy/ch-sharedlibs.html for more information. The manual pages are mostly symlinks to undocumented(7). How much of XFree86 are you building? I assume you don't have an S/390 with a graphics adapter. -- - mdz
