Hi,You've probly already thought of this but this is when strace comes to
As you may have noticed, I'm practically maintaining LLVM all by myself.
This is a really tedious, time consuming and ungrateful task, and I'm
pretty close to burnout. I'd really appreciate some help.
The problem with LLVM that it's a really huge, rapidly moving forward
(and breaking things) project. It needs frequent testing as regressions happen frequently, and we have a good chance of having somebody else fix
it if we report them early. At the same time, testing takes a lot of
time. While ccache is pretty much a must, it doesn't help much long
term as the code is changing frequently and invalidating the cache.
On top of this, there's almost-overlapping release process and Gentoo slotting that's working so-so at best. After I've pushed LLVM 13.0.1
final, I've had to immediately start testing 14.x and barely managed to
get some fixes in before rc1. Now 14.0.0 is expected soon,
simultaneously major changes are happening on the main branch
(i.e. 15.x) that also need testing and adjusting the ebuilds to.
I barely manage to keep up with amd64 multilib. Other arches are likely
to be broken. Some specific projects that need help are:
1. Compiler-RT (particularly sanitizers, fuzzer etc.) -- they break
quite often on glibc upgrades. Miraculously, right now 13.0.1
and 14.0.0 are clean right now but I'm pretty sure we'll see a new glibc release soon and they're going to require fixing again.
2. OpenMP -- there are many test regressions on every release, and 14.x
is particularly bad. I have no clue about this package, the test output
is usually cryptic and I don't really have the time to look into it. Honestly, at this point I would gladly have last rited it if it hadn't
had revdeps.
3. LLDB -- while it mostly works and I've managed to fix the worst of
it, I still haven't managed to get the test suite fully working. What's
even worse, the test runner just hangs at the very end and I have
no clue why or how to debug that.
Plus the generic stuff:
4. Testing LLVM 15.x periodically, bisecting, reporting bugs early.
I can help triaging and reporting the bugs but at least I'd need
somebody else to run the builds more often than I can.
5. Testing LLVM 14.x, 15.x on non-amd64 architectures (including x86
builds -- not all LLVM components are multilib) and reporting bugs. Unfortunately, this part may require actually providing patches.
6. Work on setting up and configuring a buildbot for Gentoo LLVM builds.
This is some effort and I don't have the time to learn how to do that.
You'll probably need to set up a local instance and figure out how to
set our builds before submitting anything upstream; in my experience
they aren't very responsive to buildbot changes, so ideally we need to
flesh out any problems early.
Yes, that's a lot of work. I can't do it all myself, I'm already doing
too much and this is having negative impact on my health. I really need
help with this.
Disclaimer: I've been doing some LLDB-related paid work in the past. However, this work wasn't Gentoo-related and if anything, it required me
to spend my CPU time on work and not testing LLVM for Gentoo.
On 2/10/22 15:36, Michał Górny wrote:
Hi,
As you may have noticed, I'm practically maintaining LLVM all by myself. This is a really tedious, time consuming and ungrateful task, and I'm pretty close to burnout. I'd really appreciate some help.
The problem with LLVM that it's a really huge, rapidly moving forward
(and breaking things) project. It needs frequent testing as regressions happen frequently, and we have a good chance of having somebody else fix
it if we report them early. At the same time, testing takes a lot of
time. While ccache is pretty much a must, it doesn't help much long
term as the code is changing frequently and invalidating the cache.
On top of this, there's almost-overlapping release process and Gentoo slotting that's working so-so at best. After I've pushed LLVM 13.0.1 final, I've had to immediately start testing 14.x and barely managed to
get some fixes in before rc1. Now 14.0.0 is expected soon,
simultaneously major changes are happening on the main branch
(i.e. 15.x) that also need testing and adjusting the ebuilds to.
I barely manage to keep up with amd64 multilib. Other arches are likely
to be broken. Some specific projects that need help are:
1. Compiler-RT (particularly sanitizers, fuzzer etc.) -- they break
quite often on glibc upgrades. Miraculously, right now 13.0.1
and 14.0.0 are clean right now but I'm pretty sure we'll see a new glibc release soon and they're going to require fixing again.
2. OpenMP -- there are many test regressions on every release, and 14.x
is particularly bad. I have no clue about this package, the test output
is usually cryptic and I don't really have the time to look into it. Honestly, at this point I would gladly have last rited it if it hadn't
had revdeps.
3. LLDB -- while it mostly works and I've managed to fix the worst ofYou've probly already thought of this but this is when strace comes to
it, I still haven't managed to get the test suite fully working. What's even worse, the test runner just hangs at the very end and I have
no clue why or how to debug that.
mind. Is it truly hanging in own code, or waiting on something to change
in the system that isn't happening?
Hi,
As you may have noticed, I'm practically maintaining LLVM all by myself.
This is a really tedious, time consuming and ungrateful task, and I'm
pretty close to burnout. I'd really appreciate some help.
The problem with LLVM that it's a really huge, rapidly moving forward
(and breaking things) project. It needs frequent testing as regressions happen frequently, and we have a good chance of having somebody else fix
it if we report them early. At the same time, testing takes a lot of
time. While ccache is pretty much a must, it doesn't help much long
term as the code is changing frequently and invalidating the cache.
On top of this, there's almost-overlapping release process and Gentoo slotting that's working so-so at best. After I've pushed LLVM 13.0.1
final, I've had to immediately start testing 14.x and barely managed to
get some fixes in before rc1. Now 14.0.0 is expected soon,
simultaneously major changes are happening on the main branch
(i.e. 15.x) that also need testing and adjusting the ebuilds to.
6. Work on setting up and configuring a buildbot for Gentoo LLVM builds.
This is some effort and I don't have the time to learn how to do that.
You'll probably need to set up a local instance and figure out how to
set our builds before submitting anything upstream; in my experience
they aren't very responsive to buildbot changes, so ideally we need to
flesh out any problems early.
Yes, that's a lot of work. I can't do it all myself, I'm already doing
too much and this is having negative impact on my health. I really need
help with this.
Are there similar programs where the infra work might fit?GSOC-worthy project?Not sure. To rephrase what was once said to me, this is summer of
*code*, not infra work.
On 11.2.2022 1.36, Michał Górny wrote:
Hi,
As you may have noticed, I'm practically maintaining LLVM all by myself. This is a really tedious, time consuming and ungrateful task, and I'm pretty close to burnout. I'd really appreciate some help.
The problem with LLVM that it's a really huge, rapidly moving forward
(and breaking things) project. It needs frequent testing as regressions happen frequently, and we have a good chance of having somebody else fix
it if we report them early. At the same time, testing takes a lot of
time. While ccache is pretty much a must, it doesn't help much long
term as the code is changing frequently and invalidating the cache.
On top of this, there's almost-overlapping release process and Gentoo slotting that's working so-so at best. After I've pushed LLVM 13.0.1 final, I've had to immediately start testing 14.x and barely managed to
get some fixes in before rc1. Now 14.0.0 is expected soon,
simultaneously major changes are happening on the main branch
(i.e. 15.x) that also need testing and adjusting the ebuilds to.
Would it help at all to not always support different _rc's and .9999s?
Or would that just bite "us" (as in Gentoo) back with a delay?
6. Work on setting up and configuring a buildbot for Gentoo LLVM builds. This is some effort and I don't have the time to learn how to do that. You'll probably need to set up a local instance and figure out how to
set our builds before submitting anything upstream; in my experience
they aren't very responsive to buildbot changes, so ideally we need to flesh out any problems early.
GSOC-worthy project?
Yes, that's a lot of work. I can't do it all myself, I'm already doing
too much and this is having negative impact on my health. I really need help with this.
I wonder if llvm and toolchain projects should join - not that there's probably anyone in toolchain interested/capable of doing llvm/clang currently. But they'd be the next with knowledge for at least simplest version bumps if you lay back a bit. Remember this is just a hobby -
even though your work is very much appreciated, not worth of wearing
yourself out over.
On Fri, Feb 11, 2022 at 09:11:51PM +0100, Michał Górny wrote:
Are there similar programs where the infra work might fit?GSOC-worthy project?Not sure. To rephrase what was once said to me, this is summer of
*code*, not infra work.
Outreachy? paid interns?
6. Work on setting up and configuring a buildbot for Gentoo LLVM builds.
This is some effort and I don't have the time to learn how to do that.
You'll probably need to set up a local instance and figure out how to
set our builds before submitting anything upstream; in my experience
they aren't very responsive to buildbot changes, so ideally we need to
flesh out any problems early.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 02:02:26 |
| Calls: | 12,098 |
| Calls today: | 6 |
| Files: | 15,003 |
| Messages: | 6,517,868 |