Bug 426751 - (ghc-X11) Review Request: ghc-X11 - A Haskell binding to the X11 graphics library.
Review Request: ghc-X11 - A Haskell binding to the X11 graphics library.
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Jens Petersen
Fedora Extras Quality Assurance
http://hackage.haskell.org/cgi-bin/ha...
:
Depends On: 460304
Blocks: 426753
  Show dependency treegraph
 
Reported: 2007-12-25 15:15 EST by Yaakov Nemoy
Modified: 2010-10-10 00:19 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-09 00:02:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
petersen: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)
Changes to spec file for ghc682 (1014 bytes, patch)
2008-01-25 19:18 EST, Michel Alexandre Salim
no flags Details | Diff
ghc-X11.spec.patch-1 (5.05 KB, patch)
2008-08-22 05:09 EDT, Jens Petersen
no flags Details | Diff
ghc-X11.spec.patch-2 (1.36 KB, patch)
2008-08-27 23:24 EDT, Jens Petersen
no flags Details | Diff
ghc-X11.spec+macros (4.05 KB, text/plain)
2008-09-04 05:05 EDT, Jens Petersen
no flags Details
ghc-X11.spec+macros-revised (3.95 KB, text/plain)
2008-09-04 07:00 EDT, Jens Petersen
no flags Details
ghc-X11.spec (2.42 KB, text/plain)
2008-09-05 05:22 EDT, Jens Petersen
no flags Details
Patch from current ghc-X11.spec to the new templates. (2.73 KB, patch)
2009-02-15 04:37 EST, Conrad Meyer
no flags Details | Diff
ghc-X11.spec-3.patch (3.51 KB, patch)
2009-02-27 10:00 EST, Jens Petersen
no flags Details | Diff
ghc-X11.spec-4.patch (1.30 KB, patch)
2009-03-08 19:42 EDT, Jens Petersen
no flags Details | Diff

  None (edit)
Description Yaakov Nemoy 2007-12-25 15:15:07 EST
Spec URL: http://fedorapeople.org/~ynemoy/xmonad/x11.spec
SRPM URL: http://fedorapeople.org/~ynemoy/xmonad/ghc681-x11-1.4.1-1.fc8.src.rpm
Description: 
A Haskell binding to the X11 graphics library.

The binding is a direct translation of the C binding; for
documentation of these calls, refer to "The Xlib Programming
Manual", available online at <http://tronche.com/gui/x/xlib/>.

This library is needed for xmonad and xmonad-contrib, which are to follow.
Comment 1 Michel Alexandre Salim 2008-01-25 19:18:27 EST
Created attachment 293024 [details]
Changes to spec file for ghc682

Splendid, was looking forward to xmonad being packaged.

Firstly, several questions:
- spec file name mismatch: It's probably going to be annoying to have to keep
renaming the spec file every time ghc is version-bumped, but perhaps we can
compromise with naming the spec ghc-x11.spec ?
- is the (runtime) Requires: on libx11-devel really needed?

I changed the spec a bit for ghc682 (changes attached), but am running into
compilation problems on x86_64:

Graphics/X11/Xlib/Types.hsc:1:0:
    Failed to load interface for `Prelude':
      Perhaps you haven't installed the profiling libraries for package base?
      Use -v to see a list of the files searched for.
make[1]: *** [dist/build/Graphics/X11/Xlib/Types.p_o] Error 1
make[1]: *** Waiting for unfinished jobs....

Graphics/X11/Types.hsc:1:0:
    Failed to load interface for `Prelude':
      Perhaps you haven't installed the profiling libraries for package base?
      Use -v to see a list of the files searched for.
make[1]: *** [dist/build/Graphics/X11/Types.p_o] Error 1
make: *** [all] Error 1
+ :
+ runghc Setup build
Preprocessing library X11-1.4.1...
Building X11-1.4.1...

Graphics/X11/Types.hsc:794:7:
    Could not find module `Foreign.C.Types':
      Perhaps you haven't installed the profiling libraries for package base?
      Use -v to see a list of the files searched for.
error: Bad exit status from /home/builder/packages/tmp/rpm-tmp.62517 (%build)
Comment 2 Jason Tibbitts 2008-01-25 19:21:45 EST
I have to say, it sure would be nice to have those Haskell packaging guidelines.
 I know FPC didn't get to meet last week for whatever reason, but I don't recall
seeing an updated version for us to discuss.  I guess this ticket really should
be blocking F-GUIDELINES.
Comment 3 Michel Alexandre Salim 2008-01-25 19:44:02 EST
True, adding that. There's still all the building problems to fix, though.
Comment 4 Yaakov Nemoy 2008-01-25 21:06:30 EST
A)  The guidelines aren't done.  I put this up here to get more exposure
B)  The naming is an issue I have yet to resolve, re: guidelines
C)  The dependencies in GHC 6.8.2 vis-a-vis Cabal packages have changed.  You
cannot have two copies of the exact same version of a package installed in two
locations, and I have the sneaky suspicion that you have some package installed
twice.  You may want to try it in a fresh user to see if it compiles.
D)  I have yet to get to updating cabal-rpm and these packages for the new
version of GHC, not to mention, there are other issues blocking that for a
general purpose solution
E)  I would ideally like to split the base library packages from GHC into
multiple packages like this.  X11 is one of the standard included packages in
GHC, and the only reason I included this was because GHC 6.8.1 was out of date
in those regards.  Splitting GHC up will minimise this problem.  I wasn't
familiar with this issue at the time of submission
F) F_GUIDELINES works for me :).  I'm waiting to hear from Spot, unless someone
else wants to comment on my packaging guidelines.
Comment 5 Jens Petersen 2008-02-13 00:37:42 EST
IMHO we should follow the upstream naming and use "X11" not "x11".
Comment 6 Yaakov Nemoy 2008-07-03 06:16:04 EDT
SPEC: http://ynemoy.fedorapeople.org/repo/x11.spec
SRPM: http://ynemoy.fedorapeople.org/repo/ghc-x11-1.4.1-1.fc9.src.rpm

This new version is compliant with the Draft Guidelines.  Reviewing will find
problems with the draft that is currently under evaluation.
Comment 7 Jens Petersen 2008-07-04 04:41:27 EDT
The spec file must be named the same as the package, ie ghc-X11.

I don't agree about downcasing the name when upstream is clearly using X11.
Comment 8 Yaakov Nemoy 2008-07-04 05:25:50 EDT
I know, but it tends to lead to rIdiCuLOUS NaMinG schemes, if you ask me.  I've
commented in the guidelines talk page that there is a controversy over this. 
Comments have been added that Fedora does not yet have a clear policy on this
either (see: python vs. perl).  There are reasons for choosing both.

Since I've put together the work, and we are still a meritocracy, I've decided
to push my personal preference forward.  I hope you believe me when I say I am
not ignoring your preferences.  I've asked the Packaging Committee to comment on
this instead of me, and if they prefer mixed case naming schemes, I will be more
than happy to switch everything around.  

But please, don't turn this into a bikeshed discussion. :)
Comment 9 Jens Petersen 2008-07-07 00:52:43 EDT
Sorry but there is no ambiguity and the upstreaming naming of Haskell packages
is quite consistent and usable.  I urge you strongly to go along with the
upstream naming conventions.

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/X11
Comment 10 Yaakov Nemoy 2008-07-11 07:36:32 EDT
Please discuss this at the next meeting with the Packaging Committee.  I've
asked them to review the guidelines, and this is one thing I want *them* to
decide.  There is definitely an ambiguity in the Fedora standards, no matter how
many times you say there aren't.
Comment 11 Jens Petersen 2008-07-13 22:21:27 EDT
(In reply to comment #10)
> Please discuss this at the next meeting with the Packaging Committee.

Yes, I have no objections to discussing there, but at the end of the day of course
they know much less about Haskell packaging than the SIG does, so I expect they
would accept any recommendation we make either way.  I think it makes more sense
to discuss it first on fedora-haskell-list and get consensus there.

> I've asked them to review the guidelines, and this is one thing I want *them* to
> decide.

Hmm, but they are still in draft state and we were supposed to finish these package
reviews first but the guidelines would be ready...

> There is definitely an ambiguity in the Fedora standards, no matter how
> many times you say there aren't.

I don't remember saying anything about the Fedora name standards - I said that
naming of Haskell libraries tends to be pretty consistent (it is not like they
use different casing in different places (like lowercase tarball, uppercase
directory,
mixed case module name or whatever).  When there is consistent use of case in a
project
then that clearly indicates upstream thinks that that cased name is the correct name
and there is no good reason for us to change that.  X11 is such an example.

Exceptions may occur and are indeed allowed by the Fedora Guidelines as you state
and that is all ok, but it is not stop us from recommending Haskell libraries
should follow the upstream naming as far as possible.
Comment 12 Yaakov Nemoy 2008-07-14 06:22:33 EDT
Sure.  I plan on making this *very* clear to the Packaging Committee tomorrow.

There's always this amibguity of upstream vs. downstream.  I think it's best we
inform them, and then let the people who know best make the final decision.  I
will make sure they see this conversation.
Comment 13 Jens Petersen 2008-08-22 05:09:25 EDT
Created attachment 314784 [details]
ghc-X11.spec.patch-1

Patch to cleanup and simplify spec file.

Unfortunately the filelist generation does not work yet for me.
Comment 14 Jens Petersen 2008-08-27 23:24:58 EDT
Created attachment 315171 [details]
ghc-X11.spec.patch-2

Patch to fix the filelist generation.
Comment 15 Jens Petersen 2008-08-29 04:02:32 EDT
The following spec is something like what I would expect for this package.

http://petersen.fedorapeople.org/ghc-X11/ghc-X11.spec
Comment 16 Yaakov Nemoy 2008-09-02 23:13:40 EDT
SPEC http://ynemoy.fedorapeople.org/repo/ghc-X11.spec
SRPM http://ynemoy.fedorapeople.org/repo/ghc-X11-1.4.2-1.fc9.src.rpm

This is an example of a library only package with links to C libraries.

The macros needed are currently available on the wiki and need to be installed
manually for now.  There is a bug to have them included in ghc directly.  I
will add it to the blockers.  Don't forget to --copyin them to mock, and then
use --no-clean to do the build.
Comment 17 Michel Alexandre Salim 2008-09-03 23:19:52 EDT
Will review tomorrow
Comment 18 Jens Petersen 2008-09-04 05:00:48 EDT
As I already mentioned in comment 14 and elsewhere, the ghc_gen_filelists macro is broken
and needs to be fixed (even though the macros were already accepted by the packaging committee;).

At the same time I think it might be worth doing some slight simplication of the macros.
Comment 19 Jens Petersen 2008-09-04 05:05:08 EDT
Created attachment 315727 [details]
ghc-X11.spec+macros

eg this spec file with embedded macros from https://fedoraproject.org/wiki/PackagingDrafts/Haskell/GHCMacroDefs gives:

+ pushd /builddir/build/BUILDROOT/ghc-X11-1.4.2-1.fc10.i386
+ echo '%defattr(-,root,root,-)'
+ find ./usr/lib/ghc-6.8.3/X11-1.4.2 '(' -name '*_p.a' -o -name '*.p_hi' ')'
+ sed 's/^.//'
+ echo '%defattr(-,root,root,-)'
+ find ./usr/lib/ghc-6.8.3/X11-1.4.2 -type d
+ sed 's/^./%dir /'
+ find ./usr/lib/ghc-6.8.3/X11-1.4.2 '!' '(' -type d -o -name '*_p.a' -o -name '*.p_hi' ')'
+ sed 's/^.//'
+ sed 's,^/,%exclude /,' '%{ghc_tar_dir}/ghc-X11-files.prof'
sed: can't read %{ghc_tar_dir}/ghc-X11-files.prof: No such file or directory
RPM build error:
Error: /var/tmp/rpm-tmp.zA1wEN の不正な終了ステータス (%install)
    /var/tmp/rpm-tmp.zA1wEN の不正な終了ステータス (%install)
Comment 20 Jens Petersen 2008-09-04 07:00:28 EDT
Created attachment 315734 [details]
ghc-X11.spec+macros-revised

I would really like to suggest that we do the macros and packaging in this way.
This is a lightly cleaned up and simplified set of packages, which I would be
happy to go ahead with. :)
Comment 21 Jens Petersen 2008-09-05 05:22:00 EDT
Created attachment 315852 [details]
ghc-X11.spec

Here is a slightly revised spec file without the macros embedded using the latest macros I attached to bug 460304 - tested and builds on rawhide.
Comment 22 Jens Petersen 2008-11-19 01:24:44 EST
Yaakov, when you think you will have time to continue this package review or would you like me to post an updated package?
Comment 23 Thomas Moschny 2008-11-27 03:01:37 EST
Ping? Btw, there's an updated X11 package out there, 1.4.4.
Comment 24 Jens Petersen 2008-11-28 01:11:00 EST
I hear Yaakov is busy with his studies, so let me take over the submission:

Spec: http://petersen.fedorapeople.org/ghc-X11/ghc-X11.spec
SRPM: http://petersen.fedorapeople.org/ghc-X11/ghc-X11-1.4.4-1.fc10.src.rpm (requires f11 rawhide to build)

Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=955786
Comment 25 Till Maas 2008-12-10 06:18:44 EST
1.4.5 is out now. Jens, do you also need to be sponsored? Otherwise you should remove FE-NEEDSPONSOR from the blocked bugs list. If you do not need to be sponsored, I will try to review this, soon.
Comment 26 Mamoru TASAKA 2008-12-10 06:52:58 EST
Petersen-san is actually one of the sponsors.
Comment 27 Till Maas 2008-12-10 08:00:23 EST
(In reply to comment #26)
> Petersen-san is actually one of the sponsors.

Ok, it seems to be safe to remove the FE_NEEDSPONSOR, then. I also noticed that   Michel is already assigned to this, are you planning to review this, soon? Are there any plans to get this also into F10?
Comment 28 Jens Petersen 2008-12-11 20:38:08 EST
(Needsponsor was for Yaakov, but he seems to be too busy for fedora at the moment...)

> Michel is already assigned to this, are you planning to review this, soon?

Yeah Michel has not commented since Sept.  Michel, if you are not available then I think we should let Till take over the review. :)

> Are there any plans to get this also into F10?

Sure, why not. :)


Spec: http://petersen.fedorapeople.org/ghc-X11/ghc-X11.spec
SRPM: http://petersen.fedorapeople.org/ghc-X11/ghc-X11-1.4.5-1.fc10.src.rpm

This needs rawhide ghc to build.

(I am kind of hovering on whether the build_doc and build_prof build switches are overkill or not for general libs: sometimes they are useful - they do make the spec file a little more complicated but make clear which parts are for docs and profiling.  The current templates I made have them though.)
Comment 29 Till Maas 2008-12-15 18:35:20 EST
(In reply to comment #28)

> (I am kind of hovering on whether the build_doc and build_prof build switches
> are overkill or not for general libs: sometimes they are useful - they do make
> the spec file a little more complicated but make clear which parts are for docs
> and profiling.  The current templates I made have them though.)

Imho the prof packages do not hurt, but in case the documentation is not big, there is no need to add it to a seperate doc subpackage. Nevertheless I would prefer to use %bcond_without or %bcond_with macros to make it possible to easily define whether or not to build the subpackages on the rpmbuild commandline.

Here is a patch:
http://till.fedorapeople.org/ghx-X11-buildcond.patch

Btw. is there any need to require a certain version of ghc except for making sure that the pkg_libdir exists, i.e. would it be possible to just use a Requires: ghc, given that one can use some spec-fu to automatically build the pkg_libdir path and Requires from the ghc version that was used to build the rpm? Iirc it was only required in previous Fedora releases, to allow parallel installation of different ghc version, which is not supported anymore.
Comment 30 Bryan O'Sullivan 2008-12-15 19:00:38 EST
Actually, the prof packages should be seen as mandatory, not optional, so there is no reason that there should be a flag to control whether or not they are built.

The reason for this is that if a library is built without profiling, then nothing that depends on it can ever be built *with* profiling enabled. As a result, we require that all libraries be built both in profiling and no-profiling flavours. The issue of whether a -prof RPM is installed on a system is a separate one.
Comment 31 Jens Petersen 2008-12-15 20:45:31 EST
(In reply to comment #30)
> Actually, the prof packages should be seen as mandatory, not optional, so there
> is no reason that there should be a flag to control whether or not they are
> built.

Bryan is probably right, we can probably drop the prof flag - at least I can't think of any cases profiling has blocked building a package: my reason for having it is really more to save time for debugging builds sometimes (either build time or time downloading ghc-prof), but for small libraries it probably doesn't make sense so I think it is safe to remove from the default template and then big libraries (like gtk2hs) might still have a prof build flag but that would be up to the maintainer.

bcond looks better though: so I will use that for docs and other places/packages.
Comment 32 Jens Petersen 2008-12-15 23:17:38 EST
> but in case the documentation is not big,
> there is no need to add it to a separate doc subpackage.

Documentation is not actually being subpackaged here: the flag would just be for whether the docs get build or not: generally no reason not to do that, though occasionally docs building can break with certain versions of haddock say.

> Here is a patch:
> http://till.fedorapeople.org/ghx-X11-buildcond.patch

Thanks - will try to fold that into the templates.

> Btw. is there any need to require a certain version of ghc except for making
> sure that the pkg_libdir exists, i.e. would it be possible to just use a
> Requires: ghc, given that one can use some spec-fu to automatically build the
> pkg_libdir path and Requires from the ghc version that was used to build the
> rpm? Iirc it was only required in previous Fedora releases, to allow parallel
> installation of different ghc version, which is not supported anymore.

Good question.  I see what you're saying, but since ghc libraries change ABI with every minor version I think it is useful to document what version a library has been built with - though I suppose one can also look at the binary package metadata for that.  Let's think a little more about it.
Comment 33 Jens Petersen 2008-12-17 00:32:29 EST
Thanks Till - I changed ghc-zlib to use bcond and %(ghc --numeric-version) so far and will do same for ghc-gtk2hs.
(I think we should move ghc_version into macros.ghc then.)
Comment 34 Yaakov Nemoy 2008-12-17 01:18:27 EST
Pong,

Sorry for the away-ness.  I plan on picking this up in a few days, but...

I'm having really really weird problems getting Xmonad to work in Gnome, so i'm going to be trying to resolve that first.
Comment 35 Jens Petersen 2008-12-17 01:21:18 EST
> Btw. is there any need to require a certain version of ghc except for making
> sure that the pkg_libdir exists, i.e. would it be possible to just use a
> Requires: ghc, given that one can use some spec-fu to automatically build the
> pkg_libdir path and Requires from the ghc version that was used to build the
> rpm? Iirc it was only required in previous Fedora releases, to allow parallel
> installation of different ghc version, which is not supported anymore.

Actually this is breaking in mock/koji for me, but perhaps I am not doing it right.

http://koji.fedoraproject.org/koji/getfile?taskID=1002891&name=srpm.log

Till, could you have look or do you know another package that does something similar?

http://cvs.fedoraproject.org/viewvc/devel/ghc-zlib/ghc-zlib.spec
Comment 36 Till Maas 2008-12-17 10:22:30 EST
I first looked at how python packages manage to get their python(ABI) = 2.6 dependency. For this rpm has it's own automatic dependency generator. Here is one for ghc that allows to skip the Requires: ghc and Requires: ghc-prof dependencies in the spec, because they will be added automatically.

http://till.fedorapeople.org/ghcdeps.sh

I am not yet sure, what the impact of
%define _use_internal_dependency_generator 0
is for ghc packages. I guess this can lead to problems in case there are also other files included that need the automatic dependency generator, e.g. python scripts. Maybe the script needs to be adjusted to also call the internal dependency generator somehow, but this should probably take care of this in the ghcdep.sh script:

/usr/lib/rpm/rpmdeps --requires $REPLY

For the post, postun, preun dependencies, the only way I found is this (inspired by kmodtool):

http://till.fedorapeople.org/ghc-script-requires.sh
Instead of the Requires(post) etc, this can be used in the spec, if Source2: points to the script:

%{expand:%(/bin/bash %SOURCE2 post preun postun)}

With this patch to the spec I was then able to build ghc-zlib with proper requires afaics:
http://till.fedorapeople.org/ghc-zlib-automatic-requires.patch

Build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1003560
Comment 37 Jens Petersen 2008-12-22 00:22:54 EST
Ok thank you very much that looks very useful: it is quite a bit change to our packaging so I think I would like to leave the automatic dependency scripts for the next update of the guidelines after this one, if that is ok - that will give us a bit more time to test and play with them.  Presumbly ghc should own those scripts?

> I am not yet sure, what the impact of
> %define _use_internal_dependency_generator 0
> is for ghc packages.

Naive question: what would be the consequence of leaving _use_internal_dependency_generator turned on?  Turning off also disables all C library dependency checking?  Anyway from what you say we can tweak the scripts to do the write thing.
Comment 38 Till Maas 2008-12-22 06:51:30 EST
(In reply to comment #37)
> Ok thank you very much that looks very useful: it is quite a bit change to our
> packaging so I think I would like to leave the automatic dependency scripts for
> the next update of the guidelines after this one, if that is ok - that will
> give us a bit more time to test and play with them.  

Sure.

> Presumbly ghc should own those scripts?

Yes or maybe better in a separate small package that is required by ghc to make it easier to update them.

> > I am not yet sure, what the impact of
> > %define _use_internal_dependency_generator 0
> > is for ghc packages.
> 
> Naive question: what would be the consequence of leaving
> _use_internal_dependency_generator turned on?  Turning off also disables all C
> library dependency checking?  Anyway from what you say we can tweak the scripts
> to do the write thing.

If it is turned on, then __find_requires is not used.
According to this
https://fedoraproject.org/wiki/PackagingDrafts/FilteringAutomaticDependencies
instead of rpmdeps maybe /usr/lib/rpm/find-requires should be used. I will ask about this on fedora-devel.
Comment 39 Till Maas 2008-12-23 15:18:26 EST
%preun and %post use undefined macros:
%ghc_postinst_script instead of %ghc_register_pkg

%ghc_preun_script instead of
if [ "$1" -eq 0 ] ; then
  %ghc_unregister_pkg
fi
Comment 40 Till Maas 2008-12-23 15:22:39 EST
Also there is a changelog entry missing for 1.4.5
Comment 41 Jens Petersen 2009-01-05 21:07:03 EST
(In reply to comment #38)
> Yes or maybe better in a separate small package that is required by ghc to make
> it easier to update them.

Yes good point - I have been thinking to move all packaging stuff to a separate package, say "haskell-packaging".

> If it is turned on, then __find_requires is not used. According to this
> https://fedoraproject.org/wiki/PackagingDrafts/FilteringAutomaticDependencies
> instead of rpmdeps maybe /usr/lib/rpm/find-requires should be used. I will ask
> about this on fedora-devel.

Ok thank you for all your explanations on this. :-)

Additionally we would really like to automate the generation of C library buildrequires but that probably needs a bit more work with parsing cabal files.
Comment 42 Yaakov Nemoy 2009-01-18 16:17:30 EST
Ok, finally, and i should be alot more on top of this in the far reaching future (i think), i have some packages.

SPEC:http://ynemoy.fedorapeople.org/review/ghc-X11.spec
SRPM:http://ynemoy.fedorapeople.org/review/ghc-X11-1.4.5-1.fc11.src.rpm

This is more or less pretty much based on the latest template. It's being managed by fedora-devshell, which means getting hotfixes done should be fast. 

Note: AFAIK, we don't have the macros needed in F10 right now, so this only builds in rawhide.  The SRPM is output from mock using rawhide. Once the macros are in F10, supporting it there should be trivial.

I submit this for review.
Comment 43 Jens Petersen 2009-01-21 03:19:20 EST
Thanks Yaakov, will try to take a look at it soon.

(The bug will soon have its first birthday so hope it can be resolved soon.:)
Comment 44 Jens Petersen 2009-01-21 03:24:16 EST
(In reply to comment #42)
> Note: AFAIK, we don't have the macros needed in F10 right now, so this only
> builds in rawhide.  The SRPM is output from mock using rawhide. Once the macros
> are in F10, supporting it there should be trivial.

Ok, finally I built ghc-6.10.1-7.fc10 for F10.

http://koji.fedoraproject.org/koji/buildinfo?buildID=79616

Unfortunately still need to update haddock and gtk2hs before it can be pushed to F10 updates.  (With the number libs going in fedora now I suspect it is going to get harder and less common to backport ghc going forward but let us see.)
Comment 45 Yaakov Nemoy 2009-01-21 11:06:53 EST
Glad to know it builds for you too. When will the review be done? Even if we don't backport all these packages, this can still go in rawhide.

Also, i see you made some changes to the templates. I'm gonna have to actually update the package once the templates hit rawhide.
Comment 46 Jens Petersen 2009-01-21 19:26:01 EST
(In reply to comment #45)
> Even if we don't backport all these packages, this can still go in rawhide.

Well assuming ghc-6.10.1 reaches f10-updates then no problem to create an F-10 branch for ghc-X11.

> Also, i see you made some changes to the templates. I'm gonna have to actually
> update the package once the templates hit rawhide.

Better to do that now IMHO: perhaps I should have left cabal2spec in ghc longer but I wanted the review package to be installable - I would appreciate more testing while we are proposing the revision to FPC.  I am not anticapating any major changes until we add the ghc requires deps scripting for rpm.
Comment 47 Michel Alexandre Salim 2009-01-25 12:54:25 EST
Jens, if Yaakov is working on it, do you (or Till) want to take over the review? Thanks.
Comment 48 Jens Petersen 2009-01-31 05:51:05 EST
Yaakov if you want to update/merge in the latest changes from
http://petersen.fedorapeople.org/cabal2spec/
I am happy to take over the review.
Comment 49 Conrad Meyer 2009-02-15 04:37:53 EST
Created attachment 331958 [details]
Patch from current ghc-X11.spec to the new templates.

I ported ghc-X11.spec to the new templates, here's the diff.
Comment 50 Yaakov Nemoy 2009-02-23 20:40:29 EST
here's an update to match the latest guidelines proposal, using cabal2spec 0.7

SRPM: http://ynemoy.fedorapeople.org/review/ghc-X11-1.4.5-2.fc10.src.rpm
SPEC: http://ynemoy.fedorapeople.org/review/ghc-X11.spec
Comment 51 Jens Petersen 2009-02-27 09:46:23 EST
Taking over review for Michel based on comment 47.
Comment 52 Jens Petersen 2009-02-27 10:00:18 EST
Created attachment 333489 [details]
ghc-X11.spec-3.patch

Patch to latest cabal2spec-0.12.

I think I am basically happy with the package.
Comment 53 Jens Petersen 2009-02-27 10:31:17 EST
One strange I think I did notice is that it seems like the binary redistribution clause is missing from the "BSD3" License - we should probably ask fedora-legal and upstream about it.
Comment 54 Jens Petersen 2009-02-28 06:53:30 EST
http://git.fedorahosted.org/git/spin-kickstarts.git

Looking at the license again the missing clause is just:

"Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution."

so I don't think there is a problem, but I just sent a mail to fedora-legal anyway to confirm.
Comment 55 Jens Petersen 2009-02-28 06:54:59 EST
(In reply to comment #54)
> http://git.fedorahosted.org/git/spin-kickstarts.git

Oops, that should have been: http://darcs.haskell.org/packages/X11/LICENSE
Comment 56 Yaakov Nemoy 2009-03-01 22:22:06 EST
Update using said patch with one modification, i like the Summary as it was before.

SPEC: http://ynemoy.fedorapeople.org/review/ghc-X11.spec
SRPM: http://ynemoy.fedorapeople.org/review/ghc-X11-1.4.5-3.fc10.src.rpm
Comment 57 Yaakov Nemoy 2009-03-02 19:05:45 EST
Jens, don't forget, i need sponsoring.
Comment 58 Jens Petersen 2009-03-03 06:26:04 EST
Okay according to spot this is okay as BSD:
https://www.redhat.com/archives/fedora-legal-list/2009-March/msg00002.html

I am sponsoring Yaakov.


Here is the review:

 +:ok, =:needs attention, -:needs fixing,  NA: not applicable

MUST Items:
[+] MUST: rpmlint output

clean

[+] MUST: Package Naming Guidelines
[+] MUST: spec file name must match base package %{name}
[+] MUST: Packaging Guidelines.
[+] MUST: Licensing Guidelines
[+] MUST: License field in the package spec file must match actual license.
[+] MUST: include license files in %doc if available in source
[+] MUST: The spec file must be written in American English and be legible.
[+] MUST: source md5sum matches upstream release

73a4ba56b8cef69ce3659ab452e4530b  X11-1.4.5.tar.gz

[+] MUST: must successfully compile and build into binary rpms on one main arch
[+] MUST: if necessary use ExcludeArch for other archs
[+] MUST: All build dependencies must be listed in BuildRequires
[NA] MUST: use %find_lang macro for .po translations
[NA] MUST: packages which store shared library files in the dynamic linker's default paths, must call ldconfig in %post and %postun.
[+] MUST: A package must own all directories that it creates.
[+] MUST: A package must not contain any duplicate files in the %files listing.
[+] MUST: Permissions on files must be set properly.
[+] MUST: Each package must have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
[+] MUST: Each package must consistently use macros, as described in the macros section of Packaging Guidelines.
[+] MUST: The package must contain code, or permissable content. This is described in detail in the code vs. content section of Packaging Guidelines.
[+] MUST: Large documentation files should go in a doc subpackage.
[+] MUST: If a package includes something as %doc, it must not affect the runtime of the application.
[+] MUST: Header files must be in a -devel package.
[NA] MUST: Static libraries must be in a -static package.
[NA] MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability).
[NA] MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package.
[NA] MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency
[+] MUST: Packages must NOT contain any .la libtool archives, these should be removed in the spec.
[NA] MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section.
[+] MUST: Packages must not own files or directories already owned by other packages.
[+] MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
[+] MUST: All filenames in rpm packages must be valid UTF-8.

SHOULD Items:
[+] SHOULD: The reviewer should test that the package builds in mock.
[+] SHOULD: The package should compile and build into binary rpms on all supported architectures.

http://koji.fedoraproject.org/koji/taskinfo?taskID=1216598

[+] SHOULD: The reviewer should test that the package functions as described.
[+] SHOULD: If scriptlets are used, those scriptlets must be sane.


This package is APPROVED for inclusion in Fedora.


Thanks for your patience as this was also one of the early packages
used as a testcase during revising the Haskell Packaging Guidelines.
Comment 59 Yaakov Nemoy 2009-03-03 20:37:53 EST
New Package CVS Request
=======================
Package Name: ghc-X11
Short Description: A Haskell binding to the X11 graphics library.
Owners: ynemoy, petersen
Branches: F-9, F-10, F-11, devel
InitialCC: ynemoy
Comment 60 Jens Petersen 2009-03-03 20:46:39 EST
That should be

Branches: F-9 F-10
InitialCC: haskell-sig
Comment 61 Jens Petersen 2009-03-04 23:33:33 EST
cvs done
Comment 62 Jens Petersen 2009-03-08 19:42:07 EDT
Created attachment 334452 [details]
ghc-X11.spec-4.patch

My bad for not checking more carefully, but these hunks got dropped from ghc-X11.spec-3.patch.

The only crucial one is the second one: base should not provide devel and fixing the arch list.

You already commented on the Summary change, but just to explain one of the reasons for changing it
is that Summary should be kept simple for PkgKit, but I leave it to your final discretion.

Please close this bug NEXTRELEASE once the final package has been built also for i586.
Comment 63 Yaakov Nemoy 2009-03-09 00:02:25 EDT
re: base and devel, should be fixed
re: summary - i wasn't aware of the use case, fixed
re: archs, somehow missed applying that in patch-3, applied now and built
closing bug now.
Comment 64 Ben Boeckel 2010-10-07 00:18:03 EDT
New Package CVS Request
=======================
Package Name: ghc-X11
Short Description: A Haskell binding to the X11 graphics library.
Owners: mathstuf, petersen
Branches: el6
InitialCC: haskell-sig
Comment 65 Kevin Fenzi 2010-10-08 16:25:03 EDT
You mean a package change request here right? 
Not a new package?
Comment 66 Ben Boeckel 2010-10-08 17:33:08 EDT
Indeed I do. Case of copy/paste errors.

Package Change Request
=======================
Package Name: ghc-X11
New Branches: el6
Owners: mathstuf, petersen
InitialCC: haskell-sig
Comment 67 Kevin Fenzi 2010-10-10 00:19:02 EDT
Git done (by process-git-requests).

Note You need to log in before you can comment on or make changes to this bug.