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:

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, 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

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:

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 \

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/

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,

Hello, This is a patch to allow building of the project using MSYS, MinGW, and MinGW-w64 with the following invocation: make -f Makefile.lite libFLAC libFLAC++ flac metaflac test_libs_common test_libFLAC test_libFLAC++ test_grabbag test_seeking test_streams utils examples This patch addresses eight points: 1. `uname -p` in MSYS returns "unknown" so we must use `gcc -dumpmachine`

Hello, This is a patch to allow building of the project using MSYS, MinGW, and MinGW-w64 with the following invocation: make -f Makefile.lite libFLAC libFLAC++ flac metaflac test_libs_common test_libFLAC test_libFLAC++ test_grabbag test_seeking test_streams utils examples This patch addresses eight points: 1. `uname -p` in MSYS returns "unknown" so we must use `gcc -dumpmachine`

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

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

Hello folks, I fried of mine offered us a few metric tons of server hardware that we can use for our CI and testing. He also offered to host and operate it. The only problem is power costs. At his location (Serbia) power costs seem to be relatively low compared to average western countries, but for such a farm still too much for a single hobbyist. So the vital question now is: can we find any

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tried to do this, gcc complained a lot about undefined references. After a bit of mucking with the code, i came up with a few patches. This might be a good conversation starter. The build that i've got out of this does pass the testsuite. To enable LTO you just need to apply these (for non-W32 builds you probably only need one of the patches)