search for: rupprecht

>>> TL;DR: please try the patch out and report if it causes "Did not receive >>> identification string" log messages. I believe it does not. Aw crap. My homegrown anti-dos tool for ssh looks for either DNRIS or if logging is verbose enough a connection that didn't result in a login. I give the attacker a few tries and whitelist any successful candidate so I

...= 0ms, Maximum = 0ms, Average = 0ms C:\> The first one is probably a firewall, but the 147.135.0.129 indicates a larger problem. P.S - Can phones that do not support outbound proxy also register at 147.135.8.128 (not just Asterisk?) ----- Original Message ----- From: "Wolfgang S. Rupprecht" <list+asterisk-users@lists.wsrcc.com> To: <asterisk-users@lists.digium.com> Sent: Monday, July 26, 2004 1:57 PM Subject: Re: [Asterisk-Users] Broadvoice problems again > > oej@edvina.net (Olle E. Johansson) writes: > > The easiest first-level hack would be to randoml...

Jordan, I have sent the patch via Phabricator: https://reviews.llvm.org/D69188 Let me know if I got it right. -- Tobias On Thu, Oct 17, 2019 at 7:12 PM Jordan Rupprecht <rupprecht at google.com> wrote: > > Tobias, > I don't have much experience with ARM, but from your report and Peter's explanation of why LLD does it, I agree we should be consistent with LLD and keep the section. > > From my skimming of the LLD sources, it looks like w...

...Off the top of my head, I remember that asan, tsan, msan, hwasan, the kernel santizers, and sancov have been ported. I don't think ubsan has been ported yet though. You can also check if other passes you need run under the new PM by checking PassRegistry.def. On Fri, Aug 2, 2019, 14:20 Jordan Rupprecht <rupprecht at google.com> wrote: > Hi Leonard, > Is the new pass manager expected to work with sanitizers now? > > On Fri, Aug 2, 2019 at 1:25 PM Leonard Chan via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I think so far most individual projects have t...

On Tue, 15 Jan 2019, Hans Wennborg wrote: > On Sat, Jan 12, 2019 at 12:49 AM Jordan Rupprecht <rupprecht at google.com> wrote: >> >> >> >> On Fri, Jan 11, 2019 at 6:26 AM Martin Storsjö <martin at martin.st> wrote: >>> >>> Hi, >>> >>> The COFF support in llvm-objcopy is in a pretty half-finished state at the >>&gt...

...mmitted without review". > > Do you have any examples that didn't have post-approval-pre-commit changes > that still got this annotation about being committed without review? > > https://reviews.llvm.org/D81267 > > > Last one seems more clear - one of the reviewers (rupprecht) still had the > review marked "requires changes", so it was committed without closure on > that > Indeed this one shows the message: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20200713/807554.html -- Mehdi -------------- next part -------------- An HTML attachme...

On Fri, Jan 11, 2019 at 6:26 AM Martin Storsjö <martin at martin.st> wrote: > Hi, > > The COFF support in llvm-objcopy is in a pretty half-finished state at the > moment. I had hoped to have it mostly usable for the common scenarios by > the time of the branch (the initial patch was sent at the end of > November), but it's still lacking stripping of sections (while

On Thu, Oct 10, 2019 at 1:14 PM Jordan Rupprecht <rupprecht at google.com> wrote: > > > On Thu, Oct 10, 2019 at 12:29 PM Tom Stellard via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On 10/10/2019 11:40 AM, Mehdi AMINI wrote: >> > >> > >> > On Thu, Oct 10, 2019 at 10:59 AM Tom S...

Pinging this thread to see if anyone else has opinions or objections -- if not I plan to go ahead with stepping towards compatibility with readelf vs llvm-readelf in https://reviews.llvm.org/D54124 on Monday. On Tue, Nov 6, 2018 at 9:52 AM Jordan Rupprecht <rupprecht at google.com> wrote: > Hi James, > > I also wanted to work on this discrepancy, but I just sent a patch instead > of an RFC: https://reviews.llvm.org/D54124. Thanks for sending the RFC > that I should have started myself :) > > On Tue, Nov 6, 2018 at 4:53 AM...

...approach as > suggested by Michael Spencer at the BoF could be to migrate away from using > cl::opt and follow the same route as llvm-objcopy. That would allow us to > have different option sets for the two versions of that tool, if we wanted. > > On Tue, 16 Apr 2019 at 08:44, Jordan Rupprecht <rupprecht at google.com> > wrote: > >> For binutil compatibility, and in general for any new tools, this sounds >> reasonable to me. But I'd worry that things like llvm-readobj have existed >> for a long time and people are used to flags like "-sections"...

...ou want to run just one test then you can use bin/llvm-lit -v -a /path/to/test.s (from your build directory). The instructions on how to contribute are in https://llvm.org/docs/DeveloperPolicy.html the people that I know have been active in llvm-objdump are MaskRay (Fangrui Song), rupprect (Jordan Rupprecht), grimar (George Rimar). If you include these people on the reviewers then I'm sure they'll be able to add anyone else that they think would be interested. Hope this helps Peter On Thu, 17 Oct 2019 at 12:53, Tobias Hieta <tobias at plexapp.com> wrote: > > Hello Peter, > &g...

...fault at all /give error messages) From: James Henderson <jh7370.2008 at my.bristol.ac.uk> Sent: Wednesday, June 26, 2019 2:31 AM To: Alex Brachet-Mialot <alexbrachetmialot at gmail.com> Cc: Fāng-ruì Sòng <maskray at google.com>; LLVMDev <llvm-dev at lists.llvm.org>; Jordan Rupprecht <rupprecht at google.com>; Chen, Yuanfang <Yuanfang.Chen at sony.com> Subject: Re: [llvm-dev] [RFC] [tools] Changing Behavior of LLVM binutils When No File Is Specified I agree with others that the a.out behaviour is weird (I've even thought this about the linker output being calle...

For binutil compatibility, and in general for any new tools, this sounds reasonable to me. But I'd worry that things like llvm-readobj have existed for a long time and people are used to flags like "-sections", and it may be complicated to change that now. (I guess this RFC is a check to see if this is true for anyone on the mailing list). What happens if you make this change and

...ames Henderson <jh7370.2008 at my.bristol.ac.uk> >> *Sent:* Wednesday, June 26, 2019 2:31 AM >> *To:* Alex Brachet-Mialot <alexbrachetmialot at gmail.com> >> *Cc:* Fāng-ruì Sòng <maskray at google.com>; LLVMDev < >> llvm-dev at lists.llvm.org>; Jordan Rupprecht <rupprecht at google.com>; Chen, >> Yuanfang <Yuanfang.Chen at sony.com> >> *Subject:* Re: [llvm-dev] [RFC] [tools] Changing Behavior of LLVM >> binutils When No File Is Specified >> >> >> >> I agree with others that the a.out behaviour is weird...

On Thu, Feb 06, 2020 at 11:46:26AM -0800, Jordan Rupprecht via llvm-dev wrote: > > Where was this policy, which sounds like replicating their design > mistakes bug-for-bug, agreed upon and documented? > James responded already, but just to add my perspective: on the subject of > llvm vs gnu binutils compatibility, I've heard everything i...

https://llvm.org/docs/DeveloperPolicy.html#new-targets says that experimental backends should be supported by an active community, in part by providing build bots and fixing bugs related to the backend. So while it doesn't *explicitly* say things about patches that only break those backends, I think reading the spirit of that policy says that it's the responsibility of the experimental

...route all the incoming FWD calls to a context that prepends "393-9" to their 6-digit prefixes? (And for extra credit "393-99" to their 5-digit prefixes?) Unless I can fix up their CID, the dialback buttons on the phone (and in voicemail) are useless. -wolfgang -- Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ Send personal replies to this address. Mailman won't let me post unless I forge the From-line to be the same as my incoming alias for this list. <wolfgang+gnus20040629T111236@dailyplanet.dontspam.wsrcc.com>

http://yro.slashdot.org/article.pl?sid=04/08/04/2212251&tid=158&tid=95&tid=103 Probably some of you already saw this. Now, beyond discussions regarding the legitimacy of such a ruling (whether they have the legal, moral or whatever right to enforce it), there's the technical aspect. Suppose i provide VoIP services using Asterisk, and i fall under the incidence of the FCC ruling

Hello, I have a problem with connecting a Digium X100P card to a Brazilian analog line. Can somebody help me out with this problem? My /etc/zaptel.conf is loadzone=br defaultzone=br fxsks=1 My /etc/asterisk/indications.conf [general] country=br [br] description = Brazil ringcadance = 1000,4000 dial = 425 busy = 425/250,0/250 ring = 425/1000,0/4000 congestion =

Has anyone else noticed Phabricator sending emails saying: This revision was not accepted when it landed; it landed in state "Needs Review". when the review clearly has been accepted by someone? Some recent examples: https://reviews.llvm.org/D83952 https://reviews.llvm.org/D80116 https://reviews.llvm.org/D81267 Thanks, Jay.