Re: [gentoo-dev] Gentoo LLVM project needs help!
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
[gentoo-dev] Last rites: sys-apps/smc-sum-driver
# Conrad Kostecki (2022-02-11) # Mask for last-rite, as source for kernel modules # is now provided directly with sys-apps/smc-sum. # Removal after 2022-02-24. sys-apps/smc-sum-driver
Re: [gentoo-dev] Gentoo LLVM project needs help!
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!
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
Re: [gentoo-dev] Gentoo LLVM project needs help!
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
[gentoo-dev] Last rites: x11-misc/gtk2fontsel
# Jonas Stein (2022-02-11) # Blocks gtk2 removal, which is EOL # Removal after 2022-04-01. Bug #833145. x11-misc/gtk2fontsel -- Best, Jonas
Re: [gentoo-dev] Gentoo LLVM project needs help!
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
[gentoo-dev] Last rites: x11-misc/i855crt
# Jonas Stein (2022-02-11) # Not usable anymore # Removal after 2022-06-01. Bug #833144. x11-misc/i855crt -- Best, Jonas
Re: [gentoo-dev] Gentoo LLVM project needs help!
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
