similar to: [LLVMdev] Server Restart: Adding New Certificate

John Criswell wrote: > Dear All, > > Some of you may have noticed that our SSL certificate expired about half > an hour ago. We have a new SSL certificate, but we haven't had time to > install it. > > I am going to attempt to install the new certificate. This will > necessitate one server restart if I am successful and probably two if > I'm not. > >

Please refrain from comitting to cvs. I will send email once I have finished creating the branch. Thanks, Tanya

Dear All, The good news is that the new llvm.org SSL certificate is installed and appears to be configured correctly. The bad news is that some machines seem to recognize the intermediate SSL certificate (which is apparently used to sign the SSL certificates UIUC buys starting this year) while others do not. In particular, our internal Linux machines show no errors, while our Macs and

Branch has been created. CVS is open again. -Tanya On Mon, 6 Nov 2006, Tanya M. Lattner wrote: > > Please refrain from comitting to cvs. I will send email once I have finished > creating the branch. > > Thanks, > Tanya > >

On 6/28/11 3:56 PM, John Criswell wrote: > Dear All, > > The good news is that the new llvm.org SSL certificate is installed and > appears to be configured correctly. As a followup to this, I discovered that I was using the MacPorts version of the svn client on our Mac OS X system. Using the svn client in /usr/bin/svn seems to recognize the certificate just fine. The pattern that

Any issues with permanently accepting the intermediate certificate, which I did this morning, when getting the message? Thanks in advance Garrison On Jun 29, 2011, at 12:13, John Criswell wrote: > On 6/28/11 3:56 PM, John Criswell wrote: >> Dear All, >> >> The good news is that the new llvm.org SSL certificate is installed and >> appears to be configured

I will be creating the release branch at 1:00pm PDT. Please refrain from checking in from 1:00-1:30pm. I will send email once I am done. Thanks, Tanya

This is just a reminder that I will be creating the 1.8 release branch in 1 hour. Please refrain from checking into cvs after 9PM PDT until I send out email confirming the branch has been created. Thanks, Tanya Lattner

I will be creating the branch at 9PM PST. Please refrain from checking in any large changes until after the branch creation. I'm still seeing unexpected dejagnu failures for PPC and X86. Platform maintainers, please XFAIL these and file bugzilla bugs. Email me if you have concerns or questions. -Tanya

LLVMers, I will be creating the branch in 30 minutes (9PM PDT). At that time, I will send out mail announcing SVN commit access is suspended. Those with commit privileges should refrain from committing until I send out mail saying commit access is restored. Thanks, Tanya Lattner

Branches have been created. You are free to checkin to cvs head again. I'll send mail once I have the prerelease tar balls up. Please continue to review and revise the documentation. I can fold this into the release later. Thanks, Tanya On Thu, 13 Apr 2006, Tanya Lattner wrote: > > I will be creating the release branch at 1:00pm PDT. Please refrain from > checking in from

Dear LLVMers, I'll be restarting the LLVM web server in about 15 minutes (3:30 pm Central Time). It's a small web server configuration change, so it'll be a quick restart. For paranoia's sake, please refrain from doing SVN commits starting at 3:30. I'll email once the web server is back online. -- John T.

Hi, I am currently setting up a backup script for the /home directory of a server. I send all the files on a remote machine through LAN connection using rsync to optimize bandwidth usage. The script is run as root on the server by a cron job but rsync connects to the remote machine as a normal user via an ssh key certificate. This leads to many "permission denied" errors, as the

I'm creating the 2.0 release branch. Users with cvs commit access, please refrain from checking anything in. I will send email out once I have finished. -Tanya

The 2.6 code freeze is tomorrow, August 21st, at 9pm PDT. Please refrain from checking in any changes that are major or invasive. This is not the time to be checking in as much as you can because you are trying to cram it into the release. Those who do not use caution with what they commit, may find their commit privileges restricted around the next release. I'm going to stress this

> On Jun 22, 2017, at 12:00 PM, Tom Stellard <tstellar at redhat.com> wrote: > > On 06/21/2017 03:22 PM, Tanya Lattner via llvm-dev wrote: >> LLVMers, >> >> >> >> TheLLVM.org <http://LLVM.org>server which hosts SVN, GIT mirror, documentation, and the mainLLVM.org <http://LLVM.org>website is moving to a new server on June 24th. As a

On Wednesday 28 January 2009 15:59, Tanya Lattner wrote: > On Jan 28, 2009, at 12:18 PM, David Greene wrote: > > I have a buildbot operating to do validating builds of llvm up at > > > > http://obbligato.org:8080 > > > > My DSL has been stable enough for the past few months for me to > > feel comfortable hosting the buildbot there. > > We had a

Can the glusterd daemon be restarted on all storage nodes without causing any disruption to data being served or the cluster in general? I am running gluster 3.2 using distributed replica 2 volumes with fuse clients. Regards, Mark -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 3/14/19 9:32 AM, Yassine Chaouche via dovecot wrote: > The general answere here is try and see, as you could totally test it > on your own. The certificate is read at startup and put in memory for > the rest of the execution time. Dovecot won't monitor the file for > changes on disk, as this would waste CPU cycles and make dovecot only > slower for no reason. The process

The various intrinsic assert/crashes should all be fixed on mainline CVS (they are PR733, which I just fixed). The only ones that I'm wary of are: XPASS: /proj/llvm/build/../llvm/test/Regression/CFrontend/2004-02-20- StaticRedeclare.c.tr FAIL: /proj/llvm/build/../llvm/test/Regression/CFrontend/2005-12-04- DeclarationLineNumbers.c: In the former case, I would guess that the test isn't