Re: [gentoo-dev] Gentoo LLVM project needs help!

2022-02-12 Thread Michał Górny
On Fri, 2022-02-11 at 00:36 +0100, Michał Górny wrote:
> 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.
> 

For the record, we have someone working on this now.

-- 
Best regards,
Michał Górny




Re: [gentoo-dev] Gentoo LLVM project needs help!

2022-02-11 Thread Benda Xu
Michał Górny  writes:

>> > 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?
>
> Not sure.  To rephrase what was once said to me, this is summer of
> *code*, not infra work.

If infra work means writing batch scripts to drive build bots, automate
tasks, generating reports and sending email notifications, it fits
summer of code.

Writing configurations is programming with descriptive DSLs.



signature.asc
Description: PGP signature


Re: [gentoo-dev] Gentoo LLVM project needs help!

2022-02-11 Thread Robin H. Johnson
On Fri, Feb 11, 2022 at 09:11:51PM +0100, Michał Górny wrote:
> > GSOC-worthy project?
> Not sure.  To rephrase what was once said to me, this is summer of
> *code*, not infra work.
Are there similar programs where the infra work might fit? 
Outreachy? paid interns?

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: PGP signature


Re: [gentoo-dev] Gentoo LLVM project needs help!

2022-02-11 Thread Michał Górny
On Fri, 2022-02-11 at 21:19 +0200, Joonas Niilola wrote:
> 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 .s?
> Or would that just bite "us" (as in Gentoo) back with a delay?

RCs are our chance to get upstream fixes into the release.  If we skip
them, it means we'll end up having to backport everything ourselves. 
It's a loss for us, and it's a loss for other people using LLVM.

Plus, filing bugs as "release blockers" has a certain psychological
effect.

> 
> > 
> > 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?

Not sure.  To rephrase what was once said to me, this is summer of
*code*, not infra work.

> 
> > 
> > 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.
> 
> 

I don't think this will help in any way -- just like having more people
on the project roster doesn't help.

-- 
Best regards,
Michał Górny




Re: [gentoo-dev] Gentoo LLVM project needs help!

2022-02-11 Thread Joonas Niilola
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 .s?
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.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] Gentoo LLVM project needs help!

2022-02-11 Thread Michał Górny
On Fri, 2022-02-11 at 09:40 -0800, A Schenck wrote:
> 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 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.
> You've probly already thought of this but this is when strace comes to
> mind. Is it truly hanging in own code, or waiting on something to change
> in the system that isn't happening?

I don't recall anymore, I haven't had time to try again in a while. 
AFAIR it was the test runner hanging after all tests are done.

-- 
Best regards,
Michał Górny




Re: [gentoo-dev] Gentoo LLVM project needs help!

2022-02-11 Thread A Schenck
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 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.
You've probly already thought of this but this is when strace comes to
mind. Is it truly hanging in own code, or waiting on something to change
in the system that isn't happening?
>
> 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.
>
-- 
Attached is my PGP public key.
Primary key fingerprint: C334 A85F 5B84 0061 2DF9 7310 6E37 4F22 EB0C 3D3A

If you have a PGP key (and a minute to spare)
please send it in reply to this email.

If you have no idea what PGP is, feel free
to ignore all this gobbledegook.



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Gentoo LLVM project needs help!

2022-02-10 Thread Michał Górny
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 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.

-- 
Best regards,
Michał Górny