Bug#218131: 3 glibc LSB RC bugs filed
On Mon, 2003-11-03 at 11:49, Daniel Jacobowitz wrote: > Red Hat already has a local patch for this, by the way. I can not tell > offhand if they are equivalent - they're structured very differently. > I recommend you grab the Rawhide glibc SRPM from a Red Hat mirror, and > take a look at glibc-redhat.patch. There may be value in the Red Hat patch (in particular, the check for TCSETS). In the main, however, the patch is still incorrect. POSIX tcsetattr needs to handle three conditions correctly: - If all changes are successful, return success (0). - If some changes are successful and some aren't, return success. - If no changes are successful, return error (-1, errno=EINVAL). The problem occurs when setting certain flags (PARENB, CREAD, or one of the CSIZE parameters) on a pty. The kernel silently ignores those settings, so libc is responsible for doing the right thing. Ancient glibc, pristine upstream glibc from February on, and Debian sarge/sid glibc fail the third condition in this case. 2.2 versions of glibc, woody glibc, 2.3 glibc up to February, and RawHide glibc fail the second condition. My patch, so far as I can tell, covers all three conditions. Note that as far as the LSB is concerned, failing the second condition does not result in test failures, but it has been known to create problems with applications. Application problems were what prompted Ulrich Drepper to drop the patch. The problems with setlocale seem utterly unrelated. Given the lack of feedback on that issue, I think I'm going to rebuild my sarge test box and try to reproduce the exact conditions which trigger it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#218131: 3 glibc LSB RC bugs filed
On Mon, Nov 03, 2003 at 11:22:19AM -0500, Jeff Licquia wrote: > On Fri, 2003-10-31 at 11:16, Jeff Licquia wrote: > > The trick now is to get the patch to produce correct POSIX behavior. > > Essentially, we need to figure out if any setting change was successful, > > and return success if it was. > > I've added some code that does this, and have confirmed that the patch > does resolve the tcgetattr and c_iflag problems. Unfortunately, I seem > to have broken something else; locale handling seems totally broken on > my test machine, even when I downgrade to sarge's libc. > > My patch is here: > > > http://hackers.progeny.com/~licquia/lsb/patches/sarge/glibc_2.3.2-9/tcsetattr.dpatch > > The broken report and journal are here: > > http://hackers.progeny.com/~licquia/lsb/journal-sarge.200311022311 > http://hackers.progeny.com/~licquia/lsb/tjreport-sarge.200311022311.txt > > Review, insight into the setlocale problem, or other comments would be > appreciated. Red Hat already has a local patch for this, by the way. I can not tell offhand if they are equivalent - they're structured very differently. I recommend you grab the Rawhide glibc SRPM from a Red Hat mirror, and take a look at glibc-redhat.patch. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#218131: 3 glibc LSB RC bugs filed
On Fri, 2003-10-31 at 11:16, Jeff Licquia wrote: > The trick now is to get the patch to produce correct POSIX behavior. > Essentially, we need to figure out if any setting change was successful, > and return success if it was. I've added some code that does this, and have confirmed that the patch does resolve the tcgetattr and c_iflag problems. Unfortunately, I seem to have broken something else; locale handling seems totally broken on my test machine, even when I downgrade to sarge's libc. My patch is here: http://hackers.progeny.com/~licquia/lsb/patches/sarge/glibc_2.3.2-9/tcsetattr.dpatch The broken report and journal are here: http://hackers.progeny.com/~licquia/lsb/journal-sarge.200311022311 http://hackers.progeny.com/~licquia/lsb/tjreport-sarge.200311022311.txt Review, insight into the setlocale problem, or other comments would be appreciated. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#218131: 3 glibc LSB RC bugs filed
On Wed, 2003-10-29 at 14:31, Jeff Licquia wrote: > On Wed, 2003-10-29 at 04:13, Matt Taggart wrote: > > #218131 > > ia64/i386: /tset/POSIX.os/devclass/tcgetattr/T.tcgetattr 1 FAIL > > ia64/i386: /tset/POSIX.os/devclass/tcgetattr/T.tcgetattr 2 FAIL > > In reference to that bug, the following mailing list messages might be > useful: > > http://sources.redhat.com/ml/libc-alpha/2003-02/msg00117.html > http://sources.redhat.com/ml/libc-hacker/1998-12/msg00076.html More information. I have been able to confirm that reapplying the H. J. Lu patch resolves the tcgetattr LSB test failures. It also seems to resolve the c_iflag failures. The trick now is to get the patch to produce correct POSIX behavior. Essentially, we need to figure out if any setting change was successful, and return success if it was. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#218131: 3 glibc LSB RC bugs filed
On Wed, 2003-10-29 at 04:13, Matt Taggart wrote: > #218131 > ia64/i386: /tset/POSIX.os/devclass/tcgetattr/T.tcgetattr 1 FAIL > ia64/i386: /tset/POSIX.os/devclass/tcgetattr/T.tcgetattr 2 FAIL In reference to that bug, the following mailing list messages might be useful: http://sources.redhat.com/ml/libc-alpha/2003-02/msg00117.html http://sources.redhat.com/ml/libc-hacker/1998-12/msg00076.html Upon closer analysis, it would seem that the current behavior is slightly more correct than the behavior in woody, but still not 100% correct. Roland McGrath, in a followup to the former message, is partially right. The patch introduced in the latter message is incorrect when it reports any kernel jiggering of c_cflag to be incorrect. However, removing the patch entirely is also incorrect. In glibc as delivered, setting PARENB alone on a pty will return success, which is also incorrect according to Roland. (I haven't looked at what POSIX really says yet.) So it would seem that we need to restore the old patch, but modify it to only trigger if no valid settings are changed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
