What about creating a release management mailing list ?
The testers are usually the same (hello folks!) :)
Sylvestre
Le 20/01/2016 00:55, Hans Wennborg a écrit :
> (cc'ing non-legacy llvm-dev this time; apologies if you get this
> twice. Please don't reply-all to the first one.)
>
> On Tue, Jan 1
This isn't rc1 but the tip of the release branch had some X86 test failures on
my most recent build:
Failing Tests (24):
libc++ ::
std/input.output/file.streams/fstreams/filebuf.virtuals/overflow.pass.cpp
libc++ ::
std/input.output/file.streams/fstreams/filebuf.virtuals/underflow.pass.cp
Hello,
thanks for confirming my suspicions. Sending the extra running event
seems quite annoying to me as well, but it is how things work at the
moment. And the problem does not seem to be linux-specific. This is
the sequence of events I get on a Mac, when running over a conditional
breakpoint tha
Hi,
I have removed all of our expected timeouts from dosep.py (there are
still some freebsd and darwin ones left, but I don't know If anyone is
looking at those), so I think we're not using any part of the old test
runner at the moment. All clear for removal on our part.
pl
On 14 December 2015
Unfortunately I'm having lots of trouble with rc1 at this point:
* libcxxabi can't build, because it requires unwind.h, which we do not yet have
on FreeBSD 10.x (Ed Maste is working on it for 11.x, but that is not ready for
general consumption).
* The test-release.sh script has no option to disab
Hans, Daniel,
How are things going? It's been 5 days and no word. I'm running the
tests now, just in case, but would be good to know that no one would
be committing to the release candidate 1 tree in the mean time.
cheers,
--renato
On 15 January 2016 at 15:56, Daniel Sanders via llvm-dev
wrote:
Sorry for not replying back on this thread. We moved offices over the weekend
and I've been busy sorting various things out.
I'm currently building rc1 but my most recent build on the release branch had
some regressions. I mentioned them on the rc1 thread but to summarize here:
* X86 failed ~20
On Wednesday, January 20, 2016 07:47 AM, Hans Wennborg wrote:
Dear testers,
Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
r258223. (It took a little longer than I'd planned, sorry about that.)
There are still a bunch of open merge requests and bug reports, but I
wanted to
Please do file a bug, that's definitely not how things are supposed to work.
You will still see a private "running" event, of course, since those are just
the raw events from the target, but the running event shouldn't get broadcast
to the public event queue if it was coming from a continuation
That would certainly make my emails easier to address :-) On the other
hand, I do think there's a point to asking for testers each time and
then only addressing those that sign up explicitly. What do the rest
of you think about having a list?
On Wed, Jan 20, 2016 at 1:31 AM, Sylvestre Ledru wrote
On Wed, Jan 20, 2016 at 2:15 AM, Ismail Donmez wrote:
> On Wed, Jan 20, 2016 at 1:47 AM, Hans Wennborg via cfe-dev
> wrote:
>> Dear testers,
>>
>> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
>> r258223. (It took a little longer than I'd planned, sorry about that.)
>>
>> T
On Wed, Jan 20, 2016 at 5:25 AM, Dimitry Andric wrote:
> Unfortunately I'm having lots of trouble with rc1 at this point:
> * libcxxabi can't build, because it requires unwind.h, which we do not yet
> have on FreeBSD 10.x (Ed Maste is working on it for 11.x, but that is not
> ready for general c
On Wed, Jan 20, 2016 at 7:54 AM, Ben Pope wrote:
> On Wednesday, January 20, 2016 07:47 AM, Hans Wennborg wrote:
>>
>> Dear testers,
>>
>> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
>> r258223. (It took a little longer than I'd planned, sorry about that.)
> Some issues:
I'm trying to get the lldb tests running using lldb built with Hexagon
support. Some tests are running correctly, but others are failing/skipped
etc.
First, I'd like to get it to skip tests that shouldn't be run. For example,
I see output that looks like this:
Configuration: arch=x86_64
compi
On Wed, Jan 20, 2016 at 7:32 AM, Renato Golin wrote:
> Hans, Daniel,
>
> How are things going? It's been 5 days and no word. I'm running the
> tests now, just in case, but would be good to know that no one would
> be committing to the release candidate 1 tree in the mean time.
Did you send this b
If it should never run with x86_64 on Hexagon, then don't bother using
command lines, just change dotest.py so that when the target is hexagon,
the default archs doesn't include x86_64
On Wed, Jan 20, 2016 at 9:48 AM Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> I’m trying to get
What is the sequence of lldb commands you use to innitiate a hexagon
debug session normally? Do you need to set a custom platform (platform
select XXX)? If so, then you need to look into --platform-name (and
possibly --platform-url, --platform-working-dir) parameter, and
possibly add some support t
A Hexagon debug session connects to the Hexagon simulator. lldb launches
hexagon-sim in the same way it launches lldb-server or debugserver.
When a Hexagon target is loaded, lldb automatically selects the hexagon
platform.
So, no special settings - target create, set a breakpoint, run.
--
Qual
Where are the default archs defined? I’m not seeing it, looking through
testcases/dotest.py.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
From: Zachary Turner [mailto:ztur...@google
Apparently I'm dumb, you actually should specify archs. For example, on
Windows we use --arch=i686
If you don't specify a value for --arch, it uses the result of
`platform.machine()`. If you do, it uses the list that you specify. So
basically if you say --arch=i386 or something like, it will us
On 20 Jan 2016, at 18:23, Hans Wennborg wrote:
>
> On Wed, Jan 20, 2016 at 5:25 AM, Dimitry Andric wrote:
>> Unfortunately I'm having lots of trouble with rc1 at this point:
>> * libcxxabi can't build, because it requires unwind.h, which we do not yet
>> have on FreeBSD 10.x (Ed Maste is workin
On Wed, Jan 20, 2016 at 12:18 PM, Dimitry Andric wrote:
> As to the symlinks, the test-release.sh script originally checks out the
> sources in parallel directories, e.g.:
>
> llvm.src
> cfe.src
> compiler-rt.src
>
> and so on. Within llvm.src, symlinks are made to point to each of these.
> Fo
22 matches
Mail list logo
