Bug#404090: marked as done (GPU temperature skyrockets after starting X)

[Debian Bug Tracking System]

Your message dated Fri, 22 Dec 2006 11:18:47 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Bug#404090: GPU temperature skyrockets after starting X
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)

--- Begin Message ---
Package: xserver-xorg-video-ati
Version: 1:6.6.3-2
Severity: important

Hi X Strike Force,

I'm fighting with my new (2nd hand) iBook G4 and found the following
behaviour in it:
(I don't run ?dm, the computer starts in text console mode)
- Start X, the GPU temperature starts to rise *very* quickly
- The temperature will reach 80 Celsius and fan will turn on
  (don't know how far it would go)
- No matter whether you remain in X or quit, the temperature won't
  descent

Now, if you suspend the laptop (by closing the lid) and resume
(just after a couple of secs.) not only the temperature will be
much lower, it will remain that low (~60C). That will happen
whether you suspend after quitting X OR even if you stay in X before
and after resuming.

So the problem seems to be in the initialization of the video card.

My video card conf:
Section "Device"
  Identifier  "Generic Video Card"
#  Driver  "radeon"
  Driver  "ati"
  BusID   "PCI:0:16:0"
  Option  "UseFBDev"
  "true"
  VendorName  "ATI"
# Option  "AGPMode" "4"
EndSection

I've tried both 'radeon' and 'ati' drivers and AGPMode 4 and none (1).
All with the same result. So it could be a kernel (module) problem
(2.6.19.1).

Thanks,

Alberto


-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.19.1
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages xserver-xorg-video-ati depends on:
ii  libc62.3.6.ds1-9 GNU C Library: Shared libraries
ii  xserver-xorg-core2:1.1.1-12  X.Org X server -- core server

xserver-xorg-video-ati recommends no packages.

-- no debconf information



-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
agi@(inittab.org|debian.org)| en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 9782 04E7 2B75 405C F5E9  0C81 C514 AF8E 4BA4 01C3

--- End Message ---
--- Begin Message ---
On Fri, Dec 22, 2006 at 07:55:38AM +0100, Michel Dänzer wrote:
> On Thu, 2006-12-21 at 17:37 +0100, Alberto Gonzalez Iniesta wrote:
> > 
> > I'm fighting with my new (2nd hand) iBook G4 and found the following
> > behaviour in it:
> > (I don't run ?dm, the computer starts in text console mode)
> > - Start X, the GPU temperature starts to rise *very* quickly
> > - The temperature will reach 80 Celsius and fan will turn on
> >   (don't know how far it would go)
> > - No matter whether you remain in X or quit, the temperature won't
> >   descent
> 
> If
> 
>   Option  "DynamicClocks"
> 
> doesn't help, please provide the full X log file.
> 
> 

Wow! That definitively solved it. Didn't find much docs on that and the
temperature thing, though. I'll close the bug now.

Thanks a lot,

Alberto


-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
agi@(inittab.org|debian.org)| en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 9782 04E7 2B75 405C F5E9  0C81 C514 AF8E 4BA4 01C3
--- End Message ---

Bug#404079: display problem with xterm + screen and bold characters

[Thomas Dickey]

On Thu, Dec 21, 2006 at 07:20:40PM -0500, Thomas Dickey wrote:
> On Thu, Dec 21, 2006 at 07:00:15PM +0100, Vincent Lefevre wrote:
> > Package: xterm
> > Version: 223-1
> > Severity: important
> > 
> > Not sure this is a bug in xterm, but the following problems don't occur
> > with rxvt.
> 
> This sounds like (see http://invisible-island.net/ncurses/NEWS.gz)
> 
> 20040710
> + modify logic in tgetent() which adjusts the termcap "me" string 
>  
>   to work with ISO-2022 string used in xterm-new (cf: 20010908).
> 
> also note the followups for sgr0 in that file.

If there's no new information here, there's nothing to fix (the fixes are
in ncurses 5.5, and there's no way other than by breaking the related
fixes for luit to make ncurses 5.4 work as you want).

Also note (as you already did) that there's a known workaround (use the
terminal description that uses the single-character ^N and ^O rather than
\E(B, etc.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgp7I6CXJWdh9.pgp
Description: PGP signature

Bug#403969: xserver-xorg: xserver crashing, mode related?

[Rob Bochan]

On Friday 22 December 2006 01:52, you wrote:
>
> Try
>
> LIBGL_DEBUG=verbose glxinfo 2>&1 >/dev/null

There are complaints about missing files relating to libglide3 (attached 
glx.log) and a file that doesn't seem to exist period (drirc), even via 
apt-cache search. I wasn't previously aware there was a libglide3, and don't 
recall it being any sort of dependency for the tdfx driver. I've had 
libglide2 for a while now. I just installed libglide3 and ran the same 
command (attached glx-postglide3.log), and there were related errors.
I also temporarily commented the AIGLX line from my xorg.conf, that you 
advised earlier, but the crashes reoccurred.

-- 

...Rob
$ LIBGL_DEBUG=verbose glxinfo 2>&1 >/dev/null
libGL: XF86DRIGetClientDriverName: 1.3.0 tdfx (screen 0)
libGL: OpenDriver: trying /usr/lib/dri/tdfx_dri.so
drmOpenByBusid: Searching for BusID pci::01:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
drmOpenByBusid: drmOpenMinor returns 4
drmOpenByBusid: drmGetBusid reports pci::01:00.0
libGL warning: 3D driver claims to not support visual 0x25
libGL warning: 3D driver claims to not support visual 0x26
libGL warning: 3D driver claims to not support visual 0x29
libGL warning: 3D driver claims to not support visual 0x2a
libGL warning: 3D driver claims to not support visual 0x2d
libGL warning: 3D driver claims to not support visual 0x2e
libGL warning: 3D driver claims to not support visual 0x31
libGL warning: 3D driver claims to not support visual 0x32
libGL warning: 3D driver claims to not support visual 0x35
libGL warning: 3D driver claims to not support visual 0x36
libGL warning: 3D driver claims to not support visual 0x39
libGL warning: 3D driver claims to not support visual 0x3a
libGL warning: 3D driver claims to not support visual 0x3d
libGL warning: 3D driver claims to not support visual 0x3e
libGL warning: 3D driver claims to not support visual 0x41
libGL warning: 3D driver claims to not support visual 0x42
libGL error: 
Can't open configuration file /etc/drirc: No such file or directory.
libGL error: 
Can't open configuration file /home/rbochan/.drirc: No such file or directory.
libGL error: 
can't find Glide library, dlopen(libglide3-v5.so) and dlopen(libglide3.so) both failed.
libGL error: 
dlerror() message: libglide3.so: cannot open shared object file: No such file or directory
$ LIBGL_DEBUG=verbose glxinfo 2>&1 >/dev/null
libGL: XF86DRIGetClientDriverName: 1.3.0 tdfx (screen 0)
libGL: OpenDriver: trying /usr/lib/dri/tdfx_dri.so
drmOpenByBusid: Searching for BusID pci::01:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
drmOpenByBusid: drmOpenMinor returns 4
drmOpenByBusid: drmGetBusid reports pci::01:00.0
libGL warning: 3D driver claims to not support visual 0x25
libGL warning: 3D driver claims to not support visual 0x26
libGL warning: 3D driver claims to not support visual 0x29
libGL warning: 3D driver claims to not support visual 0x2a
libGL warning: 3D driver claims to not support visual 0x2d
libGL warning: 3D driver claims to not support visual 0x2e
libGL warning: 3D driver claims to not support visual 0x31
libGL warning: 3D driver claims to not support visual 0x32
libGL warning: 3D driver claims to not support visual 0x35
libGL warning: 3D driver claims to not support visual 0x36
libGL warning: 3D driver claims to not support visual 0x39
libGL warning: 3D driver claims to not support visual 0x3a
libGL warning: 3D driver claims to not support visual 0x3d
libGL warning: 3D driver claims to not support visual 0x3e
libGL warning: 3D driver claims to not support visual 0x41
libGL warning: 3D driver claims to not support visual 0x42
libGL error: 
Can't open configuration file /etc/drirc: No such file or directory.
libGL error: 
Can't open configuration file /home/rbochan/.drirc: No such file or directory.
libGL error: 
can't find Glide library, dlopen(libglide3-v5.so) and dlopen(libglide3.so) both failed.
libGL error: 
dlerror() message: /usr/lib/libglide3.so: undefined symbol: __LINE__

Bug#404079: display problem with xterm + screen and bold characters

[Vincent Lefevre]

On 2006-12-22 06:27:26 -0500, Thomas Dickey wrote:
> If there's no new information here, there's nothing to fix (the
> fixes are in ncurses 5.5, and there's no way other than by breaking
> the related fixes for luit to make ncurses 5.4 work as you want).

The problem is that Debian/stable still provides ncurses 5.4.
So, there must be a fix for Debian.

Also, concerning Mac OS X, though I have ncurses 5.5 installed (via
MacPorts), the problem is that several programs are written for curses
(instead of ncurses), and ncurses 5.5 doesn't provide compatibility
links. I've already reported a few bugs for MacPorts and written a few
fixes, e.g.

  http://trac.macosforge.org/projects/macports/ticket/11157

> Also note (as you already did) that there's a known workaround (use the
> terminal description that uses the single-character ^N and ^O rather than
> \E(B, etc.

But this time, these characters break "less"!

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399848

And I don't know if this is related to changes in ncurses:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403612

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#403969: xserver-xorg: xserver crashing, mode related?

[Michel Dänzer]

retitle 403969 tdfx crashes X with AIGLX but without (working) libglide3
kthxbye

On Fri, 2006-12-22 at 08:10 -0500, Rob Bochan wrote:
> On Friday 22 December 2006 01:52, you wrote:
> >
> > Try
> >
> > LIBGL_DEBUG=verbose glxinfo 2>&1 >/dev/null
> 
> There are complaints about missing files relating to libglide3 (attached 
> glx.log) and a file that doesn't seem to exist period (drirc), even via 
> apt-cache search. 

It's an optional configuration file.

> I wasn't previously aware there was a libglide3, and don't 
> recall it being any sort of dependency for the tdfx driver. 

See bug #387339.

> I just installed libglide3 and ran the same command (attached 
> glx-postglide3.log), and there were related errors.

That's bug #326099/#329920.

> I also temporarily commented the AIGLX line from my xorg.conf, that you 
> advised earlier, but the crashes reoccurred.

Yeah, it's still falling back to indirect rendering without a working
Glide. It's possible that a working Glide would also fix the AIGLX crash
with indirect rendering, in which case this would be another duplicate
of the libglide3 bugs above, but I'm just changing the title for now.


-- 
Earthling Michel Dänzer   |  http://tungstengraphics.com
Libre software enthusiast |  Debian, X and DRI developer

Processed: Re: Bug#403969: xserver-xorg: xserver crashing, mode related?

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> retitle 403969 tdfx crashes X with AIGLX but without (working) libglide3
Bug#403969: xserver-xorg: xserver crashing, mode related?
Changed Bug title.

> kthxbye
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#397084: 1:2.1.1-4 from snapshot.debian.net works

[Mikko Rapeli]

Previous version of xserver-xorg-video-savage does not seem to have this
bug, so downgrading to 1:2.1.1-4 is a workaround:

http://snapshot.debian.net/package/xserver-xorg-video-savage

-Mikko


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#404079: display problem with xterm + screen and bold characters

[Thomas Dickey]

On Fri, Dec 22, 2006 at 03:04:53PM +0100, Vincent Lefevre wrote:
> On 2006-12-22 06:27:26 -0500, Thomas Dickey wrote:
> > If there's no new information here, there's nothing to fix (the
> > fixes are in ncurses 5.5, and there's no way other than by breaking
> > the related fixes for luit to make ncurses 5.4 work as you want).
> 
> The problem is that Debian/stable still provides ncurses 5.4.
> So, there must be a fix for Debian.
> 
> Also, concerning Mac OS X, though I have ncurses 5.5 installed (via
> MacPorts), the problem is that several programs are written for curses
> (instead of ncurses), and ncurses 5.5 doesn't provide compatibility
> links. I've already reported a few bugs for MacPorts and written a few
> fixes, e.g.
> 
>   http://trac.macosforge.org/projects/macports/ticket/11157

I've seen some confusing comments about Mac OS X "curses" versus "ncurses",
but am left with the impression that it's still ncurses (in a different
directory, etc, but still the same code).

Even still, 5.4 is nearly three years old, and there's a year-old 5.5
release which Mac OS X should be using.
 
> > Also note (as you already did) that there's a known workaround (use the
> > terminal description that uses the single-character ^N and ^O rather than
> > \E(B, etc.
> 
> But this time, these characters break "less"!
> 
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399848

That's odd, since "less" has always been a termcap application.
Perhaps it's a regression, e.g., changes by someone using a terminfo
underneath.
 
> And I don't know if this is related to changes in ncurses:
> 
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403612

Since "less" uses only the termcap interface, it would only be
related to changes in that one area.

Essentially the changes to sgr0 were made necessary by a long-ago equating
of terminfo "sgr0" and termcap "me".  They're not identical:

a) several years ago, I made changes to allow termcap applications
   to assume that "me" (sgr0) did not reset line-drawing since
   termcap applications generally did not support that feature.

b) that change only worked for single-bytes - and the change
   I noted yesterday was a fix for that.  The fix was needed to
   allow using multi-byte \E(B, etc., to support luit.

c) further changes past that point were refinement (improving
   the interaction with applications that had not been fixed
   with (b)).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgp2LQu7pDGhV.pgp
Description: PGP signature

Bug#403969: xserver-xorg: xserver crashing, mode related?

[Rob Bochan]

On Friday 22 December 2006 09:22, you wrote:
> retitle 403969 tdfx crashes X with AIGLX but without (working) libglide3
> kthxbye
>
> On Fri, 2006-12-22 at 08:10 -0500, Rob Bochan wrote:
> > On Friday 22 December 2006 01:52, you wrote:
> > > Try
> > >
> > > LIBGL_DEBUG=verbose glxinfo 2>&1 >/dev/null
> >
> > There are complaints about missing files relating to libglide3 (attached
> > glx.log) and a file that doesn't seem to exist period (drirc), even via
> > apt-cache search.
>
> It's an optional configuration file.

Okay.

> > I wasn't previously aware there was a libglide3, and don't
> > recall it being any sort of dependency for the tdfx driver.
>
> See bug #387339.

Fair enough.

> > I just installed libglide3 and ran the same command (attached
> > glx-postglide3.log), and there were related errors.
>
> That's bug #326099/#329920.
>
> > I also temporarily commented the AIGLX line from my xorg.conf, that you
> > advised earlier, but the crashes reoccurred.
>
> Yeah, it's still falling back to indirect rendering without a working
> Glide. It's possible that a working Glide would also fix the AIGLX crash
> with indirect rendering, in which case this would be another duplicate
> of the libglide3 bugs above, but I'm just changing the title for now.

Considering the age of those, I doubt there will be any sort of resolution 
before the kids show up next week for LAN games over the holidays :o(

Since these packages are also now in Etch, I guess I don't have much of a 
choice but to go back to Sarge until they're resolved. I'm no coder, but if 
there's anything at all I can do to help, I'd be glad to do what I can.

-- 

...Rob


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#404079: display problem with xterm + screen and bold characters

[Vincent Lefevre]

On 2006-12-22 10:07:25 -0500, Thomas Dickey wrote:
> I've seen some confusing comments about Mac OS X "curses" versus "ncurses",
> but am left with the impression that it's still ncurses (in a different
> directory, etc, but still the same code).

Mac OS X 10.4.x uses ncurses, even with the curses API.

> Even still, 5.4 is nearly three years old, and there's a year-old
> 5.5 release which Mac OS X should be using.

We could say the same thing for the current Debian/stable.
Now I just hope that Mac OS X 10.5 will use ncurses 5.5.

> > > Also note (as you already did) that there's a known workaround
> > > (use the terminal description that uses the single-character ^N
> > > and ^O rather than \E(B, etc.
> > 
> > But this time, these characters break "less"!
> > 
> >   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399848
> 
> That's odd, since "less" has always been a termcap application.
> Perhaps it's a regression, e.g., changes by someone using a terminfo
> underneath.

According to ldd, less uses libncurses (not libtermcap).
The less man page says:

  Less uses termcap (or terminfo on some systems) [...]

/usr/share/doc/less/README.Debian doesn't say anything.

> > And I don't know if this is related to changes in ncurses:
> > 
> >   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403612
> 
> Since "less" uses only the termcap interface, it would only be
> related to changes in that one area.

Changing the terminfo database (e.g. with infocmp to retrieve some
data + tic to install them, possibly modified, in my $HOME directory)
changed the behavior.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#404079: display problem with xterm + screen and bold characters

[Thomas Dickey]

On Fri, Dec 22, 2006 at 07:56:55PM +0100, Vincent Lefevre wrote:
> On 2006-12-22 10:07:25 -0500, Thomas Dickey wrote:
> > I've seen some confusing comments about Mac OS X "curses" versus "ncurses",
> > but am left with the impression that it's still ncurses (in a different
> > directory, etc, but still the same code).
> 
> Mac OS X 10.4.x uses ncurses, even with the curses API.
> 
> > Even still, 5.4 is nearly three years old, and there's a year-old
> > 5.5 release which Mac OS X should be using.
> 
> We could say the same thing for the current Debian/stable.
> Now I just hope that Mac OS X 10.5 will use ncurses 5.5.

Or the more straightforward solution - I'm running ncurses 5.6 on all
platforms.  Aside from being a nuisance, there's no problem updating
just the libraries.

Given the glacial progress of the *BSD's in updating packages,
it's not unlikely that they'll remain 2-3 years behind indefinitely.

> > > > Also note (as you already did) that there's a known workaround
> > > > (use the terminal description that uses the single-character ^N
> > > > and ^O rather than \E(B, etc.
> > > 
> > > But this time, these characters break "less"!
...
> Changing the terminfo database (e.g. with infocmp to retrieve some
> data + tic to install them, possibly modified, in my $HOME directory)
> changed the behavior.

hmm - since you said "less" does not recognize ^N/^O, I'm assuming you
meant that you changed sgr0 to \E[m, which works for termcap, but not
for applications that use line-drawing (without of course hardcoding
things).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpee16uzWmrd.pgp
Description: PGP signature

Bug#404079: display problem with xterm + screen and bold characters

[Vincent Lefevre]

On 2006-12-22 15:42:45 -0500, Thomas Dickey wrote:
> Or the more straightforward solution - I'm running ncurses 5.6 on all
> platforms.  Aside from being a nuisance, there's no problem updating
> just the libraries.

I prefer to have them (libraries compiled by the user) in a separate
directory. Applications that use ncurses should also be recompiled.

But in addition to my Mac OS X machine, I have lots of accounts,
so that this is annoying.

> Given the glacial progress of the *BSD's in updating packages,
> it's not unlikely that they'll remain 2-3 years behind indefinitely.

For several things, Mac OS X is more up-to-date than Debian/stable.

> hmm - since you said "less" does not recognize ^N/^O, I'm assuming you
> meant that you changed sgr0 to \E[m,

I think I'll change that back to \E[m because of this problem.

> which works for termcap, but not for applications that use
> line-drawing (without of course hardcoding things).

Well the applications that use line-drawing seem to use rmacs
explicitly (I think they should all do that for a few years
for compatibility). Then having the rmacs escape sequence in
sgr0 is useless for these applications, isn't it?

I also have the following in my precmd() in zsh:

  [[ -n $zsh410 && -n $TTY && -n $terminfo ]] &&
print -n "$terminfo[rmacs]$terminfo[sgr0]" > $TTY

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#398860: savage: a fix for respawn crash regression

[Mikko Rapeli]

Hello, 

The savage driver some time a go started crashing when respawned from
kdm et al. When MapMMIO and MapFB functions were merged to MapMem[1], one 
MapFB call in SavageScreenInit was not replaced with MapMem:

http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-savage.git;a=commitdiff_plain;h=2f8352df6488476b0c1a46798eca5dd38827444b;hp=6f9abbb972834561cd8494a1d4fb47402b285d7d

Here's a patch which fixes the issue. It works on my Thinkpad T20,
though I don't really understand the details.

-Mikko

--- xserver-xorg-video-savage-2.1.2.orig/src/savage_driver.c
+++ xserver-xorg-video-savage-2.1.2/src/savage_driver.c
@@ -3088,6 +3088,9 @@
  
 SavageEnableMMIO(pScrn);
 
+if (!SavageMapMem(pScrn))
+return FALSE;
+
 psav->FBStart2nd = 0;
 
 if (psav->overlayDepth) {



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#404079: display problem with xterm + screen and bold characters

[Thomas Dickey]

On Fri, Dec 22, 2006 at 10:17:06PM +0100, Vincent Lefevre wrote:
> On 2006-12-22 15:42:45 -0500, Thomas Dickey wrote:
> > Or the more straightforward solution - I'm running ncurses 5.6 on all
> > platforms.  Aside from being a nuisance, there's no problem updating
> > just the libraries.
> 
> I prefer to have them (libraries compiled by the user) in a separate
> directory. Applications that use ncurses should also be recompiled.

I suppose so.  In 5.6 I've revisited rpath linkage, and made it work
well enough for that, so I won't be recompiling ncurses applications
where they've been linked dynamically any more.  (Though checking, no
one's provided any information on rpath in Mac OS X - working from manpages
alone is futile).
 
> But in addition to my Mac OS X machine, I have lots of accounts,
> so that this is annoying.

I did mention that it was a nuisance...
 
> > Given the glacial progress of the *BSD's in updating packages,
> > it's not unlikely that they'll remain 2-3 years behind indefinitely.
> 
> For several things, Mac OS X is more up-to-date than Debian/stable.

I suppose so - 2-3 years behind the releases.
 
> > hmm - since you said "less" does not recognize ^N/^O, I'm assuming you
> > meant that you changed sgr0 to \E[m,
> 
> I think I'll change that back to \E[m because of this problem.

...and remove sgr (see below).
 
> > which works for termcap, but not for applications that use
> > line-drawing (without of course hardcoding things).
> 
> Well the applications that use line-drawing seem to use rmacs
> explicitly (I think they should all do that for a few years
> for compatibility). Then having the rmacs escape sequence in
> sgr0 is useless for these applications, isn't it?

Not exactly - most curses libraries use sgr if it's present.
In that case, I would expect them to use sgr0.  (I recall getting
burned with that on more than one Unix platform - sgr0 is expected
to reset the alternate character set).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpoHRXdtm4Xh.pgp
Description: PGP signature

Re: Debian XSF SVN to git migration

[Otavio Salvador]

David Nusinow <[EMAIL PROTECTED]> writes:

> It's a tough choice. The ease of use of stgit sounds really nice to me, but
> I also love the transparency that having the patches in a location like
> debian/patches affords us. I'm not horribly worried about that though, but
> it is a real benefit. We can get around that by artificially exporting all
> the patches to debian/patches. It's more work, although I'd be happy to
> write a simple script to do this. My feeling is that this would be the best
> of both worlds. What do you guys think?

I personally loves stgit and we're using it here on the company to
follow projects that use other patch systems like svn or when we're
developing a not yet ready for merging change. It does great.

The only problem that I found on stgit is the difficult to push its
full meta-data for the git repository. The only way I've found is to
use rsync. Comments on that?

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
 you the whole house."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Sahaved BLLACK Bcabe With Pouffy Nmipples Mdasturbating

[April Glover]

We're talking scum here. Air should be illegal if they breathe it.

EBXONY Bjabe Outdoor Shhows Tdits & Fuingered Plussy
http://wanna.luna-dog.com/

It doesn't do any good to sit up and take notice if you keep on 
sitting.Friendships begun in this world will be taken up again, never to be 
broken off.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]