@petersen If ghc is already in rhel, then we cannot add it to epel. But I think, ghc is shipped in rhel as part of module? If module, what stream is it?

@petersen If ghc is already in rhel, then we cannot add it to epel.

Well it is a so-called Buildroot-only package in RHEL8 and Centos8, so it is not actually shipped.
It is not shipped in Code Ready Builder (CRB repo).

But I think, ghc is shipped in rhel as part of module? If module, what stream is it?

It is not a module unfortunately (I am the RHEL maintainer).

But I am considering to make it a module in EPEL 8.

To get this unblocked, let's pull this from the CentOS Linux buildroot. That should allow Jens to bootstrap in EPEL and we can remove the binaries after the bootstrap is done.

@petersen is this the (only) one you need:

https://koji.mbox.centos.org/koji/buildinfo?buildID=2250

Or are there other deps/rpms?

@petersen is this the (only) one you need:
https://koji.mbox.centos.org/koji/buildinfo?buildID=2250

Thanks, @kevin, yes I think that should be sufficient.
(Sorry I forgot to check back here earlier...)
I think I can take care of the rest of the packages directly in Epel including ghc-rpm-macros.
Later I need to check about llvm versions (for aarch64).

(The reason I suggested RHEL buildroot is just that I understand the rest of the buildroot is based on RHEL, but the Centos package should work just as well - epel8 only has 4 archs currently anyway.)

Actually I realised if you could also tag in hscolour https://koji.mbox.centos.org/koji/buildinfo?buildID=2395 it would make the bootstrap considerably easier, thanks.

@petersen This should be done now.

Please verify and if any problem still persists, please reopen this ticket.

@petersen I am reopening the ticket as we need to remove the external repo which has ghc and hscolour that is added to epel8 buildroot once your work is done.

So, please let us know when your bootstrap is done so that we can remove the external repo.

Thanks.

Okay thanks - I finally saw this now.

I haven't forgotten but it is going to take some time because I need older versions of llvm built in EPEL8 for ghc aarch64.

Something seems wrong with s390x:

https://koji.fedoraproject.org/koji/taskinfo?taskID=45158703
https://koji.fedoraproject.org/koji/taskinfo?taskID=45161317

DEBUG util.py:600:  No matching package to install: 'ghc'
DEBUG util.py:600:  No matching package to install: 'ghc-binary-devel'
DEBUG util.py:600:  No matching package to install: 'ghc-bytestring-devel'
DEBUG util.py:600:  No matching package to install: 'ghc-compiler'
DEBUG util.py:600:  No matching package to install: 'ghc-containers-devel'
DEBUG util.py:600:  No matching package to install: 'ghc-directory-devel'
DEBUG util.py:600:  No matching package to install: 'ghc-pretty-devel'
DEBUG util.py:600:  No matching package to install: 'ghc-process-devel'
DEBUG util.py:600:  Not all dependencies satisfied

Is the external package also there for s390x?

You will need to exclude s390x... centos does not build for s390x. :(

Alright - I still don't understand why not just use the RHEL build, like the rest of EPEL does?

For example IBM Linux has actually contributed work recently upstream to llvm and ghc to improve the performance of ghc on s390x significantly.

Anyway if we can't use the RHEL build, then I would request we use a Fedora build instead.
I think: ghc-8.2.2-70.fc29 and hscolour-1.24.4-1.fc29 should be okay.

I don't want to exclude s390x just because it is not in Centos.

Well, we don't want to leak rhel binaries out.

That said, the way we were going to do this was with an external repo, which only the buildsystem should be able to access (like we do all the rhel content epel uses).

@jwboyer given that should we just use the rhel one?

That's fine.

Gentle ping: just when you have time to get to this

yes, it's always been on the radar, I just have been busy. ;)

In any case it should be there now, can you give it a try?

Could you please also add hscolour-1.24.2-2.el8

@kevin ^^ :)

Done. Sorry for the delay and missing that it was wanted.

Thanks, now I hit mysterious koji errors at the end of the builds:
https://koji.fedoraproject.org/koji/taskinfo?taskID=46791604

GenericError: hash changed for external rpm: ghc-base-devel-4.10.1.0-68.3.el8.x86_64@centos-ghc (9b343a7485c7ab272ff354305425f8e6 -> 4ce29c8780d980e9a367d9d24e5a7908)

GenericError: hash changed for external rpm: hscolour-1.24.2-2.el8.ppc64le@centos-ghc (d9f48f3cd4815a1496cc92e0e284a4bb -> 4ef333aa7085b9d262cf7122f0fce0a8)

Odd. Might be it just needed to be regenerated in koji since I changed it?

I've done that, can you try again now?

I did try resubmitting the above task, but it might have run before the newrepo finished. ;(

That doesn't seem to be it.

Maybe I should try bumping release, but the error suggests that is not the problem - I am not sure why Koji is complaining about the external repo after building... Was the centos build removed?

@kevin when you have time, could you please look more into this?

We think it might be caused by the db saving some metadata, I removed the external repo and added it again

$koji remove-external-repo centos-ghc --alltags
$koji remove-external-repo centos-ghc
$koji add-external-repo -t epel8-base -p 15 -m bare centos-ghc 'https://infrastructure.fedoraproject.org/repo/rhel/rhel8/ghc/$arch/'

@petersen Can you give it a try again?

I basically got the same Koji error again:

GenericError: hash changed for external rpm: ghc-base-devel-4.10.1.0-68.3.el8.x86_64@centos-ghc (9b343a7485c7ab272ff354305425f8e6 -> 4ce29c8780d980e9a367d9d24e5a7908)

https://koji.fedoraproject.org/koji/taskinfo?taskID=47480155

So, I think this is because we cannot re-use the same repo name here...

@mohanboddu can you do it again, but this time, remove centos-ghc and remove it from the epel8-build or whatever and then add a NEW repo called 'rhel-ghc' ?

I think koji is going to store the hash of the centos ones from the centos-ghc repo forever, so we need a new different repo for these.

So, I think this is because we cannot re-use the same repo name here...
@mohanboddu can you do it again, but this time, remove centos-ghc and remove it from the epel8-build or whatever and then add a NEW repo called 'rhel-ghc' ?
I think koji is going to store the hash of the centos ones from the centos-ghc repo forever, so we need a new different repo for these.

Changed.

$koji remove-external-repo centos-ghc --alltags
$koji remove-external-repo centos-ghc
$koji add-external-repo -t epel8-base -p 15 -m bare rhel-ghc 'https://infrastructure.fedoraproject.org/repo/rhel/rhel8/ghc/$arch/'

@petersen Can you try again?

Wow it's building, amazing 8-)

https://koji.fedoraproject.org/koji/taskinfo?taskID=47622727

I have built both ghc and hscolour now in epel8 (but not epel8-playground, is that bad?).

Wow, that was quite a marathon to get here!

Thank you, Everyone, for your help and assistance.

@mohanboddu, I think the external repo can be removed now.

Awesome. Sorry it was such a long road. ;)