ghc82 and packages and f28 building update

[Jens-Ulrik Petersen]

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

[Jens-Ulrik Petersen]

On Sat, Jan 27, 2018 at 9:42 PM, Jens-Ulrik Petersen <petersen(a)redhat.com&gt;
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

[Elliott Sales de Andrade]

On 27 January 2018 at 15:42, Jens-Ulrik Petersen <petersen(a)redhat.com&gt;
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
>
>  
-- 
Elliott

[Jens-Ulrik Petersen]

Hi Elliot,

On Tue, Jan 30, 2018 at 12:10 AM, Elliott Sales de Andrade <
quantum.analyst(a)gmail.com&gt; wrote:

>  On 27 January 2018 at 15:42, Jens-Ulrik Petersen
> <petersen(a)redhat.com&gt;
>  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>.)

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

[Jens-Ulrik Petersen]

On Tue, Jan 30, 2018 at 2:26 AM, Jens-Ulrik Petersen <petersen(a)redhat.com&gt;
wrote:

>  On Tue, Jan 30, 2018 at 12:10 AM, Elliott Sales de Andrade <
>  quantum.analyst(a)gmail.com&gt; 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