Update LDC2 support after LLVM 10 removal

[nikobockerman]

This pull-request adds new revisions for ldc 1.24.0, 1.25.1 and 1.26.0 ebuilds with support for newer llvm versions in their dependencies. The releases page of ldc2 mentions that 1.24.0 was the first version which added support for LLVM 11 and that 1.25.0 was the first version which supports also LLVM 12. After that this pull-request removes old ldc2 versions that only supported LLVM up to version 10 and removes LLVM 10 support from remaining ebuilds.

These changes are necessary now that LLVM 10 has been removed from Gentoo tree and current ebuilds can't be compiled anymore.

[nikobockerman]

I noticed couple problems still in the original commits. Force-pushed fixed versions of commits.

In order to avoid misunderstanding on the quality of these commits:
I have only used the 1.26.0-r1 ebuild myself after these changes. And I have only used it to build onedrive package. Onedrive package does appear to work fine when built with this 1.26.0-r1 with LLVM 12.

[mleise]

Thank you for your contribution Niko. I'm not really using Gentoo and DLang much these days and once ebuilds moved to ninja things started to fall behind as that required more than just updating some version numbers.

[nikobockerman]

Thank you for your contribution Niko. I'm not really using Gentoo and DLang much these days and once ebuilds moved to ninja things started to fall behind as that required more than just updating some version numbers.

No problem. I am using Gentoo but I have given up doing any actually development on dlang already quite some time ago. But I still use Onedrive and the onedrive package in this overlay is to my understanding the best linux client available. So I do want to keep it working. But I may also increase my efforts in finding a good alternative solution to replace Onedrive.

Can you tell if there was some technical reason for not having support for GCC after 9.3.0 in dlang-compilers.eclass? For me it would probably be easier to use GCC with d use flag with onedrive instead of ldc2 in case gcc could work.

[mleise]

Can you tell if there was some technical reason for not having support for GCC after 9.3.0 in dlang-compilers.eclass? For me it would probably be easier to use GCC with d use flag with onedrive instead of ldc2 in case gcc could work.

I can't remember if there was a particular reason other than GCC 10 being completely keyworded at the time. Since I pull the compilers in as a dependency of the DLang packages, something was complaining about stable ebuilds depending on unstable ones.
GCC also never moved on from DLang 2.076 which is quite an ancient front-end by today's standard. Several packages including OneDrive wont compile with that any longer. OneDrive currently requires DLANG_VERSION_RANGE="2.082-".

[nikobockerman]

Can you tell if there was some technical reason for not having support for GCC after 9.3.0 in dlang-compilers.eclass? For me it would probably be easier to use GCC with d use flag with onedrive instead of ldc2 in case gcc could work.

I can't remember if there was a particular reason other than GCC 10 being completely keyworded at the time. Since I pull the compilers in as a dependency of the DLang packages, something was complaining about stable ebuilds depending on unstable ones. GCC also never moved on from DLang 2.076 which is quite an ancient front-end by today's standard. Several packages including OneDrive wont compile with that any longer. OneDrive currently requires DLANG_VERSION_RANGE="2.082-".

Thanks for this info. I think I will then keep on using LDC2 until I switch from using Onedrive to some other storage provider.

[nikobockerman]

Is there still something you would like me to change in this PR? I have also followup changes to bump onedrive and ldc2 packages to newest upstream versions, but I'd rather get these commits approved and merged before adding more ebuilds that I need to adapt according to the feedback you give me.

I also noticed that issue #86 was opened recently which should be fixed with this PR.

[mleise]

No, all is good. I just have to update my old Gentoo system first. It's only gonna compile for a few more days, then I'll test and merge. :-)

[mleise]

I've merged your branch locally now and it looks good. I just need to make repoman full -d happy that complains about all the outdated stuff in the repository right now.

[mleise]

There is something I need you to fix. The keywords list in eclass/dlang-compilers.eclass cannot be less restrictive than the corresponding ebuilds. Where it says "2.094 amd64 ~arm ~arm64 ~ppc64 x86", the ldc2-1.24 ebuild (and the other versions) should read KEYWORDS="amd64 ~arm ~arm64 ~ppc64 x86".
Note: We can remove the keywording for architectures we tested on after 30 days of no issues with an ebuild. The LDC2 ebuilds have been in the repo for long enough.

P.S.: On the Gentoo git, we are required to git commit --signoff our commits. Without our name and email, the commits are rejected by the server. You can use an "interactive rebase" to go through the commits and follow this tutorial if Git doesn't have your name and email yet: https://docs.pi-hole.net/guides/github/how-to-signoff/

[nikobockerman]

Hi, sorry for the silence. My computer has been and still is in service. I will address you’re comments once I get it back. But I still don’t know when that will actually happen.

[mleise]

Looking good. Will check and merge on the weekend.

[nikobockerman]

I finally got my laptop back and after getting it up and running I was finally able to address your comments.

There is something I need you to fix. The keywords list in eclass/dlang-compilers.eclass cannot be less restrictive than the corresponding ebuilds. Where it says "2.094 amd64 ~arm ~arm64 ~ppc64 x86", the ldc2-1.24 ebuild (and the other versions) should read KEYWORDS="amd64 ~arm ~arm64 ~ppc64 x86". Note: We can remove the keywording for architectures we tested on after 30 days of no issues with an ebuild. The LDC2 ebuilds have been in the repo for long enough.

I changed the keywords list in eclass/dlang-compilers.eclass to match the keywords in ebuilds. Meaning that I marked the 1.25 and 1.26 as unstable for all arches. I thought that it's clearer to mark the ebuilds and eclass entries as stable separately later.

P.S.: On the Gentoo git, we are required to git commit --signoff our commits. Without our name and email, the commits are rejected by the server. You can use an "interactive rebase" to go through the commits and follow this tutorial if Git doesn't have your name and email yet: https://docs.pi-hole.net/guides/github/how-to-signoff/

I first read this as requirement to gpg sign the commits without rereading it. So I ended up finally resolving which email address to use for personal developments and to setup personal GPG key management.. And then at last minute after signing commits I reread your comment and realized that you only meant to use the --signoff option 😆
Oh well, got the GPG part finally done from my personal todo list..