1 |
On Fri, 2022-02-11 at 09:40 -0800, A Schenck wrote: |
2 |
> On 2/10/22 15:36, Michał Górny wrote: |
3 |
> > Hi, |
4 |
> > |
5 |
> > As you may have noticed, I'm practically maintaining LLVM all by myself. |
6 |
> > This is a really tedious, time consuming and ungrateful task, and I'm |
7 |
> > pretty close to burnout. I'd really appreciate some help. |
8 |
> > |
9 |
> > The problem with LLVM that it's a really huge, rapidly moving forward |
10 |
> > (and breaking things) project. It needs frequent testing as regressions |
11 |
> > happen frequently, and we have a good chance of having somebody else fix |
12 |
> > it if we report them early. At the same time, testing takes a lot of |
13 |
> > time. While ccache is pretty much a must, it doesn't help much long |
14 |
> > term as the code is changing frequently and invalidating the cache. |
15 |
> > |
16 |
> > On top of this, there's almost-overlapping release process and Gentoo |
17 |
> > slotting that's working so-so at best. After I've pushed LLVM 13.0.1 |
18 |
> > final, I've had to immediately start testing 14.x and barely managed to |
19 |
> > get some fixes in before rc1. Now 14.0.0 is expected soon, |
20 |
> > simultaneously major changes are happening on the main branch |
21 |
> > (i.e. 15.x) that also need testing and adjusting the ebuilds to. |
22 |
> > |
23 |
> > I barely manage to keep up with amd64 multilib. Other arches are likely |
24 |
> > to be broken. Some specific projects that need help are: |
25 |
> > |
26 |
> > 1. Compiler-RT (particularly sanitizers, fuzzer etc.) -- they break |
27 |
> > quite often on glibc upgrades. Miraculously, right now 13.0.1 |
28 |
> > and 14.0.0 are clean right now but I'm pretty sure we'll see a new glibc |
29 |
> > release soon and they're going to require fixing again. |
30 |
> > |
31 |
> > 2. OpenMP -- there are many test regressions on every release, and 14.x |
32 |
> > is particularly bad. I have no clue about this package, the test output |
33 |
> > is usually cryptic and I don't really have the time to look into it. |
34 |
> > Honestly, at this point I would gladly have last rited it if it hadn't |
35 |
> > had revdeps. |
36 |
> > |
37 |
> > 3. LLDB -- while it mostly works and I've managed to fix the worst of |
38 |
> > it, I still haven't managed to get the test suite fully working. What's |
39 |
> > even worse, the test runner just hangs at the very end and I have |
40 |
> > no clue why or how to debug that. |
41 |
> You've probly already thought of this but this is when strace comes to |
42 |
> mind. Is it truly hanging in own code, or waiting on something to change |
43 |
> in the system that isn't happening? |
44 |
|
45 |
I don't recall anymore, I haven't had time to try again in a while. |
46 |
AFAIR it was the test runner hanging after all tests are done. |
47 |
|
48 |
-- |
49 |
Best regards, |
50 |
Michał Górny |