similar to: Wine doesnt show close to all my files/apps...?

Hi all, I'm experiencing a problem when NTBACKING'UP my W2000 Server files against a Linux 2.4.9 + ReiserFS 3.6 file system + Samba share. It works OK for the first 4 Gb's around file size. Then ntbackup stops serving data and the file on the samba side appears to be downsized to 0 and growing ssssslowly. Once you stop ntbackup by killing the process, the file reappears at its real

I'll release v1.0.1 in a day or two, but it would be nice to get some testing before the release to see if I managed to break something after the Mercurial conversion. And did I forget something that should be fixed for v1.0.1? http://dovecot.org/tmp/dovecot-1.0.1rc2.tar.gz Changes since v1.0.0: * deliver: If Return-Path doesn't contain user and domain, don't try to bounce the

Hi All I just upgraded to v1.0.1 so that I could try out the new SMS feature. When I did this, I noticed that my outbound SIP call to Broadvoice was very choppy, so I hung up. The system would not release the call, so I restarted the server. When it came up, it started loading * then said threw up a segmentation fault in res_crypto.so. It kept respawning until it ran out of RAM. I restarted

Currently the typical rejection message is: --------- Your message was automatically rejected by Dovecot Mail Delivery Agent. The following reason was given: Quota exceeded. --------- Then there is MDN + message headers in other MIME parts. But of course there sucky clients that can't display MDNs and users get confused. Any suggestions how to improve this message? I'm not sure if the

for many versions of ruby, and as many versions of rails, ive been unable to generate docs without deleting this file: lib/rails_generator/generators/components/controller/templates/controller.rb ruby just chews more and more memory until swap fils up and the system has to be reset.. m gems # rdoc --version RDoc V1.0.1 - 20041108 ruby --version ruby 1.8.5 (2006-06-22) [x86_64-linux]

Greetings list, I'm haveing problem with FreeRADIUS v1.0.1-3 which came with CentOS 4.1 FreeRADIUS refuses to use system accounts for authentication. The latest freeradius-1.0.4 is working correctly. Can we have this update or have to wail till RH release new rpm src? Thanks, -j

This school year is pretty much finished next thursday (for the classes I intended to pass). After that I should again have enough energy to read and answer the 150 mails in this list .. :) And maybe release v1.0.1 fixing the newly found bugs. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc:

http://dovecot.org/tmp/dovecot-1.0.2-rc.tar.gz Unless someone finds something broken, I'll release v1.0.2 in a few days. The most important changes since v1.0.1: * dbox isn't built anymore by default. It will be redesigned so it shouldn't be used. + Maildir: Support reading dovecot-uidlist (v3) files created by Dovecot v1.1. - Maildir: "UIDVALIDITY changed" errors

I haven't been able to find anything directly addressing this problem. I'm running eeebuntu Hardy on a eee PC 900 and trying to install a program (CDC's EpiInfo), but I get an error message saying, "Could not create temporary file, not enough free temporary disk space. Please free up disk space and rerun this installation." I'm assuming that the temporary file is trying

http://dovecot.org/releases/dovecot-1.0.0.tar.gz http://dovecot.org/releases/dovecot-1.0.0.tar.gz.sig It took almost 5 years, but it's finally ready. I'm not expecting to release v1.0.1 anytime soon, unless someone's been sitting on a major bug just waiting for v1.0 to be released. :) People wanting new features should start testing the upcoming v1.1. http://dovecot.org/nightly/

http://dovecot.org/releases/dovecot-1.0.0.tar.gz http://dovecot.org/releases/dovecot-1.0.0.tar.gz.sig It took almost 5 years, but it's finally ready. I'm not expecting to release v1.0.1 anytime soon, unless someone's been sitting on a major bug just waiting for v1.0 to be released. :) People wanting new features should start testing the upcoming v1.1. http://dovecot.org/nightly/

I''ve noticed that the copy of Mongrel installed by the camping-omnibus gem doesn''t work with Ruby 1.8.6. Or to be more specific, cgi_multipart_eof_fix (which Mongrel is dependent upon) doesn''t work: > $ sudo gem install mongrel --source http://code.whytheluckystiff.net > > ERROR: Error installing mongrel: > cgi_multipart_eof_fix requires Ruby version

On Aug 10, 2018, at 1:28 PM, Marshall Clow via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > * The clock stuff being added in C++20 has already been discussed here. I’ve missed the discussions on file_time_type, however I thought I should throw in my opinion here before it is too late to do anything about it. I believe it is a mistake to model file_time_type with 128 bits. It

VS2013 support is dropped in about 1 week from now :) On Thu, Oct 6, 2016 at 11:37 PM Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > Visual Studio up to and including VS2013 implements > std::chrono::high_resolution_clock in an absolutely unusable manner (it is > a very low resolution clock…) [1]. Also, division is implemented

http://dovecot.org/tmp/dovecot-1.0.1rc3.tar.gz Looks like I managed to do a lot of changes today. So I'll wait a few more days before v1.0.1 release. The important changes since rc2: + deliver: Added -e parameter to write rejection error to stderr and exit with EX_NOPERM instead of sending the rejection by executing sendmail. + dovecot --log-error logs now a warning, an error and a

Hi all, We're considering using std::chrono more heavily in lldb. However, A quick search of the llvm, clang, and lld codebases shos almost zero usage of chrono. I wanted to see if this was for technical reasons (eg some compiler doesn't support it well) or simply because nobody has needed it yet. If it's the former then I'd like to be aware of the issues so we don't fall into

Sorry ... I missed mentioning the details - this is the error I get - root at no1slu398:~/Documents/LLVM/tmp# clang++ -std=c++0x hello.cpp In file included from hello.cpp:1: In file included from /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/thread:38: /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/chrono:535:6: error: no matching constructor for initialization of

OpenSSL v1.0.1 is enough. Aki > On November 1, 2016 at 7:46 PM Ruga <ruga at protonmail.com> wrote: > > > Hello, > > We cannot upgrade from 2.2.24, because we use libressl and the newer > dovecot versions demand openssl v1.1. > > Please add the new library requirement to the INSTALL file. > > All the best. > > > > > > > >

Hi All, I recently committed <filesystem> to trunk. I wanted to bring attention to some quirks it currently has. First, it's been put in a separate library, libc++fs, for now. Users are responsible for linking the library when they use filesystem. Second, it should still not be considered ABI stable. Vendors should be aware of this before shipping it. Hopefully all the standard and

All, I'm in the process of upgrading an LLVM client from using 3.8 to using 4.0 and am running into the following issue: // compile with: // clang++ -std=c++11 -Wno-c++14-extensions -S -emit-llvm // ~/chrono.cpp -o chrono.ll #include <chrono> #include <ratio> #include <thread> using namespace std; using namespace std::chrono; using tick = ratio<1, 300>; using