Problems while using divecomputer-simulator for linux

[Dirk Hohndel]

On Sun, 2014-03-30 at 12:52 -0700, Linus Torvalds wrote:
> On Sun, Mar 30, 2014 at 12:14 PM, Venkatesh Shukla IIT BHU
> <venkatesh.shukla.eee11 at iitbhu.ac.in> wrote:
> The kernel didn't actually complain at all, and what seems to happen
> is that glibc tries to be "helpful", and after it has done the TCSETC
> it does a TCGETC and compares the result. And notices that the PARENB
> 
> And it looks like it notices that it tried to *set* c_cflags to 0xfbb
> but then it reads back c_cflags as 0xebb.
> 
> The difference is octal 0400, which is PARENB. Because under Linux,
> pty's always do
> 
>         tty->termios.c_cflag &= ~(CSIZE | PARENB);
>         tty->termios.c_cflag |= (CS8 | CREAD);
> 
> and glibc tries to be "helpful" and notice that some of the settings
> don't stick. For no good reason.
> 
> Now, I'm not saying that the kernel necessarily has to do the above
> for pty's (it could just ignore the bits, and not set them to what
> pty's actually do), but Linux has always done the above, so it's some
> idiotic change in glibc that now causes problems.
> 
> Don't ask me why the glibc people decided to "improve" on tcsetattr() this way.
> 
> Funnily enough, I do *not* find this in the glibc sources for
> tcsetattr (sysdeps/unix/sysv/linux/tcsetattr.c):
> 
>   https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/tcsetattr.c
> 
> so I wonder if this is some Fedora "feature".

Hmm, that would be even more sad.
What do you recommend as workaround? I don't see anything wrong with
what the kernel does and while I don't know why glibc would be so
'helpful', I don't have enough data to argue one way or another.

Should libdivecomputer ignore the error when on a PTY?

/D