similar to: LNT easy_install problem

Dear Community members, I am trying to setup *lnt* on a system where I do not have sudo access. I am facing the following issue. Kindly suggest a solution. virtualenv version => 1.11.6 OS => Debian with kernel 3.16.7 *While installing lnt into a virtual environment, I am getting the following error -* *Processing six-1.9.0.tar.gz* *Writing /tmp/easy_install-ZBhMFI/six-1.9.0/setup.cfg*

I'd be fine pulling the pypi (sic) entry, shall I make it so? - Daniel On Tue, Jul 18, 2017 at 11:06 AM Chris Matthews <chris.matthews at apple.com> wrote: > Yep, we should pull that package down, or start to update it. > > The docs builds work for me. Is it possible that is not in your venv or > something like that? > > > On Jul 18, 2017, at 10:48 AM, Matthias

I updated the docs to show a pip/svn install like this: pip install svn+http://llvm.org/svn/llvm-project/lnt/trunk <svn+http://llvm.org/svn/llvm-project/lnt/trunk> > On Jul 18, 2017, at 11:24 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > > >> On 18 Jul 2017, at 20:21, Daniel Dunbar <daniel at zuster.org <mailto:daniel at zuster.org>> wrote:

Hello, as of Jul 9, the LNT build bot on SystemZ shows red. The problem occurs in the "setup lit" test, which fails due to: Processing dependencies for LNT==0.4.2.dev0 Searching for typing Reading https://pypi.org/simple/typing/ Downloading

Hi, working on the LNT documentation I am wondering about a few things: - LNT documentation recommends to do `easy_install lnt==0.4.2dev` (in the install box on the left side of the title page). The last available version of LNT on pypy is version 0.4.0 from 2012. Are there plans to keep this up to date or should we better remove the entry and not mention pypy packages anymore? - Building the

Folks, Its seems that the latest master restart has introduced a failure in *many* test-suite bots: File "/home/buildslave/buildslave/clang-cmake-aarch64-full/test/lnt/lnt/server/ui/decorators.py", line 6, in <module> frontend = flask.Module(__name__) AttributeError: 'module' object has no attribute 'Module'

Hi Renato, We're also seeing this on internal bots. My first guess is that it was triggered by the Flask package getting updated at Pypi on 29th of May, see https://pypi.python.org/pypi/Flask. I haven't investigated further at this point. Thanks, Kristof On 29 May 2016, at 14:28, Renato Golin <renato.golin at linaro.org<mailto:renato.golin at linaro.org>> wrote: Folks,

I followed the lnt quickstart <http://llvm.org/docs/lnt/quickstart.html> directions but got this diagnostic when doing the setup: bash-3.2$ ~/mysandbox/bin/python ~/lnt/setup.py develop /Users/dcallahan/mysandbox/lib/python2.7/site-packages/setuptools/dist.py:284: UserWarning: The version spec\ ified requires normalization, consider using '0.4.1.dev0' instead of

Hi David, That's weird, I have setup LNT in multiple different distros and have never seen this. Looks like no one ever tested on the system you're running. Can you share a bit more of your environment? Also, you can check the setup.py to see if it does any stripping of package names, which could go wrong in the wrong environment. cheers, --renato On 29 January 2015 at 20:13, David

Hi, I'm trying to use LNT to run the test-suite. I followed the instructions on <http://lnt.llvm.org/quickstart.html>. When I run it I get this error: (mysandbox)sean:~/pg/others/llvm % lnt runtest nt --sandbox mysandbox --cc ~/pg/others/llvm/release/bin/clang --test-suite test-suite nt.py:1185: note: inferred C++ compiler under test as:

On Wed, Sep 5, 2012 at 7:23 PM, Sean Silva <silvas at purdue.edu> wrote: > Hi, I'm trying to use LNT to run the test-suite. I followed the > instructions on <http://lnt.llvm.org/quickstart.html>. When I run it I > get this error: > > (mysandbox)sean:~/pg/others/llvm % lnt runtest nt --sandbox mysandbox > --cc ~/pg/others/llvm/release/bin/clang --test-suite

> And it doesn't match probably because of one of two things (& I forget > which of the two, if either, have been addressed/workaround): > > 1) using cmake instead of configure/make > 2) using git instead of svn > > One or both of these create versions that lnt doesn't understand > (because they don't include the SVN revision number in the clang > version

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/8218 Searching for aniso8601>=0.82 Reading https://pypi.python.org/simple/aniso8601/ Download error on https://pypi.python.org/simple/aniso8601/: [Errno 107] Transport endpoint is not connected -- Some packages may not be found! Couldn't find index page for 'aniso8601' (maybe misspelled?) Scanning index of all

Daniel, Tobias, Renato and myself have been looking a little bit at the potential underlying reason for why http://llvm.org/perf/ is instable, and have found some clues. I want to share them here to give people with more experience in the frameworks used by LNT (flask, sqlalchemy, wsgi, .) a chance to check if our reasoning below seems plausible. Daniel noticed the following backtrace in the

Renato, Kristof, I confirm this is due to the latest Flask --- Flask-0.11 was released this weekend --- and for some unknown (to me at least) reason, although LNT's requirements.txt pins Flask to version 0.10.1, pip installs Flask-0.11. Forcing Flask to 0.10.1 gets the situation back to normal. Reading pip's documentation makes me think it's not able to resolve dependencies

Hi folks, I noticed our test-suite bot is failing randomly when getting a timeout on the install phase: http://lab.llvm.org:8011/builders/clang-native-arm-lnt/builds/666/steps/venv.lnt.install/logs/stdio Downloading/unpacking Werkzeug>=0.6.1 (from Flask->LNT==0.4.1dev) Exception: File

Ping? This is getting as often as every other run... Is that process downloading from an internal server? If not, should we? If yes, should we not? thanks, --renato On 20 April 2013 14:03, Renato Golin <renato.golin at linaro.org> wrote: > Hi folks, > > I noticed our test-suite bot is failing randomly when getting a timeout on > the install phase: > > >

Hi, There was a new Python setuptools release (36.0.0) today, that caused this compatibility issue. The suggestion to stop breaking the builds is to add a static setuptools version on lnt's requirements.client.txt. The latest known compatible version is 35.0.2. I have tested it building a LNT sandbox and it seems to works. setuptools==35.0.2 I'll create a bug on LNT so we can

Lets deal with this in a PR: https://llvm.org/bugs/show_bug.cgi?id=28347 I’m surprised how often this is happening. I propose we lock all the dependency versions in LNT, and upgrade them on some cycle (maybe yearly). Otherwise this will happen every time we have a dependent package’s default version change. We have always done this in the reqirements.txt file, and that has worked really well

Hi, I follow quick-start guide http://llvm.org/docs/lnt/quickstart.html to run LLVM test-suite. It looks like I either make a mistake or the guide is not correct. Here is the command used to run nightly test: [[ $ lnt runtest nt --sandbox=$PWD/test-suite.bld \ --small --test-style=nightly \ --cc=$PWD/llvm.bld/Release+Asserts/bin/clang \ --cxx=$PWD/llvm.bld/Release+Asserts/bin/clang++