Bug#116507: refinance timothy gravelle
To : timothy gravelle We spoke yesterday and I'd like to go over everything now. Please check the info below and well me if you have any questions. b1ked33d96.com/v We're accepting your app. Your status has been accepted. We need to confirm your information one more time. Just visit the link above and fill out our final form. Sincerely, Alba -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349318: libxft-dev: please do not export unnecessary libraries in xft.pc
Package: libxft-dev
Version: 2.1.7-1
Severity: important
Tags: upstream
Hi folks,
So, I suppose most of you have read
http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html about
problems with packages depending on libraries that they don't use,
particularly as relates to a potential libfreetype transition. One library
that currently exposes freetype (and other libs) in its pkg-config .pc file,
but shouldn't, is libxft.
Please consider (and forward upstream) the attached patch which moves all of
the library dependencies of libxft into the Libs.private variable in xft.pc,
so that they aren't used on Debian except for static linking. I have not
touched the 'Requires' field; even though packages which link to libXft
should not need to link to libfontconfig, the pkg-config 'Requires' field
controls both CPPFLAGS and LDFLAGS, and Xft includes fontconfig headers --
unfortunately the pkg-config maintainer has not been convinced that CPPFLAGS
from Requires.private should be propagated, despite the fact that there are
many examples of this scenario in Debian... (this is bug #340904, for those
who care.)
FWIW, since September 2003 FreeType has supported pkg-config; however, I
wouldn't recommend that Xft use pkg-config dependencies for libfreetype
unless this Requires.private CPPFLAGS issue is resolved. :/
Oh, also, there seems to be a pre-existing bug in this .pc file, in that
-lX11 is specified for static linking, but -L/usr/X11R6/lib is not...
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
diff -u xft-2.1.7/debian/changelog xft-2.1.7/debian/changelog
--- xft-2.1.7/debian/changelog
+++ xft-2.1.7/debian/changelog
@@ -1,3 +1,11 @@
+xft (2.1.7-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix xft.pc to not export freetype and xrender as part of the interface
+used for shared linking; expose them only in Libs.private instead.
+
+ -- Steve Langasek [EMAIL PROTECTED] Sun, 22 Jan 2006 02:32:25 -0800
+
xft (2.1.7-1) unstable; urgency=low
* New upstream release.
only in patch2:
unchanged:
--- xft-2.1.7.orig/xft.pc.in
+++ xft-2.1.7/xft.pc.in
@@ -11,5 +11,6 @@
Description: X FreeType library
Version: @VERSION@
Requires: fontconfig
-Libs: -L${libdir} -lXft -lX11 ${freetypelibs} ${xrenderlibs}
+Libs: -L${libdir} -lXft
+Libs.private: -lX11 ${freetypelibs} ${xrenderlibs}
Cflags: -I${includedir} ${freetypecflags} ${xrendercflags}
signature.asc
Description: Digital signature
Bug#349318: libxft-dev: please do not export unnecessary libraries in xft.pc
tags 349318 + fixed-upstream On Sun, Jan 22, 2006 at 02:44:28AM -0800, Steve Langasek wrote: So, I suppose most of you have read http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html about problems with packages depending on libraries that they don't use, particularly as relates to a potential libfreetype transition. One library that currently exposes freetype (and other libs) in its pkg-config .pc file, but shouldn't, is libxft. Please consider (and forward upstream) the attached patch which moves all of the library dependencies of libxft into the Libs.private variable in xft.pc, so that they aren't used on Debian except for static linking. I have not touched the 'Requires' field; even though packages which link to libXft should not need to link to libfontconfig, the pkg-config 'Requires' field controls both CPPFLAGS and LDFLAGS, and Xft includes fontconfig headers -- unfortunately the pkg-config maintainer has not been convinced that CPPFLAGS from Requires.private should be propagated, despite the fact that there are many examples of this scenario in Debian... (this is bug #340904, for those who care.) FWIW, since September 2003 FreeType has supported pkg-config; however, I wouldn't recommend that Xft use pkg-config dependencies for libfreetype unless this Requires.private CPPFLAGS issue is resolved. :/ Oh, also, there seems to be a pre-existing bug in this .pc file, in that -lX11 is specified for static linking, but -L/usr/X11R6/lib is not... This has already been fixed in the modular tree (/cvs/xorg/lib, as opposed to /cvs/xlibs). But I guess the CPPFLAGS scenario remains. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#349318: libxft-dev: please do not export unnecessary libraries in xft.pc
Processing commands for [EMAIL PROTECTED]: tags 349318 + fixed-upstream Bug#349318: libxft-dev: please do not export unnecessary libraries in xft.pc Tags were: upstream Tags added: fixed-upstream On Sun, Jan 22, 2006 at 02:44:28AM -0800, Steve Langasek wrote: Unknown command or malformed arguments to command. So, I suppose most of you have read Unknown command or malformed arguments to command. http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html about Unknown command or malformed arguments to command. problems with packages depending on libraries that they don't use, Unknown command or malformed arguments to command. particularly as relates to a potential libfreetype transition. One library Unknown command or malformed arguments to command. Too many unknown commands, stopping here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349318: libxft-dev: please do not export unnecessary libraries in xft.pc
On Sun, Jan 22, 2006 at 10:57:12AM +, Daniel Stone wrote: tags 349318 + fixed-upstream On Sun, Jan 22, 2006 at 02:44:28AM -0800, Steve Langasek wrote: So, I suppose most of you have read http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html about problems with packages depending on libraries that they don't use, particularly as relates to a potential libfreetype transition. One library that currently exposes freetype (and other libs) in its pkg-config .pc file, but shouldn't, is libxft. Please consider (and forward upstream) the attached patch which moves all of the library dependencies of libxft into the Libs.private variable in xft.pc, so that they aren't used on Debian except for static linking. I have not touched the 'Requires' field; even though packages which link to libXft should not need to link to libfontconfig, the pkg-config 'Requires' field controls both CPPFLAGS and LDFLAGS, and Xft includes fontconfig headers -- unfortunately the pkg-config maintainer has not been convinced that CPPFLAGS from Requires.private should be propagated, despite the fact that there are many examples of this scenario in Debian... (this is bug #340904, for those who care.) FWIW, since September 2003 FreeType has supported pkg-config; however, I wouldn't recommend that Xft use pkg-config dependencies for libfreetype unless this Requires.private CPPFLAGS issue is resolved. :/ Oh, also, there seems to be a pre-existing bug in this .pc file, in that -lX11 is specified for static linking, but -L/usr/X11R6/lib is not... This has already been fixed in the modular tree (/cvs/xorg/lib, as opposed to /cvs/xlibs). But I guess the CPPFLAGS scenario remains. Excellent. I don't suppose there's any ETA for this fix making it to unstable? I've found at least one package that could benefit from it, and I imagine there are plenty more. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#349348: xserver-xorg: gamma should be set by configure
Package: xserver-xorg Version: 6.8.2.dfsg.1-11 Severity: wishlist I think the configure process should set a sensible gamma value. If not set, gamma defaults to 1.0, and this does not make sense. I recommend 1.8 (the Macintosh default), MS Windows uses 2.2. Setting a proper gamma value helps to display colors more accurately. Thanks. Michael Below -- Package-specific info: Contents of /var/lib/xfree86/X.roster: xserver-xfree86 xserver-xorg /etc/X11/X target unchanged from checksum in /var/lib/xfree86/X.md5sum. X server symlink status: lrwxrwxrwx 1 root root 17 2005-11-16 14:51 /etc/X11/X - /usr/bin/X11/Xorg -rwxr-xr-x 1 root root 1833112 2005-11-29 09:48 /usr/bin/X11/Xorg Contents of /var/lib/xfree86/xorg.conf.roster: VGA-compatible devices on PCI bus: :01:05.0 VGA compatible controller: nVidia Corporation NV10 [GeForce 256 SDR] (rev 10) /etc/X11/xorg.conf unchanged from checksum in /var/lib/xfree86/xorg.conf.md5sum. Xorg X server configuration file status: -rw--- 1 root root 3150 2006-01-19 13:44 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: Xorg X server log files on system: -rw-r--r-- 1 root root 29853 2006-01-22 14:25 /var/log/Xorg.0.log Contents of most recent Xorg X server log file /var/log/Xorg.0.log: X Window System Version 6.8.2 (Debian 6.8.2.dfsg.1-11 20051129054125 David Nusinow [EMAIL PROTECTED]) Release Date: 9 February 2005 X Protocol Version 11, Revision 0, Release 6.8.2 Build Operating System: Linux 2.6.14-2-686 i686 [ELF] Current Operating System: Linux tucholsky 2.6.12 #1 Wed Nov 23 17:32:28 MET 2005 i686 Build Date: 29 November 2005 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present OS Kernel: Linux version 2.6.12 ([EMAIL PROTECTED]) (gcc version 4.0.2 (Debian 4.0.2-2)) #1 Wed Nov 23 17:32:28 MET 2005 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sun Jan 22 14:18:42 2006 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout Default Layout (**) |--Screen Default Screen (0) (**) | |--Monitor Belinea 10 70 30 (**) | |--Device Asus V6600 (**) |--Input Device Generic Keyboard (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc105 (**) XKB: model: pc105 (**) Option XkbLayout de (**) XKB: layout: de (**) Option XkbOptions nodeadkeys (**) XKB: options: nodeadkeys (==) Keyboard: CustomKeycode disabled (**) |--Input Device Configured Mouse (**) |--Input Device Generic Mouse (WW) The directory /usr/lib/X11/fonts/CID does not exist. Entry deleted from font path. (**) FontPath set to /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,unix/:7100,/usr/lib/X11/fonts/misc,/usr/lib/X11/fonts/cyrillic,/usr/lib/X11/fonts/100dpi/:unscaled,/usr/lib/X11/fonts/75dpi/:unscaled,/usr/lib/X11/fonts/Type1,/usr/lib/X11/fonts/Speedo (==) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (WW) Open APM failed (/dev/apm_bios) (No such file or directory) (II) Module ABI versions: X.Org ANSI C Emulation: 0.2 X.Org Video Driver: 0.7 X.Org XInput driver : 0.4 X.Org Server Extension : 0.2 X.Org Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=X.Org Foundation compiled for 6.8.2, module version = 1.0.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=X.Org Foundation compiled for 6.8.2, module version = 1.0.0 ABI class: X.Org Video Driver, version 0.7 (++) using VT number 9 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1022,7006 card , rev 23 class 06,00,00 hdr 80 (II) PCI: 00:01:0: chip 1022,7007 card , rev 01 class 06,04,00 hdr 81 (II) PCI: 00:07:0: chip 1022,7408 card , rev 01 class 06,01,00 hdr 80 (II) PCI: 00:07:1: chip 1022,7409 card , rev 03 class 01,01,8a hdr 00 (II) PCI: 00:07:3: chip 1022,740b card , rev 03 class 06,80,00 hdr 00 (II) PCI: 00:07:4: chip 1022,740c card , rev 06 class 0c,03,10 hdr 00 (II) PCI: 00:08:0: chip 109e,036e card 0070,13eb rev 11 class 04,00,00 hdr 80 (II) PCI: 00:08:1: chip 109e,0878 card 0070,13eb rev 11 class 04,80,00 hdr 80 (II) PCI: 00:0a:0: chip 11f6,1401 card , rev 0a class 02,00,00 hdr 00 (II) PCI: 00:0b:0: chip 1814,0201 card 1814,2560 rev 01 class 02,80,00 hdr 00 (II) PCI: 01:05:0: chip 10de,0100 card 1043,4008 rev 10 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O
Re:
Whittaker Cassie
Re:
Nicholson Alisha
Bug#166515: Thank you
Just wanted to say thanks for everything. If you need anything please don't hesistate to ask. Clifton -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#198386: Check it out
Just wanted to say thanks for everything. If you need anything please don't hesistate to ask. Hodge -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
X Strike Force X.Org X11 SVN commit: r1104 - branches/modular/lib/mesa-6.4.1/debian
Author: dnusinow
Date: 2006-01-22 14:50:19 -0500 (Sun, 22 Jan 2006)
New Revision: 1104
Modified:
branches/modular/lib/mesa-6.4.1/debian/changelog
branches/modular/lib/mesa-6.4.1/debian/control
branches/modular/lib/mesa-6.4.1/debian/mesa-swx11-source.install
Log:
* mesa-swrast-src.install stop looking for the swx11 dir and look for swrast
Modified: branches/modular/lib/mesa-6.4.1/debian/changelog
===
--- branches/modular/lib/mesa-6.4.1/debian/changelog2006-01-22 00:07:07 UTC
(rev 1103)
+++ branches/modular/lib/mesa-6.4.1/debian/changelog2006-01-22 19:50:19 UTC
(rev 1104)
@@ -37,8 +37,9 @@
* Change libgl1-mesa-swrast Depends on libx11-6-dev to libx11-dev.
* Change libgl1-mesa-swrast to be named libgl1-mesa-swx11
* Change libgl1-mesa to be named libgl1-mesa-glx
+ * mesa-swrast-src.install stop looking for the swx11 dir and look for swrast
- -- David Nusinow [EMAIL PROTECTED] Sat, 21 Jan 2006 18:37:50 -0500
+ -- David Nusinow [EMAIL PROTECTED] Sat, 21 Jan 2006 21:43:37 -0500
mesa (6.3.2-2.1) unstable; urgency=low
Modified: branches/modular/lib/mesa-6.4.1/debian/control
===
--- branches/modular/lib/mesa-6.4.1/debian/control 2006-01-22 00:07:07 UTC
(rev 1103)
+++ branches/modular/lib/mesa-6.4.1/debian/control 2006-01-22 19:50:19 UTC
(rev 1104)
@@ -99,7 +99,7 @@
Package: libgl1-mesa-dev
Section: libs
Architecture: any
-Depends: ${shlibs:Depends}, libc6-dev, mesa-common-dev (= ${Source-Version}),
libgl1-mesa-glx (=${Source-Version}), libgl1-mesa-dri (={Source-Version})
+Depends: ${shlibs:Depends}, libc6-dev, mesa-common-dev (= ${Source-Version}),
libgl1-mesa-glx (=${Source-Version}), libgl1-mesa-dri (= ${Source-Version})
Conflicts: libgl-dev, libgl1-mesa-dri-dev
Replaces: libgl-dev, libgl1-mesa-dri-dev
Provides: libgl-dev, libgl1-mesa-dri-dev
Modified: branches/modular/lib/mesa-6.4.1/debian/mesa-swx11-source.install
===
--- branches/modular/lib/mesa-6.4.1/debian/mesa-swx11-source.install
2006-01-22 00:07:07 UTC (rev 1103)
+++ branches/modular/lib/mesa-6.4.1/debian/mesa-swx11-source.install
2006-01-22 19:50:19 UTC (rev 1104)
@@ -144,73 +144,73 @@
src/mesa/array_cache/ac_context.h usr/share/mesa-source/src/mesa/array_cache
src/mesa/array_cache/ac_import.c usr/share/mesa-source/src/mesa/array_cache
src/mesa/array_cache/acache.h usr/share/mesa-source/src/mesa/array_cache
-src/mesa/swx11/s_aaline.c usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_aaline.h usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_aalinetemp.h usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_aatriangle.c usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_aatriangle.h usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_aatritemp.h usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_accum.c usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_accum.h usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_alpha.c usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_alpha.h usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_atifragshader.c usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_atifragshader.h usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_bitmap.c usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_blend.c usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_blend.h usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_buffers.c usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_context.c usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_context.h usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_copypix.c usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_depth.c usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_depth.h usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_drawpix.c usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_drawpix.h usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_feedback.c usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_feedback.h usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_fog.c usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_fog.h usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_fragprog_to_c.c usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_imaging.c usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_lines.c usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_lines.h usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_linetemp.h usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_logic.c usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_logic.h usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_masking.c usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_masking.h usr/share/mesa-source/src/mesa/swx11
-src/mesa/swx11/s_nvfragprog.c usr/share/mesa-source/src/mesa/swx11
Mesa Transition
Hi all, This morning I realized that there's a transition I'd forgotten about that we'll need to put the archive through for 7.0. As the subject says, that's the mesa transition. Since all of our xlibs*mesa packages and such are going away in favor of those built from the mesa source package, we're going to have to transition everyone over to the standalone mesa packages. I'm working on lists of packages that depend and build-depend on the Xorg mesa packages right now so we have something concrete to send out to people. We'll probably have to do another mass bug filling, like with xlibs-dev, and it should be about as easy as with xlibs-dev, since people can just substitute the old lib for the new one. Fortunately, xlibs-dev went fast, and I think we can get an equally fast one for these packages. I'm planning on informing the release team about this soon, but I'd like to hear comments from everyone here on this. We can feasibly provide transitional packages from the mesa source package, but I'd personally rather just do this cleanly and force everyone over to the new packages. Thoughts? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349412: xserver-xorg: vt switching problem: second display/screen is not restored correctly
Package: xserver-xorg Version: 6.9.0.dfsg.1-4 Severity: normal Graphics chip: nVidia 6800 Graphics memory: 128 MB Driver: nv I use an X server with 1600x1200 pixels on vt7, 85 Hz as first display. Then I have started another X server on vt8 with: startx -display :1 -- :1 -depth 16 -nolisten tcp -verbose 5 -logverbose 5 And I typed a command to initiate scrolling action into xterm on vt8: $ cd ~ $ ls -R After switching back (CTRL-ALT-F7) and forth (CTRL-ALT-F8) a few times, the second X server could not restore the screen (see below). With the scrolling action above, it can be reproduced at once. The first screen (desktop) could be restored every time, no problem here. Effect: Black screen, grey line strokes (about 20 pixels wide) are drawn horizontally, with a big offset left black. Visual appearance: Columns full of line strokes, about every tenth line, alternating pattern: full - dotted (4 dots). Smooth scrolling of the whole screen upwards, as if it is a corrupted font which is drawn continuously. Other effects: Lower part of the screen blue, blue line strokes (full and dotted) are drawn. No black background, a pattern is drawn (colors not changing horizontally per block), moving down row per row. With nvidia driver 1.0.8178: same effect. With Xorg 6.8.2/nvidia 1.0.8178: no problems. It is a regression. Killing the above process with CTRL-C gives: ++ xterm: fatal IO error 32 (Broken pipe) or KillClient on X server :1.0 waiting for X server to shut down FreeFontPath: FPE /usr/X11R6/lib/X11/fonts/misc/ refcount is 2, should be 1; fixing. ++ -- Package-specific info: Contents of /var/lib/xfree86/X.roster: xserver-xfree86 xserver-xorg /etc/X11/X target unchanged from checksum in /var/lib/xfree86/X.md5sum. X server symlink status: lrwxrwxrwx 1 root root 17 Jan 10 06:38 /etc/X11/X - /usr/bin/X11/Xorg -rwxr-xr-x 1 root root 1878044 Jan 15 02:40 /usr/bin/X11/Xorg Contents of /var/lib/xfree86/xorg.conf.roster: xserver-xorg VGA-compatible devices on PCI bus: :01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 0041 (rev a1) :01:00.0 Class 0300: 10de:0041 (rev a1) /var/lib/xfree86/xorg.conf.md5sum does not exist. Xorg X server configuration file status: -rw-r--r-- 1 root root 2936 Jan 22 21:00 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: Section ServerLayout Identifier XFree86 Configured Screen 0 Screen0 0 0 InputDeviceMouse0 CorePointer InputDeviceMouse1 SendCoreEvents InputDeviceKeyboard0 CoreKeyboard EndSection Section ServerFlags #Option AllowMouseOpenFail true EndSection Section Files RgbPath /usr/X11R6/lib/X11/rgb ModulePath /usr/X11R6/lib/modules FontPath /usr/X11R6/lib/X11/fonts/misc/ # FontPath /usr/X11R6/lib/X11/fonts/Speedo/ FontPath /usr/X11R6/lib/X11/fonts/Type1/ FontPath /usr/X11R6/lib/X11/fonts/CID/ FontPath /usr/X11R6/lib/X11/fonts/75dpi/ FontPath /usr/X11R6/lib/X11/fonts/100dpi/ FontPath /var/lib/defoma/x-ttcidfont-conf.d/dirs/CID FontPath /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType EndSection Section Module # Load GLcore Load dbe # Load dri Load extmod Load glx Load pex5 Load record Load xie Load type1 # Load speedo Load freetype Load v4l EndSection Section InputDevice Identifier Keyboard0 Driver keyboard Option CoreKeyboard # Option Protocol Standard Option XkbRules xfree86 Option XkbModel pc105 Option XkbLayout de EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Protocol PS/2 Option Device /dev/psaux # Option SendCoreEvents true # Emulate3Buttons # Emulate3Timeout 70 EndSection Section InputDevice Identifier Mouse1 Driver mouse Option Protocol Auto Option Device /dev/input/mice Option ZAxisMapping 4 5 Option SendCoreEvents true EndSection Section Monitor Identifier eizof78 VendorName Eizo ModelNameF78 HorizSync30-110 VertRefresh 50-160 EndSection Section Device Identifier Card0 Driver nv VendorName NVidia BoardName GeForce 6800 128MB BusID PCI:1:0:0 EndSection Section Screen Identifier Screen0 Device Card0 Monitoreizof78 DefaultDepth 24 SubSection Display Depth 1 Modes 1600x1200 1152x864 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 4 Modes 1600x1200 1152x864 1024x768 800x600
Processed: tagging 349203
Processing commands for [EMAIL PROTECTED]: tags 349203 + upstream Bug#349203: xserver-xorg: Keyboard scancode translation for Hurd Tags were: patch Tags added: upstream End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 348011
Processing commands for [EMAIL PROTECTED]: tags 348011 + upstream Bug#348011: xorg-x11: Hurd /tmp/X11-unix/.X fixup Tags were: pending patch Tags added: upstream End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: bug 348011 is forwarded to can find the patch:
Processing commands for [EMAIL PROTECTED]: forwarded 348011 can find the patch: Bug#348011: xorg-x11: Hurd /tmp/X11-unix/.X fixup Noted your statement that Bug has been forwarded to can find the patch:. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: bug 349203 is forwarded to https://bugs.freedesktop.org/show_bug.cgi?id=5537
Processing commands for [EMAIL PROTECTED]: forwarded 349203 https://bugs.freedesktop.org/show_bug.cgi?id=5537 Bug#349203: xserver-xorg: Keyboard scancode translation for Hurd Noted your statement that Bug has been forwarded to https://bugs.freedesktop.org/show_bug.cgi?id=5537. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: bug 348011 is forwarded to https://bugs.freedesktop.org/show_bug.cgi?id=5537
Processing commands for [EMAIL PROTECTED]: forwarded 348011 https://bugs.freedesktop.org/show_bug.cgi?id=5537 Bug#348011: xorg-x11: Hurd /tmp/X11-unix/.X fixup Forwarded-to-address changed from can find the patch: to https://bugs.freedesktop.org/show_bug.cgi?id=5537. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349318: libxft-dev: please do not export unnecessary libraries in xft.pc
On Sun, Jan 22, 2006 at 04:18:21AM -0800, Steve Langasek wrote: On Sun, Jan 22, 2006 at 10:57:12AM +, Daniel Stone wrote: tags 349318 + fixed-upstream On Sun, Jan 22, 2006 at 02:44:28AM -0800, Steve Langasek wrote: So, I suppose most of you have read http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html about problems with packages depending on libraries that they don't use, particularly as relates to a potential libfreetype transition. One library that currently exposes freetype (and other libs) in its pkg-config .pc file, but shouldn't, is libxft. Please consider (and forward upstream) the attached patch which moves all of the library dependencies of libxft into the Libs.private variable in xft.pc, so that they aren't used on Debian except for static linking. I have not touched the 'Requires' field; even though packages which link to libXft should not need to link to libfontconfig, the pkg-config 'Requires' field controls both CPPFLAGS and LDFLAGS, and Xft includes fontconfig headers -- unfortunately the pkg-config maintainer has not been convinced that CPPFLAGS from Requires.private should be propagated, despite the fact that there are many examples of this scenario in Debian... (this is bug #340904, for those who care.) FWIW, since September 2003 FreeType has supported pkg-config; however, I wouldn't recommend that Xft use pkg-config dependencies for libfreetype unless this Requires.private CPPFLAGS issue is resolved. :/ Oh, also, there seems to be a pre-existing bug in this .pc file, in that -lX11 is specified for static linking, but -L/usr/X11R6/lib is not... This has already been fixed in the modular tree (/cvs/xorg/lib, as opposed to /cvs/xlibs). But I guess the CPPFLAGS scenario remains. Excellent. I don't suppose there's any ETA for this fix making it to unstable? I've found at least one package that could benefit from it, and I imagine there are plenty more. I'm working on it. The mesa NMU will go in shortly, and after that I need to figure out exactly how to handle the transition to FHS compliance. I'm not entirely sure I'm happy with how Daniel did it (although I've yet to look at it closely). I'm going to do a full analysis and post an RFC either on debian-x or debian-devel about it. Once that's figured out, the libs, drivers, and server can all go in to experimental, as they're finished right now. Following that, there's some work to be done on bundling the apps and packaging a few miscellaneous things that shouldn't take too long. If it all works, I'm going to throw it to unstable and see how it goes. I can't give you a real time line for this, since it's been mainly me doing this on the Debian side so far, but I'm hoping to get all of modular in to unstable within the next two or three months, but it's possible that it'll go faster. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347680: Xorg breaks acpid
On Jan 12, Mattia Dongili [EMAIL PROTECTED] wrote: No. That's the kernel only supporting a single reader for /proc/acpi/event. I'm cooking a patch to support multiple readers (based on an old and never applied patch) but I doubt it will be accepted mainline. /proc/acpi/event contention has _always_ been a problem and the only solution is to support multiple readers, not to require acpid's socket, that's just ridiculous :) It's not up to you to decide that a kernel interface is wrong, at least without the ACPI maintainer agreeing. Arguing that this will be fixed by a kernel patch which does not exist and will probably be rejected (and even if it were accepted would be in Debian kernels in a 2-4 months timeframe) is not acceptable, this needs to be fixed in X (I suggest by retrying to open the socket if it worked the first time). breaks unrelated software is one of the criteria for critical bugs, and even if 6.9 needs to move to testing ASAP it's not a reason to take this bug lightly. With my patch if acpid dies xorg reopens /proc/acpi/event. So, I'd say this is either an acpid bug (start earlier?) or better yet a kernel bug. Wrong, because acpid is normally restarted during the X server life cycle (on upgrades and by logrotate) so X needs to cope with it. -- ciao, Marco signature.asc Description: Digital signature
Bug#347680: Xorg breaks acpid
On Sun, Jan 22, 2006 at 11:24:15PM +0100, Marco d'Itri wrote: On Jan 12, Mattia Dongili [EMAIL PROTECTED] wrote: No. That's the kernel only supporting a single reader for /proc/acpi/event. I'm cooking a patch to support multiple readers (based on an old and never applied patch) but I doubt it will be accepted mainline. /proc/acpi/event contention has _always_ been a problem and the only solution is to support multiple readers, not to require acpid's socket, that's just ridiculous :) It's not up to you to decide that a kernel interface is wrong, at least without the ACPI maintainer agreeing. of course, but I'm still convinced that not supporting multiple readers for /proc/acpi/event is a bad idea. And the fact that nowadays also X wants to read it makes it even worse. Arguing that this will be fixed by a kernel patch which does not exist and will probably be rejected (and even if it were accepted would be in Debian kernels in a 2-4 months timeframe) is not acceptable, this needs It's already been rejected once (quite a long time ago) and I don't expect it to be applied in the future as it's an ugly hack IMO (and I still haven't found any time to rebase it against current kernels). to be fixed in X (I suggest by retrying to open the socket if it worked the first time). this is exactely what the patch I submitted here does. But it does only once, so if the socket is not there on the first retry it'll steal /proc/acpi/event. breaks unrelated software is one of the criteria for critical bugs, and even if 6.9 needs to move to testing ASAP it's not a reason to take this bug lightly. With my patch if acpid dies xorg reopens /proc/acpi/event. So, I'd say this is either an acpid bug (start earlier?) or better yet a kernel bug. Wrong, because acpid is normally restarted during the X server life cycle (on upgrades and by logrotate) so X needs to cope with it. and on some suspend/resume paths to workaround spurious button events. But who can tell which is the grand-piece-of-sw that has the exclusive right to open /proc/acpi/event? BTW: I also submitted a different (more conservative?) patch that simply drops ACPI support if the socket disappears. So whose bug is this? One could also argue that acpid should handle restart in a smarter way as closing the socket breaks _all_ unrelated software that listens to it. And the most obvious way to cope with it is to retry immediately and eventually take /proc/acpi/event if available. -- mattia :wq! signature.asc Description: Digital signature
Bug#347680: Xorg breaks acpid
On Jan 23, Mattia Dongili [EMAIL PROTECTED] wrote: to be fixed in X (I suggest by retrying to open the socket if it worked the first time). this is exactely what the patch I submitted here does. But it does only once, so if the socket is not there on the first retry it'll steal /proc/acpi/event. Indeed, it's wrong. breaks unrelated software is one of the criteria for critical bugs, and even if 6.9 needs to move to testing ASAP it's not a reason to take this bug lightly. With my patch if acpid dies xorg reopens /proc/acpi/event. So, I'd say this is either an acpid bug (start earlier?) or better yet a kernel bug. Wrong, because acpid is normally restarted during the X server life cycle (on upgrades and by logrotate) so X needs to cope with it. and on some suspend/resume paths to workaround spurious button events. But who can tell which is the grand-piece-of-sw that has the exclusive right to open /proc/acpi/event? The one which has been designed to multiplex the events to make them available to other programs, and it's acpid. BTW: I also submitted a different (more conservative?) patch that simply drops ACPI support if the socket disappears. So ACPI support in X will randomly break and people will wonder why? (OK, it's still better than breaking acpid.) So whose bug is this? X. One could also argue that acpid should handle restart in a smarter way And it would be a waste of our time, because acpid will still be restarted on upgrades. as closing the socket breaks _all_ unrelated software that listens to it. And the most obvious way to cope with it is to retry immediately and eventually take /proc/acpi/event if available. Obvious, but wrong. -- ciao, Marco signature.asc Description: Digital signature
Bug#349318: libxft-dev: please do not export unnecessary libraries in xft.pc
On Sun, Jan 22, 2006 at 02:36:58PM -0500, David Nusinow wrote: On Sun, Jan 22, 2006 at 04:18:21AM -0800, Steve Langasek wrote: On Sun, Jan 22, 2006 at 10:57:12AM +, Daniel Stone wrote: This has already been fixed in the modular tree (/cvs/xorg/lib, as opposed to /cvs/xlibs). But I guess the CPPFLAGS scenario remains. Excellent. I don't suppose there's any ETA for this fix making it to unstable? I've found at least one package that could benefit from it, and I imagine there are plenty more. I'm working on it. The mesa NMU will go in shortly, and after that I need to figure out exactly how to handle the transition to FHS compliance. I'm not entirely sure I'm happy with how Daniel did it (although I've yet to look at it closely). I'm going to do a full analysis and post an RFC either on debian-x or debian-devel about it. Once that's figured out, the libs, drivers, and server can all go in to experimental, as they're finished right now. Following that, there's some work to be done on bundling the apps and packaging a few miscellaneous things that shouldn't take too long. If it all works, I'm going to throw it to unstable and see how it goes. But libxft2 is already split out and installed in /usr/lib, so it should be just a simple matter of packaging the new upstream version in order to fix this particular one? Would an NMU be welcome here, or could some other member of the XSF pick it up? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#345099: marked as done (xserver-xorg: doublescan mode not working)
Your message dated Mon, 23 Jan 2006 00:05:51 +0100 with message-id [EMAIL PROTECTED] and subject line Closing 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; 28 Dec 2005 23:32:19 + From [EMAIL PROTECTED] Wed Dec 28 15:32:19 2005 Return-path: [EMAIL PROTECTED] Received: from smtp05.web.de ([217.72.192.209]) by spohr.debian.org with esmtp (Exim 4.50) id 1ErkmI-0001d3-J9 for [EMAIL PROTECTED]; Wed, 28 Dec 2005 15:32:19 -0800 Received: from [83.148.41.245] (helo=marcela-gaxm89c) by smtp05.web.de with asmtp (WEB.DE 4.105 #340) id 1Erkli-0002Lw-00 for [EMAIL PROTECTED]; Thu, 29 Dec 2005 00:31:43 +0100 Date: Thu, 29 Dec 2005 00:31:57 +0100 To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: xserver-xorg: doublescan mode not working From: =?iso-8859-2?B?Smn47SBQYWxl6GVr?= [EMAIL PROTECTED] Content-Type: multipart/mixed; boundary=--zEoasUUOx40rGsnI19LdAz MIME-Version: 1.0 Message-ID: [EMAIL PROTECTED] User-Agent: Opera M2/8.51 (Win32, build 7712) X-Antivirus: avast! (VPS 0552-1, 28.12.2005), Outbound message X-Antivirus-Status: Clean Sender: [EMAIL PROTECTED] X-Sender: [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-Level: X-Spam-Status: No, hits=-6.2 required=4.0 tests=BAYES_01,HAS_PACKAGE, TO_ADDRESS_EQ_REAL autolearn=no version=2.60-bugs.debian.org_2005_01_02 zEoasUUOx40rGsnI19LdAz Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Debbugs-CC: Jiri Palecek [EMAIL PROTECTED] Package: xserver-xorg Version: 6.8.2.dfsg.1-11 Severity: normal When I try to switch to mode 640x480, the display goes blank and indicates that the vertical refresh 170 Hz exceeds the monitor's maximum 160. However, the modeline is (**) RADEON(0): *Default mode 640x480: 74.2 MHz, 85.9 kHz, 85.1 Hz (D) (II) RADEON(0): Modeline 640x480 74.25 640 672 752 864 480 480 482 505 doublescan +hsync +vsync which, as far as I understand it, should be similar to [EMAIL PROTECTED] Hz. The server log is attached. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.13 Locale: LANG=cs_CZ.ISO-8859-2, LC_CTYPE=cs_CZ.ISO-8859-2 (charmap=ISO-8859-2) Versions of packages xserver-xorg depends on: ii debconf [debconf-2.0]1.4.62 Debian configuration management sy ii libc62.3.5-8 GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-5 GCC support library ii libxau6 6.8.2.dfsg.1-11 X Authentication library ii libxdmcp66.8.2.dfsg.1-11 X Display Manager Control Protocol ii xserver-common 6.8.2.dfsg.1-11 files and utilities common to all ii zlib1g 1:1.2.3-8 compression library - runtime Versions of packages xserver-xorg recommends: pn discover | discover1 none (no description available) pn laptop-detectnone (no description available) pn mdetect none (no description available) ii xlibs6.8.2.dfsg.1-11 X Window System client libraries m pn xresprobenone (no description available) -- debconf information: xserver-xorg/multiple_possible_x-drivers: * xserver-xorg/config/monitor/use_sync_ranges: true * xserver-xorg/config/inputdevice/mouse/port: /dev/input/mice xserver-xorg/config/monitor/lcd: false xserver-xorg/autodetect_monitor: true * xserver-xorg/config/display/default_depth: 24 * xserver-xorg/config/display/modes: 1280x1024, 1024x768, 800x600, 640x480 xserver-xorg/config/inputdevice/keyboard/internal: * xserver-xorg/config/inputdevice/keyboard/options: * xserver-xorg/config/inputdevice/mouse/zaxismapping: true * xserver-xorg/config/device/use_fbdev: true * xserver-xorg/config/inputdevice/keyboard/variant: xserver-xorg/config/nonnumeric_string_error: * xserver-xorg/config/inputdevice/keyboard/layout: cz * xserver-xorg/config/monitor/identifier: Generic Monitor * xserver-xorg/config/inputdevice/mouse/emulate3buttons: false * xserver-xorg/autodetect_mouse: true * xserver-xorg/config/monitor/horiz-sync: 30-95
Bug#349318: libxft-dev: please do not export unnecessary libraries in xft.pc
On Sun, Jan 22, 2006 at 03:05:48PM -0800, Steve Langasek wrote: But libxft2 is already split out and installed in /usr/lib, so it should be just a simple matter of packaging the new upstream version in order to fix this particular one? Would an NMU be welcome here, or could some other member of the XSF pick it up? Argh, I'd forgotten that this is one of the few that aren't built from xorg-x11. Ok, I'll grab the latest and upload it ASAP. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
X Strike Force X.Org X11 SVN commit: r1105 - branches/modular/debian/x11-common/debian
Author: dnusinow Date: 2006-01-22 20:31:33 -0500 (Sun, 22 Jan 2006) New Revision: 1105 Removed: branches/modular/debian/x11-common/debian/x11-common.README.Debian branches/modular/debian/x11-common/debian/x11-common.config.in branches/modular/debian/x11-common/debian/x11-common.dirs branches/modular/debian/x11-common/debian/x11-common.doc-base.debian-faq branches/modular/debian/x11-common/debian/x11-common.docs branches/modular/debian/x11-common/debian/x11-common.docs.s390 branches/modular/debian/x11-common/debian/x11-common.examples branches/modular/debian/x11-common/debian/x11-common.init branches/modular/debian/x11-common/debian/x11-common.install branches/modular/debian/x11-common/debian/x11-common.links branches/modular/debian/x11-common/debian/x11-common.postinst.in branches/modular/debian/x11-common/debian/x11-common.postrm.in branches/modular/debian/x11-common/debian/x11-common.preinst.in branches/modular/debian/x11-common/debian/x11-common.templates Modified: branches/modular/debian/x11-common/debian/changelog Log: Remove extra packaging to be added later and set for experimental Modified: branches/modular/debian/x11-common/debian/changelog === --- branches/modular/debian/x11-common/debian/changelog 2006-01-22 19:50:19 UTC (rev 1104) +++ branches/modular/debian/x11-common/debian/changelog 2006-01-23 01:31:33 UTC (rev 1105) @@ -1,8 +1,8 @@ -x11-common (1:1.09) UNRELEASED; urgency=low +x11-common (1:1.09) experimental; urgency=low * First upload to Debian. Renamed to x11-common. - -- David Nusinow [EMAIL PROTECTED] Thu, 27 Oct 2005 23:44:07 -0400 + -- David Nusinow [EMAIL PROTECTED] Sun, 22 Jan 2006 20:31:04 -0500 x-common (1.08) breezy; urgency=low Deleted: branches/modular/debian/x11-common/debian/x11-common.README.Debian === --- branches/modular/debian/x11-common/debian/x11-common.README.Debian 2006-01-22 19:50:19 UTC (rev 1104) +++ branches/modular/debian/x11-common/debian/x11-common.README.Debian 2006-01-23 01:31:33 UTC (rev 1105) @@ -1,90 +0,0 @@ -Debian README for x11-common package - - -The x11-common package provides the infrastructure common to all Debian X -installations. - -Newcomers to the X Window System should first read the Debian X FAQ -(Frequently Asked Questions list): /usr/share/doc/x11-common/FAQ.gz. -You can view this file with your favorite pager program after decompressing -it. For example: -$ zcat /usr/share/doc/x11-common/FAQ.gz | pager - -Those who have upgraded their Debian X packages from version 3.3.2.3-2 or -earlier (Debian 2.0), will want to read the information in -/usr/share/doc/x11-common/README.Debian-upgrade. - -Note that as of version 3.3.6-4, support for the /etc/X11/window-managers -file has been removed; the default window manager is now determined by -using the Debian alternatives mechanism. See update-alternatives(8) for -more information. - -Use dpkg --print-avail package to read the extended descriptions of -the X.Org packages and get some idea of their contents. - -There are three common types of X Window System installation: - -1) standalone X workstation -- the X server and most X clients run on the -same physical hardware. Thus both the xlibs and xserver-common packages -will be present. - -2) X terminal -- only an X server is present; all X clients are run on -remote hardware. The xlibs package need not be present, but the -xserver-common package will be. For Debian policy reasons, xlibs is of -standard priority and thus most likely will be installed, unless the -administrator has taken deliberate steps to remove it. Nevertheless, if -the machine in question is configured strictly as an X terminal, the X -libraries present on the machine will not be used. - -3) X client server -- here the different usages of client and server in -common computing parlance and the X sense can be somewhat confusing. -Essentially, this is the counterpart to 2) above. This is a machine on -which X clients run, but they are displayed only to remote machines; this -machine's own video hardware (if any) is not used by the X Window System. -Therefore, the xlibs package will be present (since in practice all X -clients written in C require the X libraries), but the xserver-common -package will not be. - -One can conclude from the above that any Debian machine which has anything to -do with the X Window System will have xlibs and/or xserver-common installed. -The x11-common package is the foundation on which those two packages -themselves depend. - -In addition to manual pages and documentation, the x11-common -package contains the following: - -1) the basic X directory hierarchy and symbolic links into it -- /usr/X11R6 -is the canonical location for the X Window System according to the FHS -(Filesystem Hierarchy Standard). By
Bug#45291: loan debra miller
For : debra miller We spoke a few days ago and I'd like to confirm everything now. Please check the information below and well me if you have any questions. erneck.com/v We're accepting your app. Your status has been accepted. We need to check your details 1 more time. Just visit the link above and fill in our last application. Sincerely, Gustavo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
X Strike Force X.Org X11 SVN commit: r1108 - in branches/modular/proto: bigreqsproto-X11R7.0-1.0.2/debian compositeproto-X11R7.0-0.2.2/debian damageproto-X11R7.0-1.0.3/debian dmxproto-X11R7.0-2.2.2/de
Author: dnusinow Date: 2006-01-22 21:45:38 -0500 (Sun, 22 Jan 2006) New Revision: 1108 Modified: branches/modular/proto/bigreqsproto-X11R7.0-1.0.2/debian/changelog branches/modular/proto/compositeproto-X11R7.0-0.2.2/debian/changelog branches/modular/proto/damageproto-X11R7.0-1.0.3/debian/changelog branches/modular/proto/dmxproto-X11R7.0-2.2.2/debian/changelog branches/modular/proto/evieext-X11R7.0-1.0.2/debian/changelog branches/modular/proto/fixesproto-X11R7.0-3.0.2/debian/changelog branches/modular/proto/fontcacheproto-X11R7.0-0.1.2/debian/changelog branches/modular/proto/fontsproto-X11R7.0-2.0.2/debian/changelog branches/modular/proto/glproto-X11R7.0-1.4.3/debian/changelog branches/modular/proto/inputproto-X11R7.0-1.3.2/debian/changelog branches/modular/proto/kbproto-X11R7.0-1.0.2/debian/changelog branches/modular/proto/randrproto-X11R7.0-1.1.2/debian/changelog branches/modular/proto/recordproto-X11R7.0-1.13.2/debian/changelog branches/modular/proto/renderproto-X11R7.0-0.9.2/debian/changelog branches/modular/proto/resourceproto-X11R7.0-1.0.2/debian/changelog branches/modular/proto/scrnsaverproto-X11R7.0-1.0.2/debian/changelog branches/modular/proto/trapproto-X11R7.0-3.4.3/debian/changelog branches/modular/proto/videoproto-X11R7.0-2.2.2/debian/changelog branches/modular/proto/xcmiscproto-X11R7.0-1.1.2/debian/changelog branches/modular/proto/xextproto-X11R7.0-7.0.2/debian/changelog branches/modular/proto/xf86bigfontproto-X11R7.0-1.1.2/debian/changelog branches/modular/proto/xf86dgaproto-X11R7.0-2.0.2/debian/changelog branches/modular/proto/xf86driproto-X11R7.0-2.0.3/debian/changelog branches/modular/proto/xf86miscproto-X11R7.0-0.9.2/debian/changelog branches/modular/proto/xf86vidmodeproto-X11R7.0-2.2.2/debian/changelog branches/modular/proto/xineramaproto-X11R7.0-1.1.2/debian/changelog branches/modular/proto/xproto-X11R7.0-7.0.4/debian/changelog Log: Set protocol headers to be uploaded to experimental Modified: branches/modular/proto/bigreqsproto-X11R7.0-1.0.2/debian/changelog === --- branches/modular/proto/bigreqsproto-X11R7.0-1.0.2/debian/changelog 2006-01-23 02:25:17 UTC (rev 1107) +++ branches/modular/proto/bigreqsproto-X11R7.0-1.0.2/debian/changelog 2006-01-23 02:45:38 UTC (rev 1108) @@ -1,4 +1,4 @@ -x11proto-bigreqs (1.0.2-1) UNRELEASED; urgency=low +x11proto-bigreqs (1.0.2-1) experimental; urgency=low * First x11proto-bigreqs release to Debian. Modified: branches/modular/proto/compositeproto-X11R7.0-0.2.2/debian/changelog === --- branches/modular/proto/compositeproto-X11R7.0-0.2.2/debian/changelog 2006-01-23 02:25:17 UTC (rev 1107) +++ branches/modular/proto/compositeproto-X11R7.0-0.2.2/debian/changelog 2006-01-23 02:45:38 UTC (rev 1108) @@ -1,4 +1,4 @@ -x11proto-composite (0.2.2-1) UNRELEASED; urgency=low +x11proto-composite (0.2.2-1) experimental; urgency=low * First release for Debian Modified: branches/modular/proto/damageproto-X11R7.0-1.0.3/debian/changelog === --- branches/modular/proto/damageproto-X11R7.0-1.0.3/debian/changelog 2006-01-23 02:25:17 UTC (rev 1107) +++ branches/modular/proto/damageproto-X11R7.0-1.0.3/debian/changelog 2006-01-23 02:45:38 UTC (rev 1108) @@ -1,4 +1,4 @@ -x11proto-damage (1.0.3-1) UNRELEASED; urgency=low +x11proto-damage (1.0.3-1) experimental; urgency=low * First packaging for Debian Modified: branches/modular/proto/dmxproto-X11R7.0-2.2.2/debian/changelog === --- branches/modular/proto/dmxproto-X11R7.0-2.2.2/debian/changelog 2006-01-23 02:25:17 UTC (rev 1107) +++ branches/modular/proto/dmxproto-X11R7.0-2.2.2/debian/changelog 2006-01-23 02:45:38 UTC (rev 1108) @@ -1,4 +1,4 @@ -x11proto-dmx (2.2.2-1) UNRELEASED; urgency=low +x11proto-dmx (2.2.2-1) experimental; urgency=low * First release to Debian Modified: branches/modular/proto/evieext-X11R7.0-1.0.2/debian/changelog === --- branches/modular/proto/evieext-X11R7.0-1.0.2/debian/changelog 2006-01-23 02:25:17 UTC (rev 1107) +++ branches/modular/proto/evieext-X11R7.0-1.0.2/debian/changelog 2006-01-23 02:45:38 UTC (rev 1108) @@ -1,4 +1,4 @@ -x11proto-evie (1.0.2-2) UNRELEASED; urgency=low +x11proto-evie (1.0.2-2) experimental; urgency=low * First release to Debian Modified: branches/modular/proto/fixesproto-X11R7.0-3.0.2/debian/changelog === --- branches/modular/proto/fixesproto-X11R7.0-3.0.2/debian/changelog 2006-01-23 02:25:17 UTC (rev 1107) +++ branches/modular/proto/fixesproto-X11R7.0-3.0.2/debian/changelog 2006-01-23 02:45:38 UTC (rev 1108) @@ -1,4 +1,4 @@
X Strike Force X.Org X11 SVN commit: r1109 - branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian
Author: dnusinow
Date: 2006-01-22 22:07:34 -0500 (Sun, 22 Jan 2006)
New Revision: 1109
Modified:
branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/changelog
branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/control
branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/libxft-dev.install
branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/libxft2.install
branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/rules
Log:
Grab latest from Ubuntu, which brings this lib in line with the rest of the
modular libs.
Modified: branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/changelog
===
--- branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/changelog
2006-01-23 02:45:38 UTC (rev 1108)
+++ branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/changelog
2006-01-23 03:07:34 UTC (rev 1109)
@@ -1,29 +1,28 @@
-xft (2.1.8.2-1) UNRELEASED; urgency=low
+libxft (2.1.8.2-1) UNRELEASED; urgency=low
- * First modular upload to Debian
- * Add myself to uploaders
+ * First upload to Debian
- -- David Nusinow [EMAIL PROTECTED] Thu, 29 Dec 2005 20:52:12 -0500
+ -- David Nusinow [EMAIL PROTECTED] Sun, 22 Jan 2006 22:06:17 -0500
-xft (2.1.7-1ubuntu5) breezy; urgency=low
+libxft (2.1.8.2-0ubuntu2) dapper; urgency=low
- * debian/control.in:
-- updated the libx11-dev requirement to build without -D_XOPEN_SOURCE.
+ * Change dependency on x-common to x11-common.
- -- Sebastien Bacher [EMAIL PROTECTED] Sat, 23 Jul 2005 14:46:42 +0200
+ -- Daniel Stone [EMAIL PROTECTED] Thu, 19 Jan 2006 18:27:58 +1100
-xft (2.1.7-1ubuntu4) breezy; urgency=low
+libxft (2.1.8.2-0ubuntu1) dapper; urgency=low
- * Set a versioned libxrender-dev build-dep to make sure we
-get the correct behaviour wanted with the previous upload.
+ * New upstream release.
+ * Repackaged to fit all the other X packages.
+ * Stop shipping libXft.la.
- -- Adam Conrad [EMAIL PROTECTED] Tue, 19 Jul 2005 12:38:29 +1000
+ -- Daniel Stone [EMAIL PROTECTED] Wed, 21 Dec 2005 13:13:31 +1100
-xft (2.1.7-1ubuntu3) breezy; urgency=low
+xft (2.1.8.1-0ubuntu1) dapper; urgency=low
- * Rebuild for the libXrender changes.
+ * New upstream release.
- -- Sebastien Bacher [EMAIL PROTECTED] Fri, 15 Jul 2005 13:07:36 +0200
+ -- Daniel Stone [EMAIL PROTECTED] Mon, 12 Dec 2005 15:33:13 +1100
xft (2.1.7-1ubuntu2) breezy; urgency=low
Modified: branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/control
===
--- branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/control 2006-01-23
02:45:38 UTC (rev 1108)
+++ branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/control 2006-01-23
03:07:34 UTC (rev 1109)
@@ -1,9 +1,8 @@
-Source: xft
-Section: devel
+Source: libxft
+Section: x11
Priority: optional
-Maintainer: Debian X Strike Force debian-x@lists.debian.org
-Uploaders: Branden Robinson [EMAIL PROTECTED], David Nusinow [EMAIL
PROTECTED]
-Build-Depends: cdbs (= 0.4.12), debhelper (= 4.0.0), libfontconfig1-dev,
libfreetype6-dev, x-dev, libx11-dev (= 1:0.99.2-1), libxrender-dev (=
1:0.9.0-2), zlib1g-dev | libz-dev
+Maintainer: Daniel Stone [EMAIL PROTECTED]
+Build-Depends: debhelper (= 4.0.0), libfontconfig1-dev, libfreetype6-dev,
x11proto-core-dev, libx11-dev, libxrender-dev, zlib1g-dev | libz-dev
Standards-Version: 3.6.1
Package: libxft2
@@ -42,7 +41,7 @@
Depends: libxft2 (= ${Source-Version}), libc6-dev | libc-dev,
libfontconfig1-dev, libfreetype6-dev, x-dev, libx11-dev, libxrender-dev,
zlib1g-dev | libz-dev
Conflicts: libxft2-dev, xlibs-dev ( 4.3.0)
Provides: libxft2-dev
-Pre-Depends: x11-common (= 1:1.09)
+Pre-Depends: x11-common (= 7.0.0-0ubuntu3)
Description: FreeType-based font drawing library for X (development files)
Xft provides a client-side font API for X applications, making the FreeType
font rasterizer available to X clients. Fontconfig is used for font
Modified: branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/libxft-dev.install
===
--- branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/libxft-dev.install
2006-01-23 02:45:38 UTC (rev 1108)
+++ branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/libxft-dev.install
2006-01-23 03:07:34 UTC (rev 1109)
@@ -1,6 +1,7 @@
-debian/tmp/usr/include/X11/Xft/* usr/include/X11/Xft/
-debian/tmp/usr/lib/libXft*.{a,la,so}
-debian/tmp/usr/lib/pkgconfig/*.pc
-debian/tmp/usr/bin/xft-config
-debian/tmp/usr/share/man/man1/xft-config.1
-debian/tmp/usr/share/man/man3/Xft.3
+usr/include/X11/Xft/*
+usr/lib/libXft.a
+usr/lib/libXft.so
+usr/lib/pkgconfig/*.pc
+usr/bin/xft-config
+usr/share/man/man1/*
+usr/share/man/man3/*
Modified: branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/libxft2.install
===
--- branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/libxft2.install
2006-01-23 02:45:38 UTC (rev 1108)
X Strike Force X.Org X11 SVN commit: r1110 - branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian
Author: dnusinow Date: 2006-01-22 22:09:34 -0500 (Sun, 22 Jan 2006) New Revision: 1110 Modified: branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/changelog branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/control Log: * Add build-dep on quilt * Set maintainer and uploaders Modified: branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/changelog === --- branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/changelog 2006-01-23 03:07:34 UTC (rev 1109) +++ branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/changelog 2006-01-23 03:09:34 UTC (rev 1110) @@ -1,8 +1,9 @@ libxft (2.1.8.2-1) UNRELEASED; urgency=low * First upload to Debian + * Add build-dep on quilt - -- David Nusinow [EMAIL PROTECTED] Sun, 22 Jan 2006 22:06:17 -0500 + -- David Nusinow [EMAIL PROTECTED] Sun, 22 Jan 2006 22:08:28 -0500 libxft (2.1.8.2-0ubuntu2) dapper; urgency=low Modified: branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/control === --- branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/control 2006-01-23 03:07:34 UTC (rev 1109) +++ branches/modular/lib/libXft-X11R7.0-2.1.8.2/debian/control 2006-01-23 03:09:34 UTC (rev 1110) @@ -1,8 +1,9 @@ Source: libxft Section: x11 Priority: optional -Maintainer: Daniel Stone [EMAIL PROTECTED] -Build-Depends: debhelper (= 4.0.0), libfontconfig1-dev, libfreetype6-dev, x11proto-core-dev, libx11-dev, libxrender-dev, zlib1g-dev | libz-dev +Maintainer: Debian X Strike Force debian-x@lists.debian.org +Uploaders: David Nusinow [EMAIL PROTECTED], Branden Robinson [EMAIL PROTECTED], Fabio M. Di Nitto [EMAIL PROTECTED] +Build-Depends: debhelper (= 4.0.0), libfontconfig1-dev, libfreetype6-dev, x11proto-core-dev, libx11-dev, libxrender-dev, zlib1g-dev | libz-dev, quilt Standards-Version: 3.6.1 Package: libxft2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#126519: what your employer is hiding from you
Hows it been going?, You have been selected to generate 1.5 - 3.5k daily! Phone me at my line below. Let me help you generate payments! Thanks, [EMAIL PROTECTED] 1*888*700*4915 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349318: marked as done (libxft-dev: please do not export unnecessary libraries in xft.pc)
Your message dated Sun, 22 Jan 2006 20:47:07 -0800
with message-id [EMAIL PROTECTED]
and subject line Bug#349318: fixed in xft 2.1.8.2-1
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; 22 Jan 2006 10:44:30 +
From [EMAIL PROTECTED] Sun Jan 22 02:44:30 2006
Return-path: [EMAIL PROTECTED]
Received: from dsl093-039-086.pdx1.dsl.speakeasy.net ([66.93.39.86]
helo=tennyson.dodds.net)
by spohr.debian.org with esmtp (Exim 4.50)
id 1F0chx-0001ZA-Uz
for [EMAIL PROTECTED]; Sun, 22 Jan 2006 02:44:30 -0800
Received: by tennyson.dodds.net (Postfix, from userid 1000)
id 8D8AE7027; Sun, 22 Jan 2006 02:44:28 -0800 (PST)
Date: Sun, 22 Jan 2006 02:44:28 -0800
From: Steve Langasek [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: libxft-dev: please do not export unnecessary libraries in xft.pc
Message-ID: [EMAIL PROTECTED]
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol=application/pgp-signature; boundary=+KJYzRxRHjYqLGl5
Content-Disposition: inline
User-Agent: Mutt/1.5.9i
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-Level:
X-Spam-Status: No, hits=-3.0 required=4.0 tests=BAYES_00 autolearn=no
version=2.60-bugs.debian.org_2005_01_02
--+KJYzRxRHjYqLGl5
Content-Type: multipart/mixed; boundary=eHhjakXzOLJAF9wJ
Content-Disposition: inline
--eHhjakXzOLJAF9wJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Package: libxft-dev
Version: 2.1.7-1
Severity: important
Tags: upstream
Hi folks,
So, I suppose most of you have read
http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html about
problems with packages depending on libraries that they don't use,
particularly as relates to a potential libfreetype transition. One library
that currently exposes freetype (and other libs) in its pkg-config .pc file,
but shouldn't, is libxft.
Please consider (and forward upstream) the attached patch which moves all of
the library dependencies of libxft into the Libs.private variable in xft.pc,
so that they aren't used on Debian except for static linking. I have not
touched the 'Requires' field; even though packages which link to libXft
should not need to link to libfontconfig, the pkg-config 'Requires' field
controls both CPPFLAGS and LDFLAGS, and Xft includes fontconfig headers --
unfortunately the pkg-config maintainer has not been convinced that CPPFLAGS
=66rom Requires.private should be propagated, despite the fact that there a=
re
many examples of this scenario in Debian... (this is bug #340904, for those
who care.)
FWIW, since September 2003 FreeType has supported pkg-config; however, I
wouldn't recommend that Xft use pkg-config dependencies for libfreetype
unless this Requires.private CPPFLAGS issue is resolved. :/
Oh, also, there seems to be a pre-existing bug in this .pc file, in that
-lX11 is specified for static linking, but -L/usr/X11R6/lib is not...
Thanks,
--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--eHhjakXzOLJAF9wJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=xft-pkgconfig.diff
Content-Transfer-Encoding: quoted-printable
diff -u xft-2.1.7/debian/changelog xft-2.1.7/debian/changelog
--- xft-2.1.7/debian/changelog
+++ xft-2.1.7/debian/changelog
@@ -1,3 +1,11 @@
+xft (2.1.7-1.1) unstable; urgency=3Dlow
+
+ * Non-maintainer upload.
+ * Fix xft.pc to not export freetype and xrender as part of the interface
+used for shared linking; expose them only in Libs.private instead.
+
+ -- Steve Langasek [EMAIL PROTECTED] Sun, 22 Jan 2006 02:32:25 -0800
+
xft (2.1.7-1) unstable; urgency=3Dlow
=20
* New upstream release.
only in patch2:
unchanged:
--- xft-2.1.7.orig/xft.pc.in
+++ xft-2.1.7/xft.pc.in
@@ -11,5 +11,6 @@
Description: X FreeType library
Version: @VERSION@
Requires: fontconfig
-Libs: -L${libdir} -lXft -lX11 ${freetypelibs} ${xrenderlibs}
+Libs: -L${libdir} -lXft
+Libs.private: -lX11 ${freetypelibs} ${xrenderlibs}
Cflags: -I${includedir} ${freetypecflags} ${xrendercflags}
--eHhjakXzOLJAF9wJ--
--+KJYzRxRHjYqLGl5
Content-Type: application/pgp-signature; name=signature.asc
Processed: Reopening
Processing commands for [EMAIL PROTECTED]: reopen 349318 Bug#349318: libxft-dev: please do not export unnecessary libraries in xft.pc Bug reopened, originator not changed. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349318: fixed in xft 2.1.8.2-1
reopen 349318
block 349318 by 340904
thanks
* Add 001_no_export_freetype.diff. This is a modified patch from Steve
Langasek that causes xft.pc not to export freetype or xrender as part of
the interface, but hide them in Requires.private instead (closes:
#349318)
The patch is:
Index: libXft-X11R7.0-2.1.8.2/xft.pc.in
===
--- libXft-X11R7.0-2.1.8.2.orig/xft.pc.in 2005-12-30 14:50:49.0
-0500
+++ libXft-X11R7.0-2.1.8.2/xft.pc.in 2006-01-22 22:12:27.0 -0500
@@ -6,7 +6,7 @@
Name: Xft
Description: X FreeType library
Version: @VERSION@
-Requires: xproto, xrender, fontconfig, freetype2
-Requires.private: xrender, fontconfig, freetype2
+Requires: xproto, fontconfig
+Requires.private: xrender, freetype2
Cflags: -I${includedir}
Libs: -L${libdir} -lXft
This won't work because of the aforementioned bug #340904:
$ grep -h include include/X11/Xft/*.h
#include X11/Xfuncproto.h
#include stdarg.h
#include ft2build.h
#include FT_FREETYPE_H
#include fontconfig/fontconfig.h
#include X11/extensions/Xrender.h
#include X11/Xfuncproto.h
/* #include X11/Xosdefs.h*/
#include X11/Xft/XftCompat.h
$
Both the xrender and freetype2 headers are included in Xft/Xft.h, and types
from both of these headers are exported in the Xft API -- so any software
using Xft.h needs to be able to find these other headers as well.
Currently, pkg-config does *not* pass cflags from packages listed in
Requires.private when called as pkg-config --cflags foo.
So far, the maintainer has resisted changing pkg-config to export cflags
(which should really be called cppflags...) from Requires.private due to a
fallacious argument regarding the nature of private dependencies. There
are three real use cases for libraries which depend on other libraries:
- the library intentionally exports the API and ABI of its dependencies when
linked to, and therefore both the ldflags and the cflags of its
dependencies should be exported by pkg-config in all cases[1]
- the library intentionally includes headers from dependencies in its own
headers in order to inherit type definitions, but these definitions are
not intended for direct consumption by users of this library alone;
therefore pkg-config must export the cflags from dependencies in all
cases, but the ldflags only when linking statically
- the library's API includes no headers from its dependencies; pkg-config
needs to export the ldflags of private dependencies when statically
linking but not when dynamically linking, and should *never* need to
export the cflags of these headers.
Please note that today, the handling of Requires.private in pkg-config maps
to *none* of these cases -- I can't think of a single situation in which
cflags of dependencies are needed when statically linking, and not needed
when dynamically linking! Instead, the Requires.private handling is
adequate for the third case; handling of Requires is correct for the first
case; and there is no combination of options that is appropriate for the
second case.
This is unfortunate, because there are a great many packages that are
inheriting dependencies this way on libraries they don't use. While it is
true that an ABI change in the dependent library will *sometimes* mean an
ABI change in the depending library, this is not always the case. As a
result, this behavior of pkg-config causes unnecessary churn for packages
depending on libraries in this scenario. In the case of libxft2, that's
over 400 packages in Debian that are potentially affected.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
[1] Personally, I think this is completely specious, but there are GNOME
people who insist that this describes the relationship between gtk+2.0
glib.
signature.asc
Description: Digital signature
