Hi, I have been busy quietly building Haskell packages for F28 in the f28-ghc side repo.
Overall it is going quite well but I have one serious packaging issue which I think needs the packaging of the data-default-instannces-* subpackages to be reviewed asap, I believe. There is an upstream ghc bug related to this but I have not seen a patch yet.
https://bugzilla.redhat.com/show_bug.cgi?id=1539317 https://bugzilla.redhat.com/show_bug.cgi?id=1539318 https://bugzilla.redhat.com/show_bug.cgi?id=1539319
If people could help to review these 3 packages ASAP that would be really awesome and hopefully still give us a chance to finish the GHC 8.2 + LTS 10 Change work for F28 before the mass rebuild next week.
(For extra fun currently Haskell packages don't build in Rawhide due to "-z defs" now being set in redhat-rpm-config (though this change?). I have disabled this in latest ghc-rpm-macros in f28-ghc but I didn't backport it yet to Rawhide, since it is still under discussion.)
Please also note the coming packaging change that libHS*.so shared libs will now be installed in %_libdir (eg /usr/lib64/) and so we will need to run ldconfig install scripts (already in git master for most packages now). A coming cabal-rpm release will do this too.
Also I would like to encourage Hackage package maintainers to try to follow Stackage LTS versions rather than Hackage as far as possible, since this will pretty much guarantee build consistency across our package set. Cabal-rpm already does this today in F27+.
Thanks, and let me know if you have any comments, concerns or questions.
Jens
On Sat, Jan 27, 2018 at 9:42 PM, Jens-Ulrik Petersen petersen@redhat.com wrote:
Also I would like to encourage Hackage package maintainers to try to follow Stackage LTS versions rather than Hackage as far as possible, since this will pretty much guarantee build consistency across our package set. Cabal-rpm already does this today in F27+.
On this note, cabal-rpm update currently does not check versions and I may have inadvertised downgraded a packages from Hackage to Stackage LTS versions.
I spotted a few but there may well be more? (I will try to add a check in cabal-rpm later.)
I hope we can avoid having to add any epochs for f28.
Jens
On 27 January 2018 at 15:42, Jens-Ulrik Petersen petersen@redhat.com wrote:
Hi, I have been busy quietly building Haskell packages for F28 in the f28-ghc side repo.
Overall it is going quite well but I have one serious packaging issue which I think needs the packaging of the data-default-instannces-* subpackages to be reviewed asap, I believe. There is an upstream ghc bug related to this but I have not seen a patch yet.
https://bugzilla.redhat.com/show_bug.cgi?id=1539317 https://bugzilla.redhat.com/show_bug.cgi?id=1539318 https://bugzilla.redhat.com/show_bug.cgi?id=1539319
If people could help to review these 3 packages ASAP that would be really awesome and hopefully still give us a chance to finish the GHC 8.2 + LTS 10 Change work for F28 before the mass rebuild next week.
(For extra fun currently Haskell packages don't build in Rawhide due to "-z defs" now being set in redhat-rpm-config (though this change?). I have disabled this in latest ghc-rpm-macros in f28-ghc but I didn't backport it yet to Rawhide, since it is still under discussion.)
Please also note the coming packaging change that libHS*.so shared libs will now be installed in %_libdir (eg /usr/lib64/) and so we will need to run ldconfig install scripts (already in git master for most packages now). A coming cabal-rpm release will do this too.
Does this mean they no longer have unique names and try to follow standard shared library numbering (so we don't need to rebuild so much)? Also, I would point out this Change wrt running ldconfig: https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets
Also I would like to encourage Hackage package maintainers to try to follow Stackage LTS versions rather than Hackage as far as possible, since this will pretty much guarantee build consistency across our package set. Cabal-rpm already does this today in F27+.
Thanks, and let me know if you have any comments, concerns or questions.
Jens
Hi Elliot,
On Tue, Jan 30, 2018 at 12:10 AM, Elliott Sales de Andrade < quantum.analyst@gmail.com> wrote:
On 27 January 2018 at 15:42, Jens-Ulrik Petersen petersen@redhat.com wrote:
Overall it is going quite well but I have one serious packaging issue which I think needs the packaging of the data-default-instannces-* subpackages to be reviewed asap, I believe. There is an upstream ghc bug related to this but I have not seen a patch yet. If people could help to review these 3 packages ASAP that would be really awesome and hopefully still give us a chance to finish the GHC 8.2 + LTS 10 Change work for F28 before the mass rebuild next week.
Thanks so much for reviewing the data-default-instances-* packages.
It seems ghc-8.2 really doesn't like my subpackaging builds (maybe a good thing;). Not sure if all libraries built with subpackages linked into them are breaking ghc hashes, but it could be so.
I am going to try the proposed upstream workaround patch Phab:D4159 https://phabricator.haskell.org/D4159 on ghc-pkg for this problem. (See https://github.com/haskell/cabal/issues/4728 and < https://ghc.haskell.org/trac/ghc/ticket/14381%3E.)
Please also note the coming packaging change that libHS*.so shared libs
will now be installed in %_libdir (eg /usr/lib64/) and so we will need to run ldconfig install scripts (already in git master for most packages now). A coming cabal-rpm release will do this too.
Does this mean they no longer have unique names and try to follow standard shared library numbering (so we don't need to rebuild so much)?
Good question.
Not really I think: the file names are unchanged - ie they are still versioned on the package hash (key) and ghc version.
Also, I would point out this Change wrt running ldconfig: https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets
Thank you! - Wish I had noticed this earlier.
Okay I will revert my ldconfig packaging changes.
Cheers, Jens
On Tue, Jan 30, 2018 at 2:26 AM, Jens-Ulrik Petersen petersen@redhat.com wrote:
On Tue, Jan 30, 2018 at 12:10 AM, Elliott Sales de Andrade < quantum.analyst@gmail.com> wrote:
Also, I would point out this Change wrt running ldconfig:
https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets
Thank you! - Wish I had noticed this earlier.
Okay I will revert my ldconfig packaging changes.
Thanks again for the heads-up.
Since it is still in progress and I think the Packaging Guidelines have not been updated yet, we can probably wait with this a bit.
Jens
haskell@lists.fedoraproject.org
-
Elliott Sales de Andrade -
Jens-Ulrik Petersen