similar to: [LLVMdev] Buildslave atom1-buildbot

Hi LLVM Dev, One of my recent commits has broken build on Ubuntu Atom D2700. 2013/4/3 <llvm.buildmaster at lab.llvm.org>: > The Buildbot has detected a new failure on builder clang-atom-d2700-ubuntu-rel while building llvm. > Full details are available at: > http://lab.llvm.org:8011/builders/clang-atom-d2700-ubuntu-rel/builds/7852 > > Buildbot URL:

2013/4/3 David Tweed <david.tweed at arm.com>: > Hi, > > As someone working on ARM, we're interested in this sort of issue, to which > there's not yet a complete solution. Some advice below: > > > 2013/4/3 <llvm.buildmaster at lab.llvm.org>: >> The Buildbot has detected a new failure on builder > clang-atom-d2700-ubuntu-rel while building llvm.

Hi. As per[1], gcc-4.8 is the oldest supported *major* gcc version. But what about minor/patch versions? When https://reviews.llvm.org/D43779 was initially committed, a few[2][3] buildbots failed. As i have now looked into the issue: * but it is *REPRODUCIBLE* with gcc-4.8.4 and gcc-4.9.2 from debian oldstable (Jessie). * it is *NOT* reproducible with gcc-4.8.5 and gcc-4.9.3 from ubuntu 16.04,

On 3 April 2013 14:59, Timur Iskhodzhanov <timurrrr at google.com> wrote: > I'd usually expect tests to work exactly the same way on all platforms. > If there are things that must be handled differently on different > platforms, I'd expect those to have a separate test for each platform > with explicit flags for each of these platforms. > You're absolutely right,

Hmm, i guess i should have mailed cfe-dev too. Doing that now. On Sun, Apr 8, 2018 at 9:38 PM, Roman Lebedev <lebedev.ri at gmail.com> wrote: > Hi. > > As per[1], gcc-4.8 is the oldest supported *major* gcc version. > But what about minor/patch versions? > > When https://reviews.llvm.org/D43779 was initially committed, > a few[2][3] buildbots failed. As i have now

+ Denis and Galina who should know about the affected buildbots and whether it's fine to upgrade them or whether their configurations reflect some important use cases. Sylvestre should know if the release process for LLVM on Ubuntu/Debian relies on the older GCC toolchains somehow. On Mon, Apr 9, 2018 at 1:51 PM Roman Lebedev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hmm,

You don't really need to use the llvm builders infrastructure, just setup a local jenkins (or whatever) bot that triggers from the llvm svn, see http://stackoverflow.com/questions/10014252/jenkins-ci-how-to-trigger-builds-on-svn-commit 2016-05-27 22:26 GMT+03:00 Asiri Rathnayake via cfe-dev < cfe-dev at lists.llvm.org>: > Hi Galina, > > I would like to setup a silent

How do we register buildslaves with the llvm buildbot? We run buildbot internally for clang/llvm. We would like to register our buildslaves with the official llvm buildbot. reed

Hi Galina, I would like to setup a silent buildslave for some experiments. Essentially, I would like to receive build requests from the llvm master buildbot, do my local builds but not publish results on the main buildbot (or complain to users when the builds fail). Would such a setup be possible? I looked at the documentation [1] but that seems to describe a normal buildslave setup. Thanks. /

Hi Reed, > How do we register buildslaves with the llvm buildbot? you point it at lab.llvm.org port 9990 and send the buildslave name and password to Galina. Ciao, Duncan.

Hi, as raghesh already posted in a previous mail, we would like to add some Polly buildslaves to the buildmaster. I just finished to set up the buildslave and now need someone to add my password to the config files. As Daniel seems to be on leave, I wonder who else has access to this machine? Cheers and thanks Tobi

This drop-in patch increases the performance of the get_checksum1() function on x86-64. On the target slow CPU performance of the function increased by nearly 50% in the x86-64 default SSE2 mode, and by nearly 100% if the compiler was told to enable SSSE3 support. The increase was over 200% on the fastest CPU tested in SSSE3 mode. Transfer time improvement with large files existing on both ends

Hi Asiri, You can use your local master for this or use silent master. Silent buildbot is currently copy of llvm buildbot, but does not sent any notifications. The both have the same set of builders and it's easy to switch a slave between them. To add slave/builder please add your slave and builder to zorg, but point your slave to silent master: use lab.llvm.org:9994 instead of

Hi, So now that the OpenBSD buildslave has been upgraded with enough memory to allow the build to finish I have noticed some issues with the test framework and was wondering if anyone could comment on what has shown up and/or anyone who is familiar with the framework could provide patches to fix the issues. For sed and head the tests are using command line options which are not specified by

Please see below. I think I know what is going on (it seems to be a make/gmake incompatibility), but to fix it, I need to rewrite some of the HP-UX packaging code, and I need a HP-UX user to help test this. Otherwise, I'm going to just rip it out for now, and add it back in when someone complains. On Feb 4, 2014, at 10:17 PM, Charles Lepple wrote: > For reasons unrelated to NUT, I

I was hoping to avoid the trouble of having to setup a master buildbot. But may be it's just easier to run Zorg as-is locally alongside the buildslave. I'll give that a go. Cheers, / Asiri On Fri, May 27, 2016 at 8:45 PM, Yaron Keren <yaron.keren at gmail.com> wrote: > You don't really need to use the llvm builders infrastructure, just setup > a local jenkins (or

Hello, Has anyone out there been able to qualify the Proliant DL360 G7 for your Solaris/OI/Nexenta environments? Any pros/cons/gotchas (vs. previous generation HP servers) would be greatly appreciated. Thanks in advance! -Anh

For reasons unrelated to NUT, I upgraded my FreeBSD-x86 buildslave machine from 9.1 to 10.0. This involved rebuilding the whole ports tree, but no other (intentional) changes were made. Now, I get this error: (cd scripts && make top_distdir=../nut-2.7.1.5 distdir=../nut-2.7.1.5/scripts \ am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir) make[4]: don't

For reasons unrelated to NUT, I upgraded my FreeBSD-x86 buildslave machine from 9.1 to 10.0. This involved rebuilding the whole ports tree, but no other (intentional) changes were made. Now, I get this error: (cd scripts && make top_distdir=../nut-2.7.1.5 distdir=../nut-2.7.1.5/scripts \ am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir) make[4]: don't

Hello, The llvm-x86_64-linux bot is failing. Seems it ran out of space on disk. I am not sure who is maintaining the bot. http://lab.llvm.org:8011/builders/llvm-x86_64-linux/builds/4917/steps/compile/logs/stdio > ranlib: /home/baldrick/osuosl/slave/llvm-x86_64/llvm/Debug+Asserts/lib/libLLVMSelectionDAG.a: No space left on device Cheers, Anna. -------------- next part -------------- An HTML