similar to: [PATCH] libstc++ import fix

Hi folks, I've noticed an problem with openssh on GNU/Linux: pressing ctrl+s locks up the ssh client. Only killing it helps. Is this problem already known ? cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email:

Hi folks, is there an solution for an detachable ssh (like an terminal server, but for text console) ? I imagine something like what screen(1) does, but integrated into ssh: + if an connection breaks down, the session (an all processes) remain running an can be re-attached. + all active sessions can be queried + the output of sessions can be logged and retrieved later + xterm window title

Hi folks, here're some quick+dirty fixes to allow sysroot'ed crosscompiling. probably not yet very clean, but seems to work. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: contact at metux.de

Hi folks, is there anywhere an opensource PXE bootdisk (i've only found some from M$ as binary image) or a howto for generating one w/ the syslinux package ? cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT services phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email:

Hi folks, JFYI: i've collected a few rules, package upstreams should follow to make distro-maintainer's life _much_ easier: http://www.metux.de/index.php/de/component/content/article/57.html cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt at metux.de

One feature that I haven't seen in OpenSSH (It may be there) is an automatic blacklisting of IP addresses when a certain number of login attempts are reached from that IP address. It seems like it is popular these days to try brute force access on password cracking and automatic blacklisting may limit these attempts. Best regards/Nils Hammar

Hi folks, here's a patch which cleans up the nasm call from Makefiles. Abusing libtool and then having to drop in some additional wrapper script to rewrite the commandline again is rather stupid. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/

Hi folks, this patch adds creation of pkg-config descriptors for libflac and libflac++ cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce

Hi folks, here's a patch which adds an local xmms.m4 file (took it from latest stable xmms), so an complete autoconf regeneration also works if xmms is not installed. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit

Hi, I've got another one... NFS error 101 with NFSROOT has been discussed a lot, and hpa gave an answer to it which appears right. It's ENETUNREACH, and I suspect my diskless box does not set its IP parameters right. PXElinux is set up as follows: label linvdr kernel kernel-linvdr append initrd=initrd-linvdr acpi=off root=/dev/nfs \

I have been successful with configuring TCP on a 2.4.23 kernel that was built with the "IP: kernel level autoconfiguration" turned on with the following append line: APPEND initrd=rootfs.gz root=/dev/ram0 rw ip=192.168.0.175::192.168.0.1:255.255.255.0 ^ ^ ^ | |

On 5/24/14, lvqcl <lvqcl.mail at gmail.com> wrote: > Ozkan Sezer <sezeroz at gmail.com> ?????(?) ? ????? ?????? Sat, 24 May 2014 > 10:16:15 +0400: > >> - changes the _MSC_VER condition to universally _WIN32: MSVC, as well >> as GCC supports this. > > MSYS/MinGW 4.8.3, 4.9.0 can't compile code from git after this patch: > > format.c:47:22: error:

xf86-input-elographics - Elographics input driver for the Xorg X server ----------------------------------------------------------------------- Alan Coopersmith (6): gitlab CI: ensure libtool is installed in build container configure: Use LT_INIT from libtool 2 instead of deprecated AC_PROG_LIBTOOL configure: clear up obsolete macro warnings from autoconf Move X.Org's

I am pleased to announce Xwayland 23.2.7 which contains bug fixes for the current stable 23.2 branch. Enrico Weigelt, metux IT consult (1): m4: drop autoconf leftovers Joshua Ashton (1): xwayland: Send ei_device_frame on device_scroll_discrete Michel D?nzer (4): xwayland: Call drmFreeDevice for dma-buf default feedback xwayland: Use drmDevicesEqual in

On CentOS 4.5 (x86_64); happening on several different machines with libstdc++ and libstdc++-devel v. 3.4.6-8 only one of the i386 or x86_64 versions of libstc++-devel is installed if I yum install libstdc++-devel it will install the x86_64 version and remove the i386 version, but not warn me. Similarly if the i386 version is installed it will install the x86_64 and remove the i386,

On Thu, Aug 29, 2013 at 07:40:46PM +0200, Duncan Sands wrote: > Hi Jack, > > On 29/08/13 18:35, Jack Howarth wrote: >> Duncan, >> Is there a long term plan for handling the conflicting c++ libraries in building >> dragonegg? In particular, as vendors switch their clang++ system compilers to default >> to -stdlib=libc++, the resulting builds of llvm against

Hi Jack, On 30/08/13 15:56, Jack Howarth wrote: > On Thu, Aug 29, 2013 at 07:40:46PM +0200, Duncan Sands wrote: >> Hi Jack, >> >> On 29/08/13 18:35, Jack Howarth wrote: >>> Duncan, >>> Is there a long term plan for handling the conflicting c++ libraries in building >>> dragonegg? In particular, as vendors switch their clang++ system compilers

Duncan, Is there a long term plan for handling the conflicting c++ libraries in building dragonegg? In particular, as vendors switch their clang++ system compilers to default to -stdlib=libc++, the resulting builds of llvm against those compilers will be using the libc++ ABI but the dragonegg plugin will still need to be built against the libstdc++ ABI. For now, the only work-around appears to

Hi Jack, On 29/08/13 18:35, Jack Howarth wrote: > Duncan, > Is there a long term plan for handling the conflicting c++ libraries in building > dragonegg? In particular, as vendors switch their clang++ system compilers to default > to -stdlib=libc++, the resulting builds of llvm against those compilers will be using > the libc++ ABI but the dragonegg plugin will still need to be

All C and C++ files must include config.h --- src/libFLAC++/metadata.cpp | 4 ++++ src/libFLAC++/stream_decoder.cpp | 4 ++++ src/libFLAC++/stream_encoder.cpp | 4 ++++ src/plugin_xmms/charset.c | 4 ++++ src/plugin_xmms/configure.c | 4 ++++ src/plugin_xmms/fileinfo.c | 4 ++++ src/plugin_xmms/http.c | 4 ++++