Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture
Michael Biebl wrote: > I've contemplated dropping the Multi-Arch: foreign notation in systemd and > maybe also for policykit-1. > > Is there a valid use case where we need/want a foreign systemd/policykit-1? Wouldn't that go in the wrong direction? I'd think that we want the native systemd or policykit daemon to satisfy a foreign dependency, and that's what `Multi-Arch: foreign` allows. In fact https://wiki.ubuntu.com/MultiarchSpec#line-1-3 suggests that the scenario I ended up in *should* not have happened; the installer should've preferred the native (amd64 for me) version of the package. So that's an argument in favor of leaving things as they are. Bertram
Bug#1052690: grub2: post-install script overrides manual changes to GRUB_DISABLE_OS_PROBER
Sorry, I never tested whether the setting actually persists; I just
hoped that it would. But indeed it is not; I had to manually intervene
once again.
Jordi's analysis and patch look plausible to me. It might be slightly
better to compare "${GRUB_DISABLE_OS_PROBER}" to "true" instead of
"false" (swapping the branches of the conditional), since that's what
/etc/grub.d/30_os-prober does.
Thanks,
Bertram
Bug#1052690: grub2: post-install script overrides manual changes to GRUB_DISABLE_OS_PROBER
Agustin Martin wrote: > I have my 'local-settings.cfg' in that dir and works as expected. > > Does using '/etc/default/grub.d/99-osprober.cfg' work? That does work. As far as I can make out, the directory ships empty (though other packages may add stuff there), so it's hard to find out about that required extension. Not sure where that information belongs... ideas: - /etc/default/grub.d/README - /etc/default/grub - the `grub` texinfo document? That documents /etc/default/grub but not the /etc/default/grub.d override. But I haven't checked whether that's a grub feature or something added by Debian. Cheers, Bertram
Bug#1052690: grub2: post-install script overrides manual changes to GRUB_DISABLE_OS_PROBER
Package: grub2 Version: 2.12~rc1-10 Dear Maintainer, * What led up to the situation? An update of grub a while ago changed the default os-prober behavior; see also #1038974. * What exactly did you do (or not do) that was effective (or ineffective)? I edited /etc/default/grub to reenable os-prober. * What was the outcome of this action? While at first effective, subsequent updates of grub reset the default each time. (It took me a while to realize this.) * What outcome did you expect instead? I expected the setting to stick when grub is updated. Additional information: It turns out that the post-install script patches /etc/default/grub here: https://git.launchpad.net/ubuntu/+source/grub2/tree/debian/postinst.in?h=debian/sid=f85ded33219dc350d3ef96caa9d1ce118247b086#n398 It's also worth noting that `update-grub` does not appear to pick up files from `/etc/default/grub.d` so putting the setting there is ineffective. (I put the setting into `/etc/default/grub.d/99-osprober` and update-grub didn't pick it up in my test.) The proper solution for now appears to be to run `dpkg-reconfigure grub-efi-amd64` (Would other grub packages work too? This is the package that owns the corresponding debconf setting `grub2/enable_os_prober` for me) Ideally, I'd prefer the manual edits to be recognized and kept. But at the very least, please add a comment in /etc/default/grub to point towards a reliable way of changing this setting. And maybe add a hint to the warning messages that update-grub prints about os-prober?
Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture
Luca Boccassi wrote: [...] > I don't think this is something we should facilitate by default or > spend any energy on. > > You can correct me if I'm wrong, but I don't see any good reason why > anybody would need to run a polkitd:i386 on an otherwise amd64 system. > It's not what happens by default if you have i386 enabled and you type > 'apt install polkitd' or so. I agree that there isn't a good reason, and I'm not sure how I ended up in that situation in the first place (the log files don't go back far enough). One thing I do know is that polkitd:i386 was marked as automatically installed, so I almost certainly did not make that decision deliberately. My speculation is that this happened while satisfying dependencies for a third party i386 application. That meant installing required 32 bit libraries, and one of them must have come with a polkitd dependency, and the i386 version was selected because I was installing an i386 package. Anyway, I reported this because I assumed that pinning packages to the native architecture was easy, so it would be justified even for this (hopefully!) rare scenario... apparently that's not the case. Cheers, Bertram
Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture
Package: polkitd Version: 123-1 Severity: normal File: /usr/lib/polkit-1/polkitd Dear Maintainer, for reasons lost in time I had polkitd:i386 installed on an x86_64 host. After the update to 123-1, polkitd stopped working with errors like [ 2080.436059] audit: type=1326 audit(1691077090.861:74): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=unconfined pid=4252 comm="polkitd" exe="/usr/lib/polkit-1/polkitd" sig=31 arch=4003 syscall=45 compat=1 ip=0xf7f51887 code=0x0 This is due to the addition of system call filtering in the polkit systemd unit: SystemCallArchitectures=native # (which is not i386) SystemCallFilter=@system-service The solution is to install polkitd in its native version. Can this be fixed by strengthening dependencies? (Say, tie the architecture to that of systemd...) Cheers, Bertram -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages polkitd depends on: ii adduser 3.137 ii dbus [default-dbus-system-bus] 1.14.8-1 ii libc6 2.36-9 ii libduktape207 2.7.0-2 ii libexpat1 2.5.0-2 ii libglib2.0-02.76.4-4 ii libpam-systemd [logind] 254-1 ii libpam0g1.5.2-6 ii libpolkit-agent-1-0 123-1 ii libpolkit-gobject-1-0 123-1 ii libsystemd0 254-1 ii systemd [systemd-sysusers] 254-1 ii xml-core0.18+nmu1 polkitd recommends no packages. Versions of packages polkitd suggests: pn polkitd-pkla Versions of packages polkitd is related to: pn elogind pn libpam-elogind ii libpam-systemd 254-1 ii systemd 254-1 -- no debconf information
Bug#1005023: thunderbird subprocess (glxtest) dumps core on startup (with apparmor)
This appears to be fixed in thunderbird 1:102.6.0-1 which
includes the following in /etc/apparmor.d/usr.bin.thunderbird:
# Imported from the opencl abstraction, which we cannot include
# due to conflicting "x"
@{sys}/devices/pci[0-9]*/**/{class,config,resource,revision} r,
I have not checked which version first contained these lines.
I'm not closing this bug report yet because bullseye is still affected.
Bug#1005023: thunderbird subprocess (glxtest) dumps core on startup (with apparmor)
Package: thunderbird
Version: 1:91.5.1-1+b2
Severity: normal
Dear Maintainer,
on startup, thunderbird generates a core dump when apparmor is enabled. Apart
from that, the program works fine.
*** To reproduce:
> thunderbird
[GFX1-]: No GPUs detected via PCI
[GFX1-]: glxtest: process failed (received signal 11)
[...]
> file core
core: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from
'/usr/lib/thunderbird/thunderbird', real uid: 1000, effective uid: 1000, real
gid: 1000, effective gid: 1000, execfn: '/usr/lib/thunderbird/thunderbird',
platform: 'x86_64'
[Note: in most installations the core dumps will be managed by
`systemd-coredump`, and probably need to be accessed with `coredumpctl`]
*** Local fix:
# echo '/sys/devices/pci[0-9]*/**/class r,' >>
/etc/apparmor.d/local/usr.bin.thunderbird
# systemctl restart apparmor.service
This augments the existing rules for /sys/devices/pci in
/etc/apparmor.d/usr.bin.thunderbird,
/sys/devices/pci[0-9]*/**/{device,subsystem_device,subsystem_vendor,uevent,vendor}
r,
to include the `class` file as well.
*** Supporting analysis:
I installed the -dbgsym packages for thunderbird and libpci to obtain a
backtrace:
> gdb /usr/lib/thunderbird/thunderbird core
[...]
(gdb) bt
#0 UnexpectedExit() () at ./toolkit/xre/nsAppRunner.cpp:399
#1 0x7fa0be447f67 in __run_exit_handlers (status=status@entry=1,
listp=0x7fa0be5c5738 <__exit_funcs>,
run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at
exit.c:108
#2 0x7fa0be44810a in __GI_exit (status=status@entry=1) at exit.c:139
#3 0x7fa0b30998e1 in pci_generic_error (msg=0x7fa0b30a1415 "Cannot open
%s: %s") at init.c:131
#4 0x7fa0b309ece2 in sysfs_get_string (d=d@entry=0x7fa0be2d2120,
object=object@entry=0x7fa0b30a1bd2 "class", buf=buf@entry=0x7ffccff099a0
"0x6fb5\n", mandatory=mandatory@entry=1) at sysfs.c:103
#5 0x7fa0b309f508 in sysfs_get_value (mandatory=1, object=0x7fa0b30a1bd2
"class", d=0x7fa0be2d2120) at sysfs.c:145
#6 sysfs_fill_info (d=0x7fa0be2d2120, flags=33) at sysfs.c:311
#7 0x7fa0b309a27f in pci_fill_info_v35 (d=d@entry=0x7fa0be2d2120,
flags=flags@entry=33) at access.c:201
#8 0x7fa0b7a477f6 in get_pci_status() () at ./toolkit/xre/glxtest.cpp:391
#9 childgltest() () at ./toolkit/xre/glxtest.cpp:1354
#10 0x7fa0b7a48136 in fire_glxtest_process() () at
./toolkit/xre/glxtest.cpp:1403
#11 0x7fa0b7a3d90b in XREMain::XRE_mainInit(bool*) (this=,
this@entry=0x7ffccff0a920, aExitFlag=aExitFlag@entry=0x7ffccff0a8af) at
./toolkit/xre/nsAppRunner.cpp:3623
#12 0x7fa0b7a44588 in XREMain::XRE_main(int, char**,
mozilla::BootstrapConfig const&) (this=this@entry=0x7ffccff0a920,
argc=argc@entry=1, argv=argv@entry=0x7ffccff0bb98, aConfig=...) at
./toolkit/xre/nsAppRunner.cpp:5408
#13 0x7fa0b7a44970 in XRE_main(int, char**, mozilla::BootstrapConfig
const&) (argc=1, argv=0x7fa0b7a3e5c0 , aConfig=...) at
./toolkit/xre/nsAppRunner.cpp:5493
#14 0x559272bf7198 in do_main(int, char**, char**) (argc=1,
argv=0x7ffccff0bb98, envp=) at ./comm/mail/app/nsMailApp.cpp:229
#15 main(int, char**, char**) (argc=, argv=,
envp=) at ./comm/mail/app/nsMailApp.cpp:368
(gdb) frame 4
(gdb) print mandatory
$1 = 1
(gdb) print (char *)namebuf
$2 = 0x7ffccff09100 "/sys/bus/pci/devices/:ff:15.1/class"
(gdb) q
So we're hitting this code in libpci,
https://github.com/pciutils/pciutils/blob/v3.7.0/lib/sysfs.c#L103
and because `mandatory` is set this is treated as an error by libpci.
dmesg points to apparmour as the cause:
# dmesg
[...]
[21096.091105] audit: type=1400 audit(1644074114.165:64): apparmor="DENIED"
operation="open" profile="thunderbird"
name="/sys/devices/pci:ff/:ff:15.1/class" pid=118142 comm="thunderbird"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[21096.091119] thunderbird[118142]: segfault at 0 ip 7fa0b7a3e5e7 sp
7ffccff08fa0 error 6 in libxul.so[7fa0b47d5000+4e9b000]
[...]
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.15.0-3-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages thunderbird depends on:
ii debianutils 5.7-0.1
ii fontconfig 2.13.1-4.4
ii libatk1.0-0 2.36.0-3
ii libbotan-2-192.19.1+dfsg-2
ii libbz2-1.0 1.0.8-5
ii libc62.33-5
ii libcairo-gobject21.16.0-5
ii libcairo21.16.0-5
ii libdbus-1-3 1.12.20-3
ii libdbus-glib-1-2 0.112-2
ii libevent-2.1-7 2.1.12-stable-1
ii libffi8 3.4.2-4
ii libfontconfig1 2.13.1-4.4
ii libfreetype6 2.11.1+dfsg-1
ii libgcc-s1
Bug#904465: Upgrading xserver-xorg-core breaks OpenGL?
I have encountered the same problem.
Note that the file .../extensions/libglx.so has been there for quite
some time. What changed is that the OS name ("linux") is no longer used
for populating the subdirectories that are used to refine the module
path:
https://cgit.freedesktop.org/xorg/xserver/commit/hw/xfree86/loader/loadmod.c?id=97bd6e453676516891250389ec0fd695c110087c
A possible solution is to create the libglx.so symlink directly inside
/usr/lib/xorg/modules/ rather than in /usr/lib/xorg/modules/linux/.
Alternatively, you can divert the existing .../extensions/libglx.so
file. I'm not sure what the best solution is.
Best regards,
Bertram Felgenhauer
Bug#718873: pppd wrongfully rejects IPCP acknowledgements containing ms-wins fields
Package: ppp
Version: 2.4.5-5.2
I'm seeing IPCP negotiations going like this (and eventually failing)
when connecting to my ISP:
Jul 11 20:03:25 * pppd[4833]: sent [IPCP ConfReq id=0x2 addr 0.0.0.0 ms-dns1
0.0.0.0 ms-dns2 0.0.0.0]
Jul 11 20:03:26 * pppd[4833]: sent [IPCP ConfReq id=0x2 addr 0.0.0.0 ms-dns1
0.0.0.0 ms-dns2 0.0.0.0]
Jul 11 20:03:26 * pppd[4833]: rcvd [IPCP ConfNak id=0x2 addr 10.167.246.198
ms-dns1 213.162.69.1 ms-dns2 213.162.69.169 ms-wins 124.6.168.55 ms-wins
17.17.17.17]
Jul 11 20:03:26 * pppd[4833]: sent [IPCP ConfReq id=0x3 addr 10.167.246.198
ms-dns1 213.162.69.1 ms-dns2 213.162.69.169 ms-wins 124.6.168.55 ms-wins
17.17.17.17]
Jul 11 20:03:26 * pppd[4833]: rcvd [IPCP ConfAck id=0x3 addr 10.167.246.198
ms-dns1 213.162.69.1 ms-dns2 213.162.69.169 ms-wins 124.6.168.55 ms-wins
17.17.17.17]
Jul 11 20:03:27 * pppd[4833]: sent [IPCP ConfReq id=0x3 addr 10.167.246.198
ms-dns1 213.162.69.1 ms-dns2 213.162.69.169 ms-wins 124.6.168.55 ms-wins
17.17.17.17]
...
with the last two lines repeating until the IPCP error limit is
reached. As you can see, the peer added two extra fields in the
ConfNak reply. This is allowed, and indeed the following ConfReq
packet sent reflects this. However, when the ConfAck packet
is received, pppd discards it as invalid, because of the ms-wins
fields. But the acknowledgement is valid---the fields match the
sent request exactly---so it should be recognized.
I have a patch fixing this problem, which I'll attach to this report.
(One subtlety that I'd like to point out is that the order of checks in
ipcp_ackci should match the order in ipcp_addci; the ppp protocol
specifies that acknowledgements are not allowed to change that order.)
This is probably hard to reproduce, because it is ISP specific;
the ISP is Telering Austria. I'm using wvdial to connect, which
in turn runs pppd. The only change to the ppp configuration I made
was to enable the debug option.
$ wvdial
wvdial.conf:
[Dialer Defaults]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 C1 D2 +FCLASS=0
Init3 = AT+CGDCONT=1,IP,WEB,0.0.0.0,0,0
Dial Attempts = 1
Password = web
Phone = *99***1#
Modem Type = USB Modem
Stupid Mode = 1
Baud = 2160
#460800
New PPPD = yes
Modem = /dev/ttyACM0
ISDN = 0
Username = w...@telering.at
Auto Reconnect = off
%Init3 = AT%NWCONF
Cheers,
Bertram
P.S. I tried to contact Paul Mackerras about this 3 weeks ago but didn't
receive a reply.
diff --git a/pppd/ipcp.c b/pppd/ipcp.c
index 12bcc61..e9738fe 100644
--- a/pppd/ipcp.c
+++ b/pppd/ipcp.c
@@ -962,6 +962,21 @@ ipcp_ackci(f, p, len)
goto bad; \
}
+#define ACKCIWINS(opt, addr) \
+if (addr) { \
+ u_int32_t l; \
+ if ((len -= CILEN_ADDR) 0) \
+ goto bad; \
+ GETCHAR(citype, p); \
+ GETCHAR(cilen, p); \
+ if (cilen != CILEN_ADDR || citype != opt) \
+ goto bad; \
+ GETLONG(l, p); \
+ cilong = htonl(l); \
+ if (addr != cilong) \
+ goto bad; \
+}
+
ACKCIADDRS(CI_ADDRS, !go-neg_addr go-old_addrs, go-ouraddr,
go-hisaddr);
@@ -974,6 +989,10 @@ ipcp_ackci(f, p, len)
ACKCIDNS(CI_MS_DNS2, go-req_dns2, go-dnsaddr[1]);
+ACKCIWINS(CI_MS_WINS1, go-winsaddr[0]);
+
+ACKCIWINS(CI_MS_WINS2, go-winsaddr[1]);
+
/*
* If there are any remaining CIs, then this packet is bad.
*/
Bug#628043: Broken glyphs im proofgeneral emacs mode.
Package: emacs23 Version: 23.3+1-1 Proof General (which is an emacs based frontend for automatic theorem provers) can display parts of formulas using unicode characters. In recent versions of emacs, these get truncated (i.e. the corresponding character cells are too narrow to contain the character.) This problem has been reported and fixed upstream, http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8703 Since it's unclear when the next emacs release will be (at least I could not find any information about that), and since this is an actual usability propblem with a fairly simple fix, it would be great if the Debian package would incorporate that patch. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551838: debootstrap --unpack-tarball downloads Packages file.
Package: debootstrap Version: 1.0.27 When running debootstrap --unpack-tarball using a tarball created with the --make-tarball, the Packages file is downloaded again, despite being included in the tarball. This is bad for two reasons: 1) there may be no network connection in that second run of debootstrap 2) the new Packages file may be inconsistent with the packages downloaded earlier, pretty much defeating the purpose of creating the tarball in the first place. The behaviour is strongly related to #551838. In fact this is a feature (the Packages file is downloaded using the 'nocache' option in /usr/share/debootstrap/functions). For the original reporter, this was surprising and annoying, and I tend to agree with him. But even if the feature is there to stay, I think that this behaviour should be disabled by --make-tarball. Best regards, Bertram Felgenhauer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#358164: libedit2: adding \n incrementally with read/write history
Hi,
this is caused by a misuse of the second argument to the getline()
glibc function in fgetln(). The number stored there is not the number
of bytes read (plus 1), but the actually allocated size for the buffer,
which may be larger. To find the number of characters read, the
return value of getline has to be used instead.
Proposed implementation:
(glibc-bsd-glue/bsdcompat/fgetln.c)
#include bsdcompat.h
#include stdlib.h
char *
fgetln (FILE *stream, size_t *len)
{
char *line=NULL;
ssize_t slen;
*len = slen = getline (line, len, stream);
if (slen 0)
return NULL;
return line;
}
(end of file)
Btw, the function leaks memory, but it's no worse than before.
regards,
Bertram
P.S. on the memory leak.
BSD's fgetln() returns a buffer that is invalidated upon the next file
I/O operation on the handle. (In fact it appears to return a pointer
into libc's read buffer for the stream)
So while reusing a single buffer as follows is tempting,
char *
fgetln (FILE *stream, size_t *len)
{
static char *line = NULL;
static size_t line_size = 0;
ssize_t slen;
*len = slen = getline (line, line_size, stream);
if (slen 0)
return NULL;
return line;
}
I'm not convinced that it's safe; in fact I suspect that registering
a command using rl_add_defun() which (recursively) sources another
config file will break this.
It's probably easier to fix the calling sites to use getline instead.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382550: xsok can overwrite last level's savefiles
Package: xsok
Version: 1.02-16
The find next unsolved level command (shift-U) in xsok can cause the last
level's savefiles to be overwritten if no unsolved level is found.
To reproduce:
- solve last level
- go to second last level
- press shift-U, then s (for 'save') - this creates a savefile with the
wrong level number. The same effect occurs if you now solve this level
and beat the current record.
Proposed fix:
* do not use global variable game.level as a counter
--- a/src/commands.c
+++ b/src/commands.c
@@ -54,9 +54,10 @@ void cmd_LevelInfo(void) {
}
void cmd_NextUnsolved(void) {
-while (game.level maxlevel) {
- if (!highscore[++game.level]) {
- NewLevel(game.level);
+int level = game.level;
+while (level maxlevel) {
+ if (!highscore[++level]) {
+ NewLevel(level);
cmd_LevelInfo();
return;
}
With kind regards,
Bertram Felgenhauer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305593: telnet messes up control characters if used on a non-TTY
This bug still exists; the link I provided for the patch no longer works
though, and neither does the original e-mail address. So here's the patch
again, inline this time.
--- netkit-telnet-0.17/telnet/terminal.cc 2006-04-08 23:01:19.701512988
+0200
+++ netkit-telnet-0.17.my/telnet/terminal.cc2006-04-08 23:14:09.636796319
+0200
@@ -664,9 +664,10 @@
nttyb = ottyb;
#else /* USE_TERMIO */
-tcgetattr(0, old_tc);
-
-new_tc = old_tc;
+if (!tcgetattr(0, old_tc))
+new_tc = old_tc;
+else
+old_tc = new_tc;
#ifndefVDISCARD
termFlushChar = CONTROL('O');
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305593: telnet messes up control characters if used on a non-TTY
Package: telnet Version: 0.17-28 When telnet is invoked with non-TTY stdin, it can mess up the control characters. example: $ echo lll | telnet localhost 8000 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host. receiving end: $ nc -l -p 8000 | od -t x1 000 ff f4 ff fd 06 005 (as you can see, it interprets 'l' as 'interrupt process' here) I've tracked down the bug to TerminalSaveState() in terminal.cc, where tcgetattr() is called without checking if fd 0 is a terminal, and without checking the result value; as it turns out, the call modifies the passed struct (I guess the C library creates its own temporary buffer and then copies the values from there), and returns -1 to signal an error. http://www.inf.tu-dresden.de/~bf3/misc/netkit-telnet-0.17-tcgetattr.diff is a patch that works for me - but I'm not sure that's entirely correct and it's most likely incomplete. I'm using kernel 2.6.11.7 and glibc 2.3.4. I'm using Gentoo Linux, but Gentoo uses the telnet package of Debian without significant modifications at this time (it only adds a -D_GNU_SOURCE to CFLAGS and CXXFLAGS) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
