search for: brinckerhoff

...g: userdb lookup > skipped, username taken from USER environment > Nov 3 12:23:05 desmond dovecot: lda(granitemon): Debug: none: root=, > index=, indexpvt=, control=, inbox=, alt= > Nov 3 12:23:05 desmond dovecot: lda(granitemon): Debug: Destination > address: granitemon at desmond.brinckerhoff.org (source: user at hostname) > Nov 3 12:23:05 desmond dovecot: lda(granitemon): Error: > setegid(privileged) failed: Operation not permitted > Nov 3 12:23:05 desmond dovecot: lda(granitemon): msgid=< > 20151103202305.88BE05FF39 at desmond.brinckerhoff.org>: save failed to >...

and, are you SURE that dovecot-lda has mail in it's group list when it is executing? On Tue, Nov 3, 2015 at 2:12 PM, Larry Rosenman <larryrtx at gmail.com> wrote: > Hrm. if you turn up the debug on lda, do you get any more of a clue? > > Those permissions look fine to me. > > > On Tue, Nov 3, 2015 at 2:10 PM, John Clements <johnbclements at gmail.com> >

...ot: lda(granitemon): Debug: userdb lookup skipped, username taken from USER environment Nov 3 12:23:05 desmond dovecot: lda(granitemon): Debug: none: root=, index=, indexpvt=, control=, inbox=, alt= Nov 3 12:23:05 desmond dovecot: lda(granitemon): Debug: Destination address: granitemon at desmond.brinckerhoff.org (source: user at hostname) Nov 3 12:23:05 desmond dovecot: lda(granitemon): Error: setegid(privileged) failed: Operation not permitted Nov 3 12:23:05 desmond dovecot: lda(granitemon): msgid=< 20151103202305.88BE05FF39 at desmond.brinckerhoff.org>: save failed to INBOX: BUG: Unknown inte...

...first post, you are using -MAX_WBITS, which enables old (headerless? don't know what it's called) zlib format, that has no gzip header and no checksum. Maybe you should be using +MAX_WBITS (the default), which adds necessary header and checksum.? Ben Stabler Systems Analysis Group Parsons Brinckerhoff 503.478.2859 ___________________________ NOTICE: This communication and any attachments ("this message") may contain confidential information for the sole use of the intended recipient(s). Any unauthorized use, disclosure, viewing, copying, alteration, dissemination or distribution of...

Here's a piece of code that behaves in a way that appears insane to me; I'm hoping that someone can either explain to me why this is the right behavior, or label it a bug. target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32- i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64- f80:128:128" target triple = "i386-apple-darwin8" define i32

...t -n # 1.2.15: /etc/dovecot/dovecot.conf # OS: Linux 2.6.32-5-686 i686 Debian 6.0.2 log_timestamp: %Y-%m-%d %H:%M:%S login_dir: /var/run/dovecot/login login_executable: /usr/lib/dovecot/imap-login mail_privileged_group: mail mbox_write_locks: fcntl dotlock lda: postmaster_address: postmaster at brinckerhoff.org mail_plugins: sieve auth default: passdb: driver: pam userdb: driver: passwd ... this is the version associated with debian stable. Finally, since I had coredumps enabled, I'm in a position to provide 'bt full', but it looks like my binaries are stripped, so I'm...

On Jan 28, 2009, at 1:20 AM, Duncan Sands wrote: > Hi John, > >> I have what appears to be a bug in LLVM... I'm deeply hesitant to >> label it a bug, given my lack of experience with LLVM, but the >> behaviour of this fragment strongly suggests a bug. > > this is a frequently asked question. The LLVM code generators > currently do not support unwind. As far

It appears to me based on my experiments with llvm-as that literal floating-point constants may be specified in the 64-bit IEEE hexadecimal format, but not in the 32-bit format. For instance, this file: target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32- i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64- f80:128:128" target triple =

I have what appears to be a bug in LLVM... I'm deeply hesitant to label it a bug, given my lack of experience with LLVM, but the behaviour of this fragment strongly suggests a bug. In particular, compiling and running this fragment using a fresh SVN build yields this stderr: uccello:/tmp clements$ lli a.out.bc 0 lli 0x005e72b6 char const* std::find<char const*,