search for: _known_

....mail-archive.com/dovecot at dovecot.org/msg43366.html "So, Solr in Dovecot works perfectly. > But the same search in thunderbird return "No matches found" :( Thunderbird problem, nothing you can do about it from Dovecot's side." at the very least, there are/were _known_ issues with TBird's search-on-server bits. now, whether that issue is still relevant here, I dunno yet; haven't finished digging through the ~ decade of Mozilla bug reports, finger pointing, and lack-of-resource complaints. grumble.

...her maps to 0! Moreover, I largely folled the Debian Wiki https://wiki.debian.org/AuthenticatingLinuxWithActiveDirectory. In their setup uids get prefixed by %D+. Unsure which I like better, but it's a least an observation. samba4 runs vanilla Debian Wheezy, i.e. samba 3.6.6. If this is a _known_ issue with that version, I readily update to backports 4.1.7. Otherwise, I have some reasons to explore the old version for a while. Thanks for your help, - lars.

Dear R developers, (Apologies about previous incomplete e-mail, I fat-fingered a keyboard shortcut)?? I recently upgraded to 3.2.3 and am getting mystifying errors with my in-development code (available at https://github.com/gertvv/gemtc/tree/feature/regression). Every few hundred LPs that I solve using the rcdd package will result in a SEGFAULT in the garbage collector (address 0x10, cause

...t;> If I remember correctly, that is an issue with TB - it only does body >> serches serverside, regardless of what you request, there should be an >> entry in their bugzilla, I'm too lazy right now. > > this is a very old bug > > at the very least, there are/were _known_ issues with TBird's > search-on-server bits. > > now, whether that issue is still relevant here, I dunno yet; haven't > finished digging through the ~ decade of Mozilla bug reports, finger > pointing, and lack-of-resource complaints.? grumble. A network trace will show...

...g that > it might be a temporary problem with the latest snapshot, I downloaded the > earliest snapshot I could get from the snapshots page. Same problem. It > also didn't matter either I used regular make or GNU make. > > Jan > Whilst there may well be problems, there are no _known_ problems, and we certainly won't be able to fix them unless you actually tell us what the problems are. Mike --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-reque...

On Thursday, 05 June 2003 at 16:26, Jan-Erik Moon wrote: ... > > Whilst there may well be problems, there are no _known_ problems, and we > > certainly won't be able to fix them unless you actually tell us what the > > problems are. > > Ok, here come the details: > > System #1: > > FreeBSD 5.1-BETA (updated from CURRENT branch on 9th of May) > libshout source is from nightly sn...

...thing more encouraging -- but this _sometimes_ happens with prebuilt R, or prebuilt packages. We try try chase this, and when we do batch runs of R CMD check over all reverse depends we end up rebuilding. I was just bitten by this when upgrading to Ubuntu 15.10 as it brings in g++-5.2 which has a _known_ ABI transition for C++11/14. About 15% of packages got 'random' (but repeatable) seg.faults when there were none before. And that went away with a proper R version also built with a gcc-5.2 toolchain. So in short: check your toolchain. Things may then go away. If they don't then ther...

...c that implies a full memory barrier, with RCpc it does not. Currently PowerPC is the only arch that (can, and) does RCpc and gives a weaker RELEASE + ACQUIRE. Only the CPU who did the ACQUIRE is guaranteed to see the stores of the CPU which did the RELEASE in order. As it stands, RCU is the only _known_ codebase where this matters, but we did in fact write code for a fair number of years 'assuming' RELEASE + ACQUIRE was a full barrier, so who knows what else is out there. RCsc - release consistency sequential consistency RCpc - release consistency processor consistency https://en.wikipe...

On Sun, Apr 7, 2013 at 7:24 PM, Cameron McInally <cameron.mcinally at nyu.edu> wrote: > Hey Jeffrey, > > Thanks for the suggestion. A few comments... > > On Sun, Apr 7, 2013 at 12:31 PM, Jeffrey Yasskin <jyasskin at googlers.com> > wrote: > ... >> >> If you can find a way to implement -fsanitize=undefined to use the FP >> trap instead of a branch

Hey Jeffrey, Thanks for the suggestion. A few comments... On Sun, Apr 7, 2013 at 12:31 PM, Jeffrey Yasskin <jyasskin at googlers.com>wrote: ... > > If you can find a way to implement -fsanitize=undefined to use the FP > trap instead of a branch when checking floating division by 0, I > suspect such a patch would stand a good chance of being accepted. > (Although I'm not

On 10/19/20 1:18 AM, John Fawcett wrote: > I would recommend you to redo the tests after correcting the > configuration. To be doubly sure you can include accented and unique non > accented text in the same email and search for both. If the non accented > text is found you know you've searching against the updated index and > the fact that accented text is not found is not

On Tue, Jan 12, 2016 at 11:40:12AM +0100, Peter Zijlstra wrote: > On Tue, Jan 12, 2016 at 11:25:55AM +0100, Peter Zijlstra wrote: > > On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote: > > > 2) the changelog _completely_ fails to explain the sync 0x11 and sync > > > 0x12 semantics nor does it provide a publicly accessible link to > > > documentation

On Tue, Jan 12, 2016 at 11:40:12AM +0100, Peter Zijlstra wrote: > On Tue, Jan 12, 2016 at 11:25:55AM +0100, Peter Zijlstra wrote: > > On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote: > > > 2) the changelog _completely_ fails to explain the sync 0x11 and sync > > > 0x12 semantics nor does it provide a publicly accessible link to > > > documentation

[mod: This discussion has been going on "offline" with an occasional CC to linux-security. By the time I got around to do another "moderation round" this one was the latest. Everyone is keeping good context, so I think you all will be able to follow the discussion. --REW] >>>>> <seifried@seifried.org> writes: >> The only thing I can see coming out

----- Original Message ----- From: "Michael Smith" <msmith@xiph.org> To: <icecast-dev@xiph.org> Sent: Wednesday, June 04, 2003 3:47 PM Subject: Re: [icecast-dev] libshout2 compiling problems under FreeBSD? <p>> Whilst there may well be problems, there are no _known_ problems, and we > certainly won't be able to fix them unless you actually tell us what the > problems are. Ok, here come the details: System #1: FreeBSD 5.1-BETA (updated from CURRENT branch on 9th of May) libshout source is from nightly snapshots (libshout-2.0-20030605) libvorbis and...

Hi, I couldn't find anything about this subject from archive - are there known problems with compiling libshout2 under FreeBSD 5.1 or 4.8 (both are up to date). I downloaded libshout2 latest nightly snapshot and tried to compile it on 5.0 and then later on 4.8. Both failed (problems were mostly around sock.c, sock.h, resolver.c - redeclaring and syntax errors). Thinking that it might be a