search for: signatures

Hi, I am trying to setup the antispam plugin using the direct dspam backend. I have set antispam_signature = X-DSPAM-Signature in dovecot.conf and in all mails I have signature lines like X-DSPAM-Signature: 1,49084a24139132188715614 but still, if I try to move a mail into the spam folder, i get the IMAP error message "antispam signature not found". I thought it might have to do

...le files but rather parts of files. Sadly, this functionality is not actually present in the rsync program. I'd like to explore adding this ability. There are basically three things that need to be done to enable efficient (partial-file) incremental tape backups, namely: 1) Generation of rsync signatures from existing files. 2) Generation of a binary patch from existing files + an rsync signature. 3) Application of a binary patch to existing files. Rsync already has the facility to generate and apply binary patches -- namely, batch-mode operation. Thus all that remains to be added is read and writ...

...>> > omittedSig <- sigNames %in% fnames[omitted] # .... > my "pretty sure" statement above has proven to be wrong .. >> > ------------- >> > >> >> I think the intention must have been that the two "ANY" signatures should change to "missing". > Definitely. >> However, with the current logic that will not happen, because >> >> > c(F,T,T,F) && c(T,T) >> [1] FALSE >> >> Henrik's non-fix would have resulted in &g...

I run checks with R-devel rev. 76756 on several of my packages which use S4, with no ill effects. With the risk of not adding much, it seems that Martin's example, which I repeat below, suggests a crossover between several "signatures" involved here - the signature of the generic, the signature of the method (the argument for setMethod()), and the signature of the function object defining the method. >> r2 <- oligoFn(object=diag(2), target=array(42)) > Error in .local(object, target) : >...

...ove > is useful for solving the issue -- I can work with that. > > I'm already pretty sure the wrong code starts with > > omittedSig <- sigNames %in% fnames[omitted] # .... > > ------------- > I think the intention must have been that the two "ANY" signatures should change to "missing". However, with the current logic that will not happen, because > c(F,T,T,F) && c(T,T) [1] FALSE Henrik's non-fix would have resulted in > c(F,T,T,F) & c(T,T) [1] FALSE TRUE TRUE FALSE which is actually right, but only coincidentally...

...a, a) cbind (a, a, a, deparse.level = 1) ### end example However, I get the following message: with setGeneric Creating a generic for "cbind" in package ".GlobalEnv" (the supplied definition differs from and overrides the implicit generic in package "base": Signatures differ: (...), (deparse.level)) How do I specify the correct signature? Furthermore: as I do not want to do anything with "deparse.level", I'd rather specify it as "missing" in setMethod. But again, I don't get the signature correct. I tried setGeneric ("cbi...

after this setClass("A") setGeneric("bar", function(x, y) standardGeneric("bar")) setMethod(bar, signature(x="A", y="A"), function(x, y) {}) setMethod(bar, signature(x="A", y="ANY"), function(x, y) {}) the method for signature c("A", "A") contains package information > str(getMethod(bar,

Hello, Is the signature-log backend of the antispam plugin broken when compiling with dovecot version 1.1.2? I'm using version 1.0 of the antispam plugin. It looks like there isn't anything more recent. cc -c -DCONFIG_DEBUG -DDEBUG_SYSLOG -fPIC -shared -Wall -Wextra -DPLUGINNAME=antispam -DHAVE_CONFIG_H -I../dovecot-1.1.2/ -I../dovecot-1.1.2/src/ -I../dovecot-1.1.2/src/lib/

...e there is a valid reason, I just don't get it...) > > > -pd > > I've also have mused over that question... > and I had assumed some difference in the case the original > omittedSig contains NAs ... but that's NOT true actually, see: > > > sign2 <- signatures <- LETTERS > > omittedSig <- LETTERS < "K" > > omittedSig[c(8,18)] <- NA # now have an omittedSig with {T, F, NA} > > iSig <- seq_along(omittedSig)[omittedSig] > > sign2[iSig] <- "missing" > > signatures[omittedSig] <-...

...-10 [SC] Key fingerprint = 4AA4 767B BC9C 4B1D 18AE 28B7 7F2D 434B 9741 E8AC uid [ unknown] Pierre Schmitz <pierre at archlinux.de> sub rsa2048/0xE9B9D36A54211796 2011-04-10 [E] wink at wink-desktop:~ $ gpg --import Documents/keys-crypto/hans-gpg-key.asc gpg: Note: signatures using the SHA1 algorithm are rejected *gpg: key 0x0FC3042E345AD05D: 1 bad signature* gpg: key 0x0FC3042E345AD05D: public key "Hans Wennborg <hans at chromium.org>" imported gpg: Total number processed: 1 gpg: imported: 1 wink at wink-desktop:~ $ echo $? 0 wink at wink-...

Henrik, If a minimal reprex is hard to construct, could you perhaps instrument your version of R to include a browser() call at the start of the else if(!all(signature[omittedSig] == "missing")) { branch, run the code that triggers the issue for you (and must hit that branch) and tell us what the "signature" and "omittedSig" objects look like at that point?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey everyone.. been struggling with building a mailserver and i'm almost done. One of the last pieces is integrating dovecot with dspam so that I'm users can train their spam filters easily (sieve filtering is the last piece left.. that should be interesting.. lol) Anyway, I think i found an issue with memory allocation, and I'm not sure

I made yum update to bind on 21.12.2019. Yum.log: Dec 21 23:14:41 Updated: 32:bind-license-9.11.4-9.P2.el7.noarch Dec 21 23:16:43 Installed: 32:bind-export-libs-9.11.4-9.P2.el7.x86_64 Dec 21 23:16:49 Updated: 32:bind-libs-lite-9.11.4-9.P2.el7.x86_64 Dec 21 23:16:50 Updated: 32:bind-libs-9.11.4-9.P2.el7.x86_64 Dec 21 23:18:02 Updated: rpcbind-0.2.0-48.el7.x86_64 Dec 21 23:23:21 Updated:

Full_Name: Tim Keitt Version: 1.5 OS: Linux Submission from: (NULL) (128.227.201.237) The function "setMethod" makes the following call to "insertMethod": allMethods <- insertMethod(allMethods, signature, fnames[1:length(signature)], asMethodDefinition(definition, signature)) If I understand insertMethod correctly, the third argument should be the names of the

...d", function(..., deparse.level=1) standardGeneric("rbind"), + signature = "...") Creating a generic for "rbind" in package ".GlobalEnv" (the supplied definition differs from and overrides the implicit generic in package "base": Signatures differ: (...), (deparse.level)) [1] "rbind" > rbind(1) [,1] [1,] 1 > rbind standardGeneric for "rbind" defined from package ".GlobalEnv" function (..., deparse.level = 1) standardGeneric("rbind") <environment: 0x83862f4> Methods may be d...

Hi. It looks like the gpg signatures of the RC2 and RC3 tarballs are bogus... I've tested the .bz2 and .tar.gz files downloaded from the us1 and us4 mirrors. To confirm that it's not a local problem, I've tested the signature of the Samba_CA.crt file (http://us4.samba.org/samba/ftp/) and it's ok. Can someone else ple...

While trying to install a package, I received this error ** preparing package for lazy loading Error in matchSignature(signature, fdef, where) : more elements in the method signature (2) than in the generic signature (1) A more helpful variant is Error in matchSignature(signature, fdef, where) : more elements in the method signature (2) than in the generic signature (1) for function

Hi, #tcsh#machine# gpg --verify openssh-4.1p1.tar.gz.asc openssh-4.1p1.tar.gz gpg: Signature made Wed May 25 08:26:24 2005 EDT using DSA key ID 86FF9C48 gpg: BAD signature from "Damien Miller (Personal Key) <djm at mindrot.org>" I made sure that I had the same key loaded that the signature was made with, but that didn't change the error. Thanks, Matt -- Matthew Goebel :

Send CentOS-announce mailing list submissions to centos-announce at centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request at centos.org You can reach the person managing the list at centos-announce-owner at centos.org When

...omittedSig <- sigNames %in% fnames[omitted] # .... ? ? >> my? "pretty sure"? statement above has proven to be wrong .. ? ? >>> > ------------- ? ? >>> > ? ? >>> ? ? >>> I think the intention must have been that the two "ANY" signatures should change to "missing". ? ? >> Definitely. ? ? >>> However, with the current logic that will not happen, because ? ? >>> ? ? >>> > c(F,T,T,F) &&? c(T,T) ? ? >>> [1] FALSE ? ? >>> ? ? >>> Henrik's non-fix w...