Bug#255192: Alt-Tab is broken differently with Window Maker
On my machine with Window Maker the behaviour is slightly different: all Alt- shortcuts work, and Alt-Tab switching works, but swallows the first keypress in the new window. In xterm, the cursor changes from shallow to filled after the swallowed keypress, as if the window receives the keyboard focus only after a key is pressed in it; in GUI windows, text cursor only appears after the first (swallowed) keypress, too. Is it somehow related to the "Grab updates to XKB data from XFree86 CVS" changelog item? Like "fix Meta, Super, Hyper keysyms interpretation"? -- Dmitry Borodaenko
Processed: Re: Bug#255439: d-i report
Processing commands for [EMAIL PROTECTED]: > clone 255439 -1 Bug#255439: d-i report Bug 255439 cloned as bug 255689. > retitle -1 Wrong driver chosen for ATI Technologies Inc Radeon Mobility U1 Bug#255689: d-i report Changed Bug title. > reassign -1 xserver-xfree86 Bug#255689: Wrong driver chosen for ATI Technologies Inc Radeon Mobility U1 Bug reassigned from package `installation-reports' to `xserver-xfree86'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: Bug#255439: d-i report
clone 255439 -1 retitle -1 Wrong driver chosen for ATI Technologies Inc Radeon Mobility U1 reassign -1 xserver-xfree86 thanks * Cristian Escalante <[EMAIL PROTECTED]> [2004-06-21 23:22]: > > > - Detect the wrong vga card (apm instead of ati); > > Can you send your /var/log/XFree86.0.log file please. > Sure, I gzipped the XF86Config-4, XFree86.0.log (before updating the > driver from *apm* to *ati*) and after the update. > In XF86Config-4, you will see (about line 76): Thanks for those logs, I'm cloning this bug and reassigning it to the XFree86 package. -- Martin Michlmayr [EMAIL PROTECTED]
Bug#255701: xlibs-data: fonts can't be display under ja_JP.UTF-8
Package: xlibs-data
Version: 4.3.0.dfsg.1-5
Severity: normal
Tags: patch
Japanese fonts can't be displayed under ja_JP.UTF-8 locale.
Please update XLC_LOCALE for ja_JP.UTF-8.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.7-rc2
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (ignored: LC_ALL set to
ja_JP.UTF-8)
-- no debconf information
--
Tatsuki Sugiura mailto:[EMAIL PROTECTED]
diff -ruP xc/nls/XLC_LOCALE/ja_JP.UTF-8 xc.orig/nls/XLC_LOCALE/ja_JP.UTF-8
--- xc/nls/XLC_LOCALE/ja_JP.UTF-8 2004-06-22 23:18:36.0 +0900
+++ xc.orig/nls/XLC_LOCALE/ja_JP.UTF-8 2002-10-17 10:12:57.0 +0900
@@ -32,8 +32,23 @@
}
}
-XCOMM fs2 class (Kanji)
-fs2{
+XCOMM ISO10646-1 is put after iso8859-1 to make usually better-looking
+XCOMM iso8859-x fonts are picked up before iso10646-1 fonts.
+XCOMM Moreover, some iso10646-1 fonts don't have any glyph at all
+XCOMM in ISO8859-X ranges.
+
+XCOMM fs2 class
+fs2 {
+ charset {
+name ISO10646-1
+ }
+ font {
+primary ISO10646-1
+ }
+}
+
+XCOMM fs3 class (Kanji)
+fs3{
charset {
nameJISX0208.1983-0:GL
}
@@ -42,8 +57,8 @@
}
}
-XCOMM fs3 class (Korean Character)
-fs3{
+XCOMM fs4 class (Korean Character)
+fs4{
charset {
nameKSC5601.1987-0:GL
}
@@ -52,8 +67,8 @@
}
}
-XCOMM fs4 class (Chinese Han Character)
-fs4{
+XCOMM fs5 class (Chinese Han Character)
+fs5{
charset {
nameGB2312.1980-0:GL
}
@@ -61,8 +76,8 @@
primary GB2312.1980-0:GL
}
}
-XCOMM fs5 class (Half Kana)
-fs5{
+XCOMM fs6 class (Half Kana)
+fs6{
charset {
nameJISX0201.1976-0:GR
}
@@ -71,22 +86,6 @@
vertical_rotate all
}
}
-
-XCOMM ISO10646-1 is put after iso8859-1 to make usually better-looking
-XCOMM iso8859-x fonts are picked up before iso10646-1 fonts.
-XCOMM Moreover, some iso10646-1 fonts don't have any glyph at all
-XCOMM in ISO8859-X ranges.
-
-XCOMM fs6 class
-fs6 {
- charset {
-name ISO10646-1
- }
- font {
-primary ISO10646-1
- }
-}
-
END XLC_FONTSET
XCOMM
@@ -105,47 +104,47 @@
ct_encoding ISO8859-1:GL
}
+XCOMM cs1 class
+cs1 {
+sideGR:Default
+length 1
+ct_encoding ISO8859-1:GR
+}
+
XCOMM cs2 class
-cs1{
+cs2{
sideGR
length 2
ct_encoding JISX0208.1983-0:GL; JISX0208.1983-0:GR;
JISX0208.1983-1:GL; JISX0208.1983-1:GR
}
-XCOMM cs2 class
-cs2 {
+XCOMM cs3 class
+cs3 {
sideGL
length 2
ct_encoding KSC5601.1987-0:GL; KSC5601.1987-0:GR;
KSC5601.1987-1:GL; KSC5601.1987-1:GR
}
-XCOMM cs3 class
-cs3 {
+XCOMM cs4 class
+cs4 {
sideGR
length 2
ct_encoding GB2312.1980-0:GL; GB2312.1980-0:GR
}
-XCOMM cs4 class
-cs4{
+XCOMM cs5 class
+cs5{
sideGR
length 1
ct_encoding JISX0201.1976-0:GR
}
-XCOMM cs5 class
-cs5{
+XCOMM cs6 class
+cs6{
sidenone
ct_encoding ISO10646-1
}
-XCOMM cs6 class
-cs6 {
-sideGR:Default
-length 1
-ct_encoding ISO8859-1:GR
-}
-
END XLC_XLOCALE
Processing of xfree86_4.3.0.dfsg.1-5_powerpc.changes
xfree86_4.3.0.dfsg.1-5_powerpc.changes uploaded successfully to localhost along with the files: lbxproxy_4.3.0.dfsg.1-5_powerpc.deb libdps1_4.3.0.dfsg.1-5_powerpc.deb libdps1-dbg_4.3.0.dfsg.1-5_powerpc.deb libdps-dev_4.3.0.dfsg.1-5_powerpc.deb libice6_4.3.0.dfsg.1-5_powerpc.deb libice6-dbg_4.3.0.dfsg.1-5_powerpc.deb libice-dev_4.3.0.dfsg.1-5_powerpc.deb libsm6_4.3.0.dfsg.1-5_powerpc.deb libsm6-dbg_4.3.0.dfsg.1-5_powerpc.deb libsm-dev_4.3.0.dfsg.1-5_powerpc.deb libx11-6_4.3.0.dfsg.1-5_powerpc.deb libx11-6-dbg_4.3.0.dfsg.1-5_powerpc.deb libx11-dev_4.3.0.dfsg.1-5_powerpc.deb libxaw6_4.3.0.dfsg.1-5_powerpc.deb libxaw6-dbg_4.3.0.dfsg.1-5_powerpc.deb libxaw6-dev_4.3.0.dfsg.1-5_powerpc.deb libxaw7_4.3.0.dfsg.1-5_powerpc.deb libxaw7-dbg_4.3.0.dfsg.1-5_powerpc.deb libxaw7-dev_4.3.0.dfsg.1-5_powerpc.deb libxext6_4.3.0.dfsg.1-5_powerpc.deb libxext6-dbg_4.3.0.dfsg.1-5_powerpc.deb libxext-dev_4.3.0.dfsg.1-5_powerpc.deb libxft1_4.3.0.dfsg.1-5_powerpc.deb libxft1-dbg_4.3.0.dfsg.1-5_powerpc.deb libxi6_4.3.0.dfsg.1-5_powerpc.deb libxi6-dbg_4.3.0.dfsg.1-5_powerpc.deb libxi-dev_4.3.0.dfsg.1-5_powerpc.deb libxmu6_4.3.0.dfsg.1-5_powerpc.deb libxmu6-dbg_4.3.0.dfsg.1-5_powerpc.deb libxmu-dev_4.3.0.dfsg.1-5_powerpc.deb libxmuu1_4.3.0.dfsg.1-5_powerpc.deb libxmuu1-dbg_4.3.0.dfsg.1-5_powerpc.deb libxmuu-dev_4.3.0.dfsg.1-5_powerpc.deb libxp6_4.3.0.dfsg.1-5_powerpc.deb libxp6-dbg_4.3.0.dfsg.1-5_powerpc.deb libxp-dev_4.3.0.dfsg.1-5_powerpc.deb libxpm4_4.3.0.dfsg.1-5_powerpc.deb libxpm4-dbg_4.3.0.dfsg.1-5_powerpc.deb libxpm-dev_4.3.0.dfsg.1-5_powerpc.deb libxrandr2_4.3.0.dfsg.1-5_powerpc.deb libxrandr2-dbg_4.3.0.dfsg.1-5_powerpc.deb libxrandr-dev_4.3.0.dfsg.1-5_powerpc.deb libxt6_4.3.0.dfsg.1-5_powerpc.deb libxt6-dbg_4.3.0.dfsg.1-5_powerpc.deb libxt-dev_4.3.0.dfsg.1-5_powerpc.deb libxtrap6_4.3.0.dfsg.1-5_powerpc.deb libxtrap6-dbg_4.3.0.dfsg.1-5_powerpc.deb libxtrap-dev_4.3.0.dfsg.1-5_powerpc.deb libxtst6_4.3.0.dfsg.1-5_powerpc.deb libxtst6-dbg_4.3.0.dfsg.1-5_powerpc.deb libxtst-dev_4.3.0.dfsg.1-5_powerpc.deb libxv1_4.3.0.dfsg.1-5_powerpc.deb libxv1-dbg_4.3.0.dfsg.1-5_powerpc.deb libxv-dev_4.3.0.dfsg.1-5_powerpc.deb proxymngr_4.3.0.dfsg.1-5_powerpc.deb twm_4.3.0.dfsg.1-5_powerpc.deb xbase-clients_4.3.0.dfsg.1-5_powerpc.deb xdm_4.3.0.dfsg.1-5_powerpc.deb xfs_4.3.0.dfsg.1-5_powerpc.deb xfwp_4.3.0.dfsg.1-5_powerpc.deb xlibmesa-dri_4.3.0.dfsg.1-5_powerpc.deb xlibmesa-dri-dbg_4.3.0.dfsg.1-5_powerpc.deb xlibmesa-gl_4.3.0.dfsg.1-5_powerpc.deb xlibmesa-gl-dbg_4.3.0.dfsg.1-5_powerpc.deb xlibmesa-gl-dev_4.3.0.dfsg.1-5_powerpc.deb xlibmesa-glu_4.3.0.dfsg.1-5_powerpc.deb xlibmesa-glu-dbg_4.3.0.dfsg.1-5_powerpc.deb xlibmesa-glu-dev_4.3.0.dfsg.1-5_powerpc.deb xlibosmesa4_4.3.0.dfsg.1-5_powerpc.deb xlibosmesa4-dbg_4.3.0.dfsg.1-5_powerpc.deb xlibosmesa-dev_4.3.0.dfsg.1-5_powerpc.deb xlibs-static-dev_4.3.0.dfsg.1-5_powerpc.deb xlibs-static-pic_4.3.0.dfsg.1-5_powerpc.deb xmh_4.3.0.dfsg.1-5_powerpc.deb xnest_4.3.0.dfsg.1-5_powerpc.deb xprt_4.3.0.dfsg.1-5_powerpc.deb xserver-common_4.3.0.dfsg.1-5_powerpc.deb xserver-xfree86_4.3.0.dfsg.1-5_powerpc.deb xserver-xfree86-dbg_4.3.0.dfsg.1-5_powerpc.deb xterm_4.3.0.dfsg.1-5_powerpc.deb xutils_4.3.0.dfsg.1-5_powerpc.deb xvfb_4.3.0.dfsg.1-5_powerpc.deb x-window-system-core_4.3.0.dfsg.1-5_powerpc.deb x-window-system-dev_4.3.0.dfsg.1-5_powerpc.deb xlibmesa3_4.3.0.dfsg.1-5_powerpc.deb Greetings, Your Debian queue daemon
xfree86_4.3.0.dfsg.1-5_powerpc.changes ACCEPTED
Accepted: lbxproxy_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/lbxproxy_4.3.0.dfsg.1-5_powerpc.deb libdps-dev_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libdps-dev_4.3.0.dfsg.1-5_powerpc.deb libdps1-dbg_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libdps1-dbg_4.3.0.dfsg.1-5_powerpc.deb libdps1_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libdps1_4.3.0.dfsg.1-5_powerpc.deb libice-dev_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libice-dev_4.3.0.dfsg.1-5_powerpc.deb libice6-dbg_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libice6-dbg_4.3.0.dfsg.1-5_powerpc.deb libice6_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libice6_4.3.0.dfsg.1-5_powerpc.deb libsm-dev_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libsm-dev_4.3.0.dfsg.1-5_powerpc.deb libsm6-dbg_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libsm6-dbg_4.3.0.dfsg.1-5_powerpc.deb libsm6_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libsm6_4.3.0.dfsg.1-5_powerpc.deb libx11-6-dbg_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libx11-6-dbg_4.3.0.dfsg.1-5_powerpc.deb libx11-6_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libx11-6_4.3.0.dfsg.1-5_powerpc.deb libx11-dev_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libx11-dev_4.3.0.dfsg.1-5_powerpc.deb libxaw6-dbg_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxaw6-dbg_4.3.0.dfsg.1-5_powerpc.deb libxaw6-dev_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxaw6-dev_4.3.0.dfsg.1-5_powerpc.deb libxaw6_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxaw6_4.3.0.dfsg.1-5_powerpc.deb libxaw7-dbg_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxaw7-dbg_4.3.0.dfsg.1-5_powerpc.deb libxaw7-dev_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxaw7-dev_4.3.0.dfsg.1-5_powerpc.deb libxaw7_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxaw7_4.3.0.dfsg.1-5_powerpc.deb libxext-dev_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxext-dev_4.3.0.dfsg.1-5_powerpc.deb libxext6-dbg_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxext6-dbg_4.3.0.dfsg.1-5_powerpc.deb libxext6_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxext6_4.3.0.dfsg.1-5_powerpc.deb libxft1-dbg_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxft1-dbg_4.3.0.dfsg.1-5_powerpc.deb libxft1_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxft1_4.3.0.dfsg.1-5_powerpc.deb libxi-dev_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxi-dev_4.3.0.dfsg.1-5_powerpc.deb libxi6-dbg_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxi6-dbg_4.3.0.dfsg.1-5_powerpc.deb libxi6_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxi6_4.3.0.dfsg.1-5_powerpc.deb libxmu-dev_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxmu-dev_4.3.0.dfsg.1-5_powerpc.deb libxmu6-dbg_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxmu6-dbg_4.3.0.dfsg.1-5_powerpc.deb libxmu6_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxmu6_4.3.0.dfsg.1-5_powerpc.deb libxmuu-dev_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxmuu-dev_4.3.0.dfsg.1-5_powerpc.deb libxmuu1-dbg_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxmuu1-dbg_4.3.0.dfsg.1-5_powerpc.deb libxmuu1_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxmuu1_4.3.0.dfsg.1-5_powerpc.deb libxp-dev_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxp-dev_4.3.0.dfsg.1-5_powerpc.deb libxp6-dbg_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxp6-dbg_4.3.0.dfsg.1-5_powerpc.deb libxp6_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxp6_4.3.0.dfsg.1-5_powerpc.deb libxpm-dev_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxpm-dev_4.3.0.dfsg.1-5_powerpc.deb libxpm4-dbg_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxpm4-dbg_4.3.0.dfsg.1-5_powerpc.deb libxpm4_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxpm4_4.3.0.dfsg.1-5_powerpc.deb libxrandr-dev_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxrandr-dev_4.3.0.dfsg.1-5_powerpc.deb libxrandr2-dbg_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxrandr2-dbg_4.3.0.dfsg.1-5_powerpc.deb libxrandr2_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxrandr2_4.3.0.dfsg.1-5_powerpc.deb libxt-dev_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxt-dev_4.3.0.dfsg.1-5_powerpc.deb libxt6-dbg_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxt6-dbg_4.3.0.dfsg.1-5_powerpc.deb libxt6_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxt6_4.3.0.dfsg.1-5_powerpc.deb libxtrap-dev_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxtrap-dev_4.3.0.dfsg.1-5_powerpc.deb libxtrap6-dbg_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxtrap6-dbg_4.3.0.dfsg.1-5_powerpc.deb libxtrap6_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxtrap6_4.3.0.dfsg.1-5_powerpc.deb libxtst-dev_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxtst-dev_4.3.0.dfsg.1-5_powerpc.deb libxtst6-dbg_4.3.0.dfsg.1-5_powerpc.deb to pool/main/x/xfree86/libxtst6-dbg_4
X Strike Force XFree86 SVN commit: r1556 - trunk/debian
Author: branden Date: 2004-06-22 12:43:26 -0500 (Tue, 22 Jun 2004) New Revision: 1556 Modified: trunk/debian/CHANGESETS trunk/debian/changelog Log: Credit Fabio for r1555. Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-06-21 08:20:22 UTC (rev 1555) +++ trunk/debian/CHANGESETS 2004-06-22 17:43:26 UTC (rev 1556) @@ -38,6 +38,6 @@ Update French debconf template translations (thanks, Christian Perrier). (Closes: #255464) -1555 +1555, 1556 vim:set ai et sts=4 sw=4 tw=80: Modified: trunk/debian/changelog === --- trunk/debian/changelog 2004-06-21 08:20:22 UTC (rev 1555) +++ trunk/debian/changelog 2004-06-22 17:43:26 UTC (rev 1556) @@ -23,10 +23,12 @@ * Update Danish debconf template translations (thanks, Claus Hindsgaul). (Closes: #255184) + Changes by Fabio Massimo Di Nitto: + * Update French debconf template translations (thanks, Christian Perrier). (Closes: #255464) - -- Branden Robinson <[EMAIL PROTECTED]> Sat, 19 Jun 2004 16:57:06 -0500 + -- Branden Robinson <[EMAIL PROTECTED]> Tue, 22 Jun 2004 12:41:27 -0500 xfree86 (4.3.0.dfsg.1-5) unstable; urgency=low
Re: Future of X packages in Debian
On Fri, 18 Jun 2004, Anders Karlsson wrote: > On Friday 18 Jun 2004 08:02, Fabio Massimo Di Nitto wrote: > > Hi everybody, > > As you might have seen from the messages on > > debian-devel-changes, 4.3.0.dfsg.1-5 has been accepted into unstable. > > Seen it, downloaded it and installed it. Works like a charm. Many > thanks! :) Thanks! it's always nice to know that someone out there appreciate :-) > > Our questions to the community are: > > > > * What kinds of X packages would you like to see in the future? > > As a user and not a developer, This is also important feedback for us. > I do not know how much work there would be involved in a shift to the > X.org release, but X.org seems to have a decent road-map, good ideas and > above all, an active team working on things. What I am trying to say is > that X.org seems from a users perspective to be the good route to take. The amount of work is going to be relatively huge indipendently of which direction we will take. There is nothing to do about it other than getting it done. > > * Should we go our own way starting from the "sanitized" XFree86 CVS > > snapshot we've prepared? > > Would this give the developers and the users added benefits above and > beyond what X.org gives? Since we are talking about sarge+1 no. There would be no benefit in maintaining our own tree other than we already know what works and what doesn't. Thanks Fabio ps I am taking notes of all the comments. they are not passing unreaded. -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.
Re: Future of X packages in Debian
On Fri, 18 Jun 2004, Adrian 'Dagurashibanipal' von Bidder wrote: > #include > > On Friday 18 June 2004 09.02, Fabio Massimo Di Nitto wrote: > > > * Should we ensure that multiple implementations of the X Window > > System are packaged, or standardize on just one? > > from a user perspective, multiple X servers to chose from which are > almost but not exaclty the same is most confusing. AFAICT this is not > like having KDE and GNOME and .. in the archive because they are really > different, but this is more like the kernel having 3 different drivers > for NCR53c8xx SCSI chips, and how should the user know which to use and > why (difference in the scale, obviously)... Users can still have the freedom to choose. XSF will only support one, but other people are perfectly allowed to package other servers. Noone will ever stop them to do so. Fabio -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.
Re: Future of X packages in Debian
On Fri, 18 Jun 2004, Andreas Metzler wrote: > Fabio Massimo Di Nitto <[EMAIL PROTECTED]> wrote: > [...] > > * What kinds of X packages would you like to see in the future? > > As a user, all I care about: > * DFSG-free That's one of the reason we need to change. > * is ready whenever Debian would like to make a release, i.e. X should > not be the delaying point itself. Since 4.3.0.dfsg it has always been ready for release. We even delayed uploads to let the previous version entering sarge. Branden and I agreed that each release has to be a "good" one for stable. Of course we cannot avoid the unpredictable as i am sure everybody understand. > > * Should we go our own way starting from the "sanitized" XFree86 CVS > > snapshot we've prepared? > > Do you think this is sustainable? Currently the status s quite good, as > many drivers have been backported, but I doubt this can continue > eternally. Personally (i am not wearing any hat other than a user of my our own packages) no. It would be overkilling in time. > > * Should we ensure that multiple implementations of the X Window System > > are packaged, or standardize on just one? > > I cannot think of why it would be useful to have e.g. libx11.so from > both xorg and http://freedesktop.org/Software/xlibs in Debian. - Apart > from the fact that they are the same code the interfaces are > standardized. > > Afaict the X-strike force _cannot_ ensure that only a single > implementation is packaged, they can only choose the package only a > single implementation themselves. This is a good point that other people have already discussed in the thread. > > * If we standardize on just one, which one should it be? > [...] > > The one that is going to fulfill the criteria listed at the top of the > screen when we are thinking about releasing sarge+1. We are only thinking of sarge+1 here. There would be no time to switch tree (speaking quality wise). Fabio -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.
Re: Future of X packages in Debian
On Fri, 18 Jun 2004, Greg Folkert wrote: > > * What kinds of X packages would you like to see in the future? > > I'd like to see a packaging that gives me the ability to mix and match > pieces from any of the choices we have available. IOW, meta packages to > get the "full" compliment of each version, or me picking cheeries if I > want. Lotsa work... But hey, you said you wanted to know. eheh but i doubt the XSF will have manpower to handle more than one implementation. Other people can join and package other parts from other sources. > > We will do our best to choose a course that reflects the wishes and needs > > of the Debian community. Your feedback is a great first step, but we can > > always use more help. If you'd like to influence the direction of Debian > > X packaging, the best thing to do is to join the maintenance team. > > Please subscribe to debian-x, and if it's not obvious to you what you can > > do to help, just ask. > > As I am not a programmer, I'll have to ask "What would I *get* to do?" There is really a lot that you can do. In the first place you might have hardware that we do not have. You can help us testing the packages and report bugs before we release. Even if it seems simple it is a great contribution to know that the work we are doing is actually tested more than by only Branden and me. Thanks Fabio -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.
Re: Future of X packages in Debian
On Sun, 20 Jun 2004, Daniel Stone wrote: > I think we can all agree here; I hope, anyway. Yes at least i do (not wearing any hat). > I personally have an affinity for the modular tree, as it solves many > problems; my bias here being that I'm a (currently, paid) developer on > it. > > Here are the possibilities: > Libs: > * fd.o - needs libX11 merged, and a couple more client-side > libs. Other than that, fine. Uses autotools; one module per > library/extension. > * X.Org - monolithic tree with imake. IPv6 support. > * XFree86 - monolithic tree with imake. > Server: > * X.Org - monolithic tree with imake. IPv6 support. DRI tree > merged in CVS. > * XFree86 - monolithic tree with imake. > * debrix - modular tree with autotools, comes from X.Org tree. > No GL support as yet (that part of the world is particularly > nasty WRT imake hackage). > Apps: > * X.Org/XFree86 - monolithic tree with imake. > * fd.o - modular tree with autotools; not that many apps merged > yet. > Fonts: > * X.Org/XFree86 - monolithic tree with imake. > Docs: > * X.Org/XFree86 - monolithic tree with imake. > > As can be seen here, the operational word for modular is 'not there > yet'. The libX11 changes made in X.Org in the run-up to R6.7 still need > to be merged (I'm hoping to get to that this weekend), and it still > needs a few libs, such as libXvMC, but is rounding out very quickly. > Most libs are relatively trivial to add. > > Fonts and docs are a clear decision: the monolithic tree is the only > provider of these. Despite best intentions (and efforts), most apps are > still only available in the monolithic tree. > > The server arena is where it gets interesting - it's where we have the > most to gain, but the most to lose. debrix is a quite ambitious > proof-of-concept, aiming to prove three concepts: > a) modular builds for servers work (proved), > b) dlloader works/can be made to work (proved), > c) out-of-tree builds for drivers work (proved). > nice layout of the situation :-) > We could also start the slow app migration, and autotool missing apps as > we go; for the time being, just disable the ones that are there. Moving > to Thomas Dickey's xterm entirely would also be nice. > > Thus, my short-term proposal is: > * Libraries: fd.o, from /cvs/xlibs, according to > http://people.debian.org/~daniels/xlibs.html. > * Server: X.Org, built from the monolithic tree. > * Apps: Mix of monolithic and some broken-out apps - gradual > migration towards modular. > * Docs/Fonts: X.Org, built from the monolithic tree. > > If the DDK patches were merged, this might also significantly ease the > pain WRT drivers. My preferred long-term solution obviously involves > moving to the modular tree. > > If we continue to have a single monolithic 'xorg' source package, we can > keep working from this, while in parallel working upstream on the > modularisation efforts. This provides a good solution to the problem of > slowly-drifting X implementations (the libraries are particularly > worrying), and also alleviates our workload, as we can start merging > some of our hundreds of thousands of lines of patches into the parts > we've modularised. > > This means that we can disable app building one-by-one, get rid of the > fonts, docs, et al, and eventually also the server. > > I am willing to expend significant work on this; indeed, I'm in the > middle of my rejuvinated xlibs work, and am prepared to put in the work > to disable the libs on the server side - all the packaging work that > would be needed to transition to using fd.o xlibs. How would you perform such a transition without packaging madness? I am afraid that we will endup in a big mess of Conflicts: Replaces: Provides: that we will have to support across at least one major release. (hey just from a fast look.) Fabio
X Strike Force XFree86 SVN commit: r1557 - trunk/debian
Author: branden Date: 2004-06-22 13:16:23 -0500 (Tue, 22 Jun 2004) New Revision: 1557 Modified: trunk/debian/CHANGESETS trunk/debian/TODO trunk/debian/changelog trunk/debian/xlibs.bug Log: Enhance xlibs package's bug script to report compiled XKB data for X server, if possible. Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-06-22 17:43:26 UTC (rev 1556) +++ trunk/debian/CHANGESETS 2004-06-22 18:16:23 UTC (rev 1557) @@ -40,4 +40,8 @@ (Closes: #255464) 1555, 1556 +Enhance xlibs package's bug script to report compiled XKB data for X +server, if possible. +1557 + vim:set ai et sts=4 sw=4 tw=80: Modified: trunk/debian/TODO === --- trunk/debian/TODO 2004-06-22 17:43:26 UTC (rev 1556) +++ trunk/debian/TODO 2004-06-22 18:16:23 UTC (rev 1557) @@ -17,7 +17,6 @@ 4.3.0.dfsg.1-6 -- -* Enhance xlibs bug script to include output of "xkbcomp $DISPLAY -o -". * Add "How to Use This Document" and "Acknowledgements" sections to FAQ. * Update FAQ entry about X Window System history to reflect developments over the past year with x.org, freedesktop.org, and The XFree86 Project, Inc. Modified: trunk/debian/changelog === --- trunk/debian/changelog 2004-06-22 17:43:26 UTC (rev 1556) +++ trunk/debian/changelog 2004-06-22 18:16:23 UTC (rev 1557) @@ -23,12 +23,15 @@ * Update Danish debconf template translations (thanks, Claus Hindsgaul). (Closes: #255184) + * Enhance xlibs package's bug script to report compiled XKB data for X +server, if possible. + Changes by Fabio Massimo Di Nitto: * Update French debconf template translations (thanks, Christian Perrier). (Closes: #255464) - -- Branden Robinson <[EMAIL PROTECTED]> Tue, 22 Jun 2004 12:41:27 -0500 + -- Branden Robinson <[EMAIL PROTECTED]> Tue, 22 Jun 2004 13:15:22 -0500 xfree86 (4.3.0.dfsg.1-5) unstable; urgency=low Modified: trunk/debian/xlibs.bug === --- trunk/debian/xlibs.bug 2004-06-22 17:43:26 UTC (rev 1556) +++ trunk/debian/xlibs.bug 2004-06-22 18:16:23 UTC (rev 1557) @@ -21,4 +21,19 @@ printf "\n" >&3 -# vim:set ai et sts=4 sw=4 tw=0: +if which xkbcomp >/dev/null 2>&1; then +if [ -n "$DISPLAY" ]; then +printf "Compiled XKB description for X server \"%s\":\n" "$DISPLAY" >&3 +if ! xkbcomp -o - "$DISPLAY" >&3; then +printf "xkbcomp command reported failure.\n" >&3 +fi +else +printf "Cannot report compiled XKB description; \$DISPLAY null or undefined.\n" +fi +else +printf "xkbcomp command not available.\n" >&3 +fi + +printf "\n" >&3 + +# vim:set ai et sts=4 sw=4 tw=80:
Re: Future of X packages in Debian
On Sat, Jun 19, 2004 at 02:40:57PM +0100, Martin Michlmayr wrote: > * Fabio Massimo Di Nitto <[EMAIL PROTECTED]> [2004-06-18 09:02]: > > * Should we regard X.Org or FreeDesktop.Org as our upstream source? > > Yes, I'd go with one of them. Keith Packard is also in the NM queue > and interested in helping out. > > > * Should we go our own way starting from the "sanitized" XFree86 CVS > > snapshot we've prepared? > > I think this would be a really bad idea. I think it would be much > better to try to get all of our patches integrated upstream, and I > hear that the new upstream people (X.Org/FreeDesktop.Org) are much > more interested in integrating porting patches than XFree86 was. > Since Keith Packard is also on our lists, I hope that he'll help with > forwarding patches upstream and getting them integrated. Anyone can forward patches upstream. There are a reasonable amount of people who can integrate them. Once libX11 is merged with the monolithic tree[0], I'm going to be throwing the xlibs tree open to features again, including patch merges from the major vendors as a priority. [0]: Changes made since it was branched off the monolithic tree back in November or something and X11R6.7. -- Daniel Stone<[EMAIL PROTECTED]> Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
Bug#255744: xserver-xfree86: X fails to load if psmouse module managed by hotplug
Package: xserver-xfree86 Version: 4.3.0.dfsg.1-4 Severity: important If the system is powered up and X is started by kdm, X will often fail because of a missing core pointer. Starting X manually immediately after (e.g. using /etc/init.d/kdm start), always succeeds. The problem goes away if psmouse is added to /etc/modules. I have seen this problem myself on two different systems and [1] has two more people with the same problem. In all cases the solution above worked. In my case, I did a fresh Sarge install using Debian Installer on both systems. By default the mouse driver and related modules (like evdev) will be managed by hotplug. This means that psmouse is only loaded after X is started and probes for the presence of the core pointer. I think the time out allowed by X is to short for the drivers to load, so X can't find the mouse, the load fails and the user is returned to the console. Adding psmouse in /etc/modules ensures that the drivers are loaded much earlier in the bootprocess, so X is able to locate the mouse without problem. I think this bug is important because a lot of installs with Sarge's new installer are likely to be affected by this problem. The problem has been observed 4 times using kdm, but I would think it applies to other display managers as well. [1] http://lists.debian.org/debian-kde/2004/06/msg00159.html I have not included config and log files as the problem is currently fixed on my system using the solution listed above. I can however easily reproduce a log file if needed (on request). TIA, Frans Pop -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.5.20040613-1 Locale: LANG=C, LC_CTYPE=C Versions of packages xserver-xfree86 depends on: ii debconf [debconf-2.0] 1.4.25 Debian configuration management sy ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an ii xserver-common4.3.0.dfsg.1-4 files and utilities common to all ii zlib1g1:1.2.1.1-3compression library - runtime -- debconf information: * xserver-xfree86/config/device/identifier: Generic Video Card xserver-xfree86/config/monitor/screen-size: 17 inches (430 mm) xserver-xfree86/config/device/use_fbdev: * xserver-xfree86/config/monitor/selection-method: Medium xserver-xfree86/config/doublequote_in_string_error: shared/default-x-server: xserver-xfree86 * xserver-xfree86/config/inputdevice/mouse/emulate3buttons: true * xserver-xfree86/config/device/bus_id: PCI:0:2:0 * xserver-xfree86/config/inputdevice/keyboard/layout: us xserver-xfree86/config/monitor/horiz-sync: 30-60 * xserver-xfree86/config/monitor/identifier: Generic Monitor shared/no_known_x-server: xserver-xfree86/autodetect_mouse: true * xserver-xfree86/config/device/video_ram: * xserver-xfree86/config/monitor/mode-list: 1024x768 @ 75Hz * xserver-xfree86/config/monitor/lcd: true xserver-xfree86/config/inputdevice/keyboard/internal: * xserver-xfree86/config/inputdevice/keyboard/rules: xfree86 xserver-xfree86/multiple_possible_x-drivers: * xserver-xfree86/config/inputdevice/keyboard/model: pc104 * xserver-xfree86/config/write_dri_section: true * xserver-xfree86/config/device/driver: i810 xserver-xfree86/config/monitor/vert-refresh: 50-75 * xserver-xfree86/config/display/default_depth: 24 * xserver-xfree86/config/inputdevice/mouse/zaxismapping: true * xserver-xfree86/config/display/modes: 1024x768, 800x600, 640x480 xserver-xfree86/config/device/bus_id_error: * xserver-xfree86/config/modules: GLcore, bitmap, dbe, ddc, dri, extmod, freetype, glx, int10, record, speedo, type1, vbe * xserver-xfree86/config/inputdevice/keyboard/options: xserver-xfree86/config/nonnumeric_string_error: * xserver-xfree86/config/inputdevice/mouse/protocol: ImPS/2 shared/multiple_possible_x-servers: xserver-xfree86/config/null_string_error: xserver-xfree86/config/monitor/range_input_error: * xserver-xfree86/autodetect_video_card: true * xserver-xfree86/config/inputdevice/keyboard/variant: * xserver-xfree86/config/inputdevice/mouse/port: /dev/psaux * xserver-xfree86/config/write_files_section: true xserver-xfree86/autodetect_monitor: true
Re: Future of X packages in Debian
On Tuesday 22 June 2004 19.53, Fabio Massimo Di Nitto wrote: [packaging more than one X server] > Users can still have the freedom to choose. XSF will only support one, > but other people are perfectly allowed to package other servers. Noone > will ever stop them to do so. My point was exactly the oposite: users will probably not want to havte to chose, unless the choices are really different. Multiple X servers where one does 'A' a little better, but 'B' a little worse, and another does 'A' worse but 'B' good, and 'C' does only work really on the third X server which can't be reasonably used because of 'K', ... - in other words: if I need an export to explain to me how the different choices differ, I don't think it's a benefit to the users. So long - I think I've made my point. -- vbi [I'm not on debian-x, so you'll need to cc: me.] -- featured product: SpamAssassin - http://spamassassin.org pgphwL3KWPMLB.pgp Description: signature
Re: Future of X packages in Debian
On Tue, 2004-06-22 at 13:57, Fabio Massimo Di Nitto wrote: > On Fri, 18 Jun 2004, Greg Folkert wrote: > > > * What kinds of X packages would you like to see in the future? > > > > I'd like to see a packaging that gives me the ability to mix and match > > pieces from any of the choices we have available. IOW, meta packages to > > get the "full" compliment of each version, or me picking cheeries if I > > want. Lotsa work... But hey, you said you wanted to know. > > eheh but i doubt the XSF will have manpower to handle more than one > implementation. Other people can join and package other parts from other > sources. Yes, I long for a future so bright from X "gamma" I gotta wear shades. > > > We will do our best to choose a course that reflects the wishes and needs > > > of the Debian community. Your feedback is a great first step, but we can > > > always use more help. If you'd like to influence the direction of Debian > > > X packaging, the best thing to do is to join the maintenance team. > > > Please subscribe to debian-x, and if it's not obvious to you what you can > > > do to help, just ask. > > > > As I am not a programmer, I'll have to ask "What would I *get* to do?" > > There is really a lot that you can do. In the first place you might have > hardware that we do not have. You can help us testing the packages and > report bugs before we release. Even if it seems simple it is a great > contribution to know that the work we are doing is actually tested more > than by only Branden and me. I have been doing that all along. I was using the 4.3.0 server from the linuxppc.org server and then when that became problem (I understand why) I started using Branden's archive location. This was all before 4.3.0-XXX went into experimental. I even have a coupla bugs to my credit. Have 8 Linux Systems at work running the business. One is a Mix of RedHat --> Debian on its way to Straight Debian. The rest are all Debian. I am, also, completely moving away from Microsoft products where possible. 6 machines at home also running Debian Only. Slowest one == 1.2GHz Duron \o/ !!! BTW, All machines I maintain are on Sid/Experimental. I use my two workstations as daily sacrifices to the dist-update GODS! Just to keep them happy. They then tell me to wait on some things or to continue on ahead. This seems to workout well. Lately the GODS, have been pleased... which is good. -- [EMAIL PROTECTED] REMEMBER ED CURRY! http://www.iwethey.org/ed_curry Novell's Directory Services is a competitive product to Microsoft's Active Directory in much the same way that the Saturn V is a competitive product to those dinky little model rockets that kids light off down at the playfield. -- Thane Walkup signature.asc Description: This is a digitally signed message part
Bug#255749: xterm: Dies with segmentation fault
Package: xterm
Version: 4.3.0.dfsg.1-5
Severity: normal
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.6-2-k7
Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.UTF-8
Versions of packages xterm depends on:
ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an
ii libexpat1 1.95.6-8 XML parsing C library - runtime li
ii libfontconfig12.2.2-2generic font configuration library
ii libfreetype6 2.1.7-2.1 FreeType 2 font engine, shared lib
ii libice6 4.3.0.dfsg.1-5 Inter-Client Exchange library
ii libncurses5 5.4-4 Shared libraries for terminal hand
ii libsm64.3.0.dfsg.1-5 X Window System Session Management
ii libxaw7 4.3.0.dfsg.1-5 X Athena widget set library
ii libxext6 4.3.0.dfsg.1-5 X Window System miscellaneous exte
ii libxft2 2.1.2-6FreeType-based font drawing librar
ii libxmu6 4.3.0.dfsg.1-5 X Window System miscellaneous util
ii libxpm4 4.3.0.dfsg.1-5 X pixmap library
ii libxrender1 0.8.3-7X Rendering Extension client libra
ii libxt64.3.0.dfsg.1-5 X Toolkit Intrinsics
ii xlibs 4.3.0.dfsg.1-5 X Window System client libraries m
ii xlibs-data4.3.0.dfsg.1-5 X Window System client data
-- no debconf information
execve("/usr/bin/X11/xterm", ["xterm", "2"], [/* 30 vars */]) = 0
uname({sys="Linux", node="tabernacle", ...}) = 0
brk(0) = 0x8093000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40017000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=84533, ...}) = 0
old_mmap(NULL, 84533, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40018000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/libXft.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P<\0\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=71896, ...}) = 0
old_mmap(NULL, 70912, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002d000
old_mmap(0x4003e000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x11000) = 0x4003e000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/libfontconfig.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\202"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=154916, ...}) = 0
old_mmap(NULL, 157528, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4003f000
old_mmap(0x40062000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x23000) = 0x40062000
old_mmap(0x40065000, 1880, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40065000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/libfreetype.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\345"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=447212, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40066000
old_mmap(NULL, 446176, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40067000
old_mmap(0x400cd000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x66000) = 0x400cd000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/libexpat.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240!\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=126248, ...}) = 0
old_mmap(NULL, 129252, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x400d4000
old_mmap(0x400f1000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x1c000) = 0x400f1000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/libXrender.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\25\0\000"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=28316, ...}) = 0
old_mmap(NULL, 31392, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x400f4000
old_mmap(0x400fb000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x6000) = 0x400fb000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/libXaw.so.7", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\
Re: Future of X packages in Debian
Keith Packard <[EMAIL PROTECTED]> writes: > So, the big question is how to get everyone back into a single tree. > Ideally, Egbert would let us just ditch the imake build system and move > X.Org to autotools in one big jump; we have almost all of the build > infrastructure ready and waiting in my 'research' trees. In case of a "big jump", is autotools the only alternative to imake ? There are other build system like scons or cons that could be used to build X. At one point you mentionned the shortcomings of autotools, it might be worth to check if cons or scons are more apt to build X than autotools. > Alternatively, we would slowly modify the X.Org tree imake build > infrastructure so that we could lay a modular autotools build system > alongside and build either way. At work (HP) we moved rather slowly from a homebrewed system based on make to a build system based on cons. Now we use cons to build a software (~ 1 million lines of C, Objective-C, C++) for Linux IA32 Linux IA64, HPUX for PA-RISC and IA-64. So cons is able to handle huge softwares. Hope this might help. Cheers
X Strike Force XFree86 SVN commit: r1558 - trunk/debian
Author: branden Date: 2004-06-22 16:36:54 -0500 (Tue, 22 Jun 2004) New Revision: 1558 Modified: trunk/debian/CHANGESETS trunk/debian/changelog Log: Fix my email address, which was butchered in the changelog due to $DEBEMAIL being undefined on my host. Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-06-22 18:16:23 UTC (rev 1557) +++ trunk/debian/CHANGESETS 2004-06-22 21:36:54 UTC (rev 1558) @@ -42,6 +42,6 @@ Enhance xlibs package's bug script to report compiled XKB data for X server, if possible. -1557 +1557, 1558 vim:set ai et sts=4 sw=4 tw=80: Modified: trunk/debian/changelog === --- trunk/debian/changelog 2004-06-22 18:16:23 UTC (rev 1557) +++ trunk/debian/changelog 2004-06-22 21:36:54 UTC (rev 1558) @@ -31,7 +31,7 @@ * Update French debconf template translations (thanks, Christian Perrier). (Closes: #255464) - -- Branden Robinson <[EMAIL PROTECTED]> Tue, 22 Jun 2004 13:15:22 -0500 + -- Branden Robinson <[EMAIL PROTECTED]> Tue, 22 Jun 2004 16:36:05 -0500 xfree86 (4.3.0.dfsg.1-5) unstable; urgency=low
Bug#254632: xterm update results in worse thread view in mutt running inside a GNU screen
On Tue, Jun 22, 2004 at 03:48:49AM +0200, Adrian Bunk wrote:
> The typescript file is attached.
It does show that screen isn't issuing the initialization string.
And in setting out to explain the results, I see the problem (the termcap).
Here's a readable version of the typescript from covering the initialization
through the first use of line-drawing text:
\n$ screen -r m\r
\n
\E7
\E[?47h
\E7
\E[r
\E[m
\E[?7h
\E[?1;3;4;6l
\E[4l
\E8
\E>
\E[4l
\E[?1h
\E=
\E[m^O
\E[1;76r
\E[H
\E[2J
\E[H
\E[2J
\E[7mq:Quit d:Del u:Undel s:Save c:Mailg:Group ?:Help
\rq:Q
\n
\E[m1
\E[5COct 16 Florian_Oelmaie ( 110) Antwort: Verst\344ndnisproblem zum Thema
op\r
\n2
\E[5COct 16 Peter Wintrich ( 25) ^Ntq^O>\r
\n3
A big chunk comes from the termcap initialization string (and has nothing
to do with line-drawing, so we can ignore that):
:is=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>:\
What's left consists mostly of cursor movement (\E[H), clearing (\E[J), some
text - and ^N/^O to turn on line-drawing temporarily. What I don't see is a
string such as \E)0. Referring to ctlseqs.ms
SO Shift Out (Ctrl-N) -> Switch to Alternate Character Set:
invokes the G1 character set.
ESC ) CDesignate G1 Character Set (ISO 2022)
C = 0 -> DEC Special Character and Line Drawing Set
This was not noticeable before #182, since xterm's initialization did
that (incorrectly). Fixing xterm exposed this error.
The termcap should have a string such as
:eA=\E)0:
which would tell screen how to initialize the alternate character set.
Here's a diff of NetBSD's termcap which shows when the bug was added:
> diff netbsd.tc-1.53 netbsd.tc-1.52
1c1
< # $NetBSD: termcap.src,v 1.53 2000/04/16 01:27:44 mycroft Exp $
---
> # $NetBSD: termcap.src,v 1.52 2000/02/14 05:41:11 jun Exp $
1745,1747c1745
< :RI=\E[%dC:UP=\E[%dA:\
< :ac=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~:\
< :ae=^O:al=\E[L:as=^N:bl=^G:cd=\E[J:\
---
> :RI=\E[%dC:UP=\E[%dA:ae=^O:al=\E[L:as=^N:bl=^G:cd=\E[J:\
1782c1780
< :tc=xterm-xf86-v33:
---
> :tc=xterm-r6:
See that 1.53 adds some of the line-drawing features, but omits "eA".
The termcap that comes with xterm has no line-drawing (to fit in 1023
bytes, you must choose features from line-drawing, color and function
keys). This change was from another source. It doesn't appear to be
copied from the termcaps I'm maintaining for ncurses. Anyway, it's
a NetBSD bug (appears to be in the current 1.84 file).
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
pgpqVkxKCfrPY.pgp
Description: PGP signature
X Strike Force XFree86 SVN commit: r1559 - trunk/debian
Author: branden Date: 2004-06-22 16:44:28 -0500 (Tue, 22 Jun 2004) New Revision: 1559 Modified: trunk/debian/CHANGESETS trunk/debian/xterm.docs Log: Refer to text version of XTerm FAQ by the correct filename. Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-06-22 21:36:54 UTC (rev 1558) +++ trunk/debian/CHANGESETS 2004-06-22 21:44:28 UTC (rev 1559) @@ -30,7 +30,7 @@ /usr/share/doc/xterm/xterm.faq.gz, not /usr/share/doc/xterm/xterm.faq.text.gz. Update xterm's doc-base information accordingly. -1543 +1543, 1559 Update Danish debconf template translations (thanks, Claus Hindsgaul). (Closes: #255184) Modified: trunk/debian/xterm.docs === --- trunk/debian/xterm.docs 2004-06-22 21:36:54 UTC (rev 1558) +++ trunk/debian/xterm.docs 2004-06-22 21:44:28 UTC (rev 1559) @@ -1,7 +1,7 @@ build-tree/xc/programs/xterm/README.i18n build-tree/xc/programs/xterm/xterm.log.html debian/local/xterm.faq.html -debian/local/xterm.faq.text.gz +debian/local/xterm.faq.gz debian/tmp/usr/X11R6/lib/X11/doc/PostScript/ctlseqs.ps debian/tmp/usr/X11R6/lib/X11/doc/ctlseqs.txt debian/tmp/usr/X11R6/lib/X11/doc/html/ctlseqs.html
howto/script for migration of ttf fonts into supported debian structure?
i have a couple of ttf fonts that i installed in one directory on my system. now after installing additional debian ttf-packages, i would like to have *one* clean solution for all fonts. is there a script that copies the fonts around, generates indexes etc for cases like this?
Re: Future of X packages in Debian
also sprach Dominique Dumont <[EMAIL PROTECTED]> [2004.06.22.2237 +0200]: > At one point you mentionned the shortcomings of autotools, it > might be worth to check if cons or scons are more apt to build > X than autotools. While I agree that autotools are mostly a pain, I also didn't find a viable alternative when I went on a quest recently. Scons is powerful and I can recommend it to anyone, but it is an automake replacement and features few to none of the features of autoconf. There is toc (toc.sf.net), but it's very GNU-centric, so I imagine that Debian may be happy with it as long as we don't start supporting BSD-userland. In addition, I know the toc author personally and can vouch for him: he's eager to incorporate improvements into the system, so I guess there could be an interesting synergy. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
COOPERATIVA DE VALORES
Efectivo Ahora, damos crédito a tus Ilusiones. Somos su solución para obtener crédito en el día sin mas requisitos que su cuenta corriente con chequera. El límite de crédito que desea lo determina el movimiento que tiene en su cuenta. Retire hoy mismo el efectivo que necesita, sin garantias adicionales. Tambien operamos con cuentas de Empresas RECUERDE: EN TODO EL PAIS. Seriedad y absoluta reserva para su tranquilidad. Consultenos, estamos para ayudarlo. Contactar: Srta. Ana Martinez 011-4815-4888 [EMAIL PROTECTED] EfectivoAhora.com Si este mail no es de su interes, contestar con la la palabra R3mov3r. Sepa disculpar las molestias. Identificacion:hercules
Bug#255749: xterm: Dies with segmentation fault
On Tue, Jun 22, 2004 at 09:40:14PM +0200, Mykola A. Nickishov wrote: > Package: xterm > Version: 4.3.0.dfsg.1-5 > Severity: normal > > > > -- System Information: > Debian Release: testing/unstable > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable') > Architecture: i386 (i686) > Kernel: Linux 2.6.6-2-k7 > Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.UTF-8 The strace tells me that it failed very early - but not much more than that. You might be able to get a walkback by running a copy of it without the setuid (which is used only for utmp updating), from gdb. > Versions of packages xterm depends on: > ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries > an > ii libexpat1 1.95.6-8 XML parsing C library - runtime > li > ii libfontconfig12.2.2-2generic font configuration > library > ii libfreetype6 2.1.7-2.1 FreeType 2 font engine, shared > lib > ii libice6 4.3.0.dfsg.1-5 Inter-Client Exchange library 4.3.0.dsfg.1-5 seems to be having problems (I'm using 4.3.0.dfsg.1-4 currently) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpU3cCjxAg7F.pgp Description: PGP signature
Bug#255749: xterm: Dies with segmentation fault
On Tue, Jun 22, 2004 at 06:32:09PM -0400, Thomas Dickey wrote: > On Tue, Jun 22, 2004 at 09:40:14PM +0200, Mykola A. Nickishov wrote: > > Package: xterm > > Version: 4.3.0.dfsg.1-5 > > Severity: normal > > > > > > > > -- System Information: > > Debian Release: testing/unstable > > APT prefers testing > > APT policy: (990, 'testing'), (500, 'unstable') > > Architecture: i386 (i686) > > Kernel: Linux 2.6.6-2-k7 > > Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.UTF-8 > > The strace tells me that it failed very early - but not much more than that. > You might be able to get a walkback by running a copy of it without the > setuid (which is used only for utmp updating), from gdb. [EMAIL PROTECTED]:~$ gdb xterm (gdb) run Starting program: /usr/X11R6/bin/xterm (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x40146af0 in XawTreeForceLayout () from /usr/X11R6/lib/libXaw.so.7 (gdb) So the problem was in libxaw7. After downgrading libxaw7 from 4.3.0.dfsg.1-5 to 4.3.0.dfsg.1-4 xterm works fine. Thank you, Thomas. -- MAN-UANIC Eclipse.org downloads @ http://eclipse.osdn.org.ua/ signature.asc Description: Digital signature
Bug#255772: libxaw7: xterm dies with segfault
Package: libxaw7 Version: 4.3.0.dfsg.1-5 Severity: normal xterm 4.3.0.dfsg.1-5 dies with SIGSEGV: [EMAIL PROTECTED]:~$ gdb xterm (gdb) run Starting program: /usr/X11R6/bin/xterm (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x40146af0 in XawTreeForceLayout () from /usr/X11R6/lib/libXaw.so.7 (gdb) After downgrading libxaw7 to 4.3.0.dfsg.1-4 problem has gone. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.6-2-k7 Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.UTF-8 Versions of packages libxaw7 depends on: ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an ii libice6 4.3.0.dfsg.1-5 Inter-Client Exchange library ii libsm64.3.0.dfsg.1-5 X Window System Session Management ii libxext6 4.3.0.dfsg.1-5 X Window System miscellaneous exte ii libxmu6 4.3.0.dfsg.1-5 X Window System miscellaneous util ii libxpm4 4.3.0.dfsg.1-5 X pixmap library ii libxt64.3.0.dfsg.1-5 X Toolkit Intrinsics ii xlibs 4.3.0.dfsg.1-5 X Window System client libraries m -- no debconf information
Bug#255749: xterm: Dies with segmentation fault
> So the problem was in libxaw7. After downgrading libxaw7 from > 4.3.0.dfsg.1-5 to 4.3.0.dfsg.1-4 xterm works fine. > > Thank you, Thomas. no problem (I think this one should be redirected to the X libraries) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpjloeHSq7Lk.pgp Description: PGP signature
Re: Future of X packages in Debian
On Tue, Jun 22, 2004 at 10:37:33PM +0200, Dominique Dumont wrote: > Keith Packard <[EMAIL PROTECTED]> writes: > > So, the big question is how to get everyone back into a single tree. > > Ideally, Egbert would let us just ditch the imake build system and move > > X.Org to autotools in one big jump; we have almost all of the build > > infrastructure ready and waiting in my 'research' trees. > > In case of a "big jump", is autotools the only alternative to imake ? > > There are other build system like scons or cons that could be used to > build X. > > At one point you mentionned the shortcomings of autotools, it might be > worth to check if cons or scons are more apt to build X than autotools. Sure, every build system sucks. It just so happens that autoconf sucks less than imake, and most everything else. One of the reasons we're moving, however (and this is a major reason), is that everyone knows autotools. People are comfortable with using it, and hacking it to some degree. Most people have autotools installed. Right now, we've already migrated xlibs, xapps (someone has autotooled a great deal of the missing xapps, which I discovered last night - word), and xserver and some of the drivers to autotools. We've already committed, and it's way too late to go back and work with a build system we're all unfamiliar with. -- Daniel Stone<[EMAIL PROTECTED]> Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
Re: Future of X packages in Debian
On Tue, Jun 22, 2004 at 07:57:44PM +0200, Fabio Massimo Di Nitto wrote: > On Fri, 18 Jun 2004, Greg Folkert wrote: > > > * What kinds of X packages would you like to see in the future? > > > > I'd like to see a packaging that gives me the ability to mix and match > > pieces from any of the choices we have available. IOW, meta packages to > > get the "full" compliment of each version, or me picking cheeries if I > > want. Lotsa work... But hey, you said you wanted to know. > > eheh but i doubt the XSF will have manpower to handle more than one > implementation. Other people can join and package other parts from other > sources. I don't think separate X servers will require too much work at all, once it's modularised. Remember, uploading tiny changes in tiny packages is *easy*. -- Daniel Stone<[EMAIL PROTECTED]> Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
Re: Future of X packages in Debian
On Tue, Jun 22, 2004 at 07:53:52PM +0200, Fabio Massimo Di Nitto wrote: > On Fri, 18 Jun 2004, Adrian 'Dagurashibanipal' von Bidder wrote: > > On Friday 18 June 2004 09.02, Fabio Massimo Di Nitto wrote: > > > * Should we ensure that multiple implementations of the X Window > > > System are packaged, or standardize on just one? > > > > from a user perspective, multiple X servers to chose from which are > > almost but not exaclty the same is most confusing. AFAICT this is not > > like having KDE and GNOME and .. in the archive because they are really > > different, but this is more like the kernel having 3 different drivers > > for NCR53c8xx SCSI chips, and how should the user know which to use and > > why (difference in the scale, obviously)... > > Users can still have the freedom to choose. XSF will only support one, but > other people are perfectly allowed to package other servers. Noone will > ever stop them to do so. I'm huge on the freedom to choose, but not so much on being *forced* to choose. Users should have the freedom to install KDrive if they want (IMHO this should be packaged), or whatever, but Xorg should come per default - most people aren't qualified to make that choice, and shouldn't have to. -- Daniel Stone<[EMAIL PROTECTED]> Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
Re: Future of X packages in Debian
On Tue, Jun 22, 2004 at 08:04:47PM +0200, Fabio Massimo Di Nitto wrote: > On Sun, 20 Jun 2004, Daniel Stone wrote: > > We could also start the slow app migration, and autotool missing apps as > > we go; for the time being, just disable the ones that are there. Moving > > to Thomas Dickey's xterm entirely would also be nice. > > > > Thus, my short-term proposal is: > > * Libraries: fd.o, from /cvs/xlibs, according to > > http://people.debian.org/~daniels/xlibs.html. > > * Server: X.Org, built from the monolithic tree. > > * Apps: Mix of monolithic and some broken-out apps - gradual > > migration towards modular. > > * Docs/Fonts: X.Org, built from the monolithic tree. > > > > If the DDK patches were merged, this might also significantly ease the > > pain WRT drivers. My preferred long-term solution obviously involves > > moving to the modular tree. > > > > If we continue to have a single monolithic 'xorg' source package, we can > > keep working from this, while in parallel working upstream on the > > modularisation efforts. This provides a good solution to the problem of > > slowly-drifting X implementations (the libraries are particularly > > worrying), and also alleviates our workload, as we can start merging > > some of our hundreds of thousands of lines of patches into the parts > > we've modularised. > > > > This means that we can disable app building one-by-one, get rid of the > > fonts, docs, et al, and eventually also the server. > > > > I am willing to expend significant work on this; indeed, I'm in the > > middle of my rejuvinated xlibs work, and am prepared to put in the work > > to disable the libs on the server side - all the packaging work that > > would be needed to transition to using fd.o xlibs. > > How would you perform such a transition without packaging madness? I am > afraid that we will endup in a big mess of Conflicts: Replaces: Provides: > that we will have to support across at least one major release. > (hey just from a fast look.) Not really - the xlibs bustup did most of the work for us, so we just need to provide higher versions[0] for the libs. The apps will need a good epoching, probably, and C/R xbase-clients. :) d [0]: A fair few of them are 6.x, but the rest will need an epoch. -- Daniel Stone<[EMAIL PROTECTED]> Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
