similar to: [cfe-dev] [3.9 Release] Release Candidate 3 source and binaries available

We're very very close to the final release. Source and binaries for LLVM-3.9.0-rc3 are available at http://llvm.org/pre-releases/3.9.0/#rc3 This release candidate is almost the same as rc2, with the following additional commits: r279224 - Minor change to OpenCL release notes r279260 - [lld] Add a note that 3.9 is a major milestone for us r279468, r279474 - Fix gather-root.ll SLP vectorizer

It's a test for the new interceptor for prlimit. It could be disabled with __GLIBC_PREREQ for 2.13+. On Fri, Aug 19, 2016 at 5:16 PM, Hans Wennborg <hans at chromium.org> wrote: > +Evgenii for msan. > > I suspect the community simply doesn't keep track of what glibc > version is required :-/ > > On Fri, Aug 19, 2016 at 5:10 PM, Brian Cain <brian.cain at

When I tested rc1 I found that some of the test suite wouldn't build on SLES11.3 as a consequence of changes to the tests. At least some of the msan tests have been changed leverage features of glibc newer than is available on this platform. I asked about a minimum-required glibc but didn't hear back. Is the minimum required glibc for 3.9 different from 3.8? When I tried rc1 on

Hello there, I’ve configured my server for maximum 50000 open files. [root at scast1 ~]# ulimit -a ... open files (-n) 50000 ... max user processes (-u) 65535 While im doing the Load Test 1, my server only reaches ~1015 listeners. I’ve set this on etc/security/limits.conf : icecast hard nofile 50000 icecast soft nofile 60000 icecast soft nproc 65535 icecast

Hi, I?ve been trying to increase the number of open files for the dovecot user on Debian 9 and have so far, failed! I?ve tried this: # cat /etc/security/limits.d/limits_dovecot.conf dovecot soft nofile 2048 dovecot hard nofile 8192 # cat /etc/systemd/system/dovecot.service.d/service.conf LimitNOFILE=8192 But to no avail: # prlimit -p 27208|grep -i

Hi all, KubeVirt uses libvirtd to manage qemu VMs represented as Kubernetes API resources. In this case, libvirtd is running inside an unprivileged pod, with some host mounts / capabilities added to the pod, needed by libvirtd and other services. One of the capabilities libvirtd requires for successful startup inside a pod is SYS_RESOURCE. This capability is used to adjust RLIMIT_MEMLOCK ulimit

Dear testers, 3.9.0-rc2 was just tagged from the 3.9 branch at r279183. This is a release candidate in the very real sense that if nothing new comes up, this is be what the final release looks like. There are currently no open release blockers, and no patches in my merge-queue. Please build, test, and upload binaries to the sftp. Let me know how everything goes. >From this point, the branch

On Thu, Aug 22, 2019 at 12:01 PM Laine Stump <laine@redhat.com> wrote: > > On 8/22/19 10:56 AM, Ihar Hrachyshka wrote: > > On Thu, Aug 22, 2019 at 2:24 AM Daniel P. Berrangé <berrange@redhat.com> wrote: > >> > >> On Wed, Aug 21, 2019 at 01:37:21PM -0700, Ihar Hrachyshka wrote: > >>> Hi all, > >>> > >>> KubeVirt uses

On Thu, Aug 22, 2019 at 2:24 AM Daniel P. Berrangé <berrange@redhat.com> wrote: > > On Wed, Aug 21, 2019 at 01:37:21PM -0700, Ihar Hrachyshka wrote: > > Hi all, > > > > KubeVirt uses libvirtd to manage qemu VMs represented as Kubernetes > > API resources. In this case, libvirtd is running inside an > > unprivileged pod, with some host mounts / capabilities

On Fri, 23 Aug 2019, 0:27 Laine Stump, <laine@redhat.com> wrote: > (Adding Alex Williamson to Cc so he can correct any mistakes) > > On 8/22/19 4:39 PM, Ihar Hrachyshka wrote: > > On Thu, Aug 22, 2019 at 12:01 PM Laine Stump <laine@redhat.com> wrote: > >> > >> On 8/22/19 10:56 AM, Ihar Hrachyshka wrote: > >>> On Thu, Aug 22, 2019 at 2:24 AM

(Adding Alex Williamson to Cc so he can correct any mistakes) On 8/22/19 4:39 PM, Ihar Hrachyshka wrote: > On Thu, Aug 22, 2019 at 12:01 PM Laine Stump <laine@redhat.com> wrote: >> >> On 8/22/19 10:56 AM, Ihar Hrachyshka wrote: >>> On Thu, Aug 22, 2019 at 2:24 AM Daniel P. Berrangé <berrange@redhat.com> wrote: >>>> >>>> On Wed, Aug 21,

> On 24 May 2018 at 20:43 Sophie Loewenthal <sophie at klunky.co.uk> wrote: > > > Hi, > > I?ve been trying to increase the number of open files for the dovecot user on Debian 9 and have so far, failed! I?ve tried this: > > # cat /etc/security/limits.d/limits_dovecot.conf > dovecot soft nofile 2048 > dovecot hard nofile

I am getting startup errors for nfs ganesha CentOS 7.3 with gluster 3.10.2 from CentOS storage sig # systemctl status nfs-ganesha ? nfs-ganesha.service - NFS-Ganesha file server Loaded: loaded (/usr/lib/systemd/system/nfs-ganesha.service; disabled; vendor preset: disabled) Active: failed (Result: core-dump) since Wed 2017-06-14 14:00:49 EDT; 4s ago Docs:

On 8/22/19 10:56 AM, Ihar Hrachyshka wrote: > On Thu, Aug 22, 2019 at 2:24 AM Daniel P. Berrangé <berrange@redhat.com> wrote: >> >> On Wed, Aug 21, 2019 at 01:37:21PM -0700, Ihar Hrachyshka wrote: >>> Hi all, >>> >>> KubeVirt uses libvirtd to manage qemu VMs represented as Kubernetes >>> API resources. In this case, libvirtd is running

Dear testers, 3.9.0-rc1 was just tagged from the 3.9 branch at r277207. This took a little longer than I'd hoped, but I think the branch is in a decent state now. There are still open merge requests and bugs, but I'd like to get the real testing started to see where we're at. Please build, test, and upload binaries to the sftp. Let me know how it goes. I'll upload source, docs,

On Tue, Jun 28, 2016 at 12:22 PM Rafael Espíndola <cfe-dev at lists.llvm.org> wrote: > > I think the main issue (besides users asking what's the big change in > > 4.0, which I agree is not a big problem) is that the bitcode > > compatibility policy is tied to the major version number. > > It is tied in saying we *can* drop compatibility, not that we will. If >

On Mon, Jun 27, 2016 at 3:29 PM, Chris Lattner <clattner at apple.com> wrote: > On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> That's what concerns me about going to the scheme Richard and Rafael >> suggested, of bumping the major version each time: we'd release 4.0, >> and would Tom's dot-release then be

> I think the main issue (besides users asking what's the big change in > 4.0, which I agree is not a big problem) is that the bitcode > compatibility policy is tied to the major version number. It is tied in saying we *can* drop compatibility, not that we will. If we still support loading 3.0 bitcode when 4.1 ships we just have to document that. It just given us the flexibility to

On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev <llvm-dev at lists.llvm.org> wrote: > That's what concerns me about going to the scheme Richard and Rafael > suggested, of bumping the major version each time: we'd release 4.0, > and would Tom's dot-release then be 4.1? That would be confusing to > those who are used to our current scheme. Chris suggested going

> I don't think this is as obvious as you might think it is. We can happily > drop the "major version equals bitcode compatibility" implicit promise if we > want, but it's been there for a while and will need some messaging as to the > actual promises here and what we'll do to fulfill and what we mean when we > want to change it (will we actually rev the