Bug 426751 (ghc-X11)

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)

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.

True, adding that. There's still all the building problems to fix, though.

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.

IMHO we should follow the upstream naming and use "X11" not "x11".

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.

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.

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. :)

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

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.

(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.

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.

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.

Created attachment 315171 [details]
ghc-X11.spec.patch-2

Patch to fix the filelist generation.

The following spec is something like what I would expect for this package.

http://petersen.fedorapeople.org/ghc-X11/ghc-X11.spec

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.

Will review tomorrow

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.

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)

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. :)

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.

Yaakov, when you think you will have time to continue this package review or would you like me to post an updated package?

Ping? Btw, there's an updated X11 package out there, 1.4.4.

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

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.

Petersen-san is actually one of the sponsors.

(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?

(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.)

(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.

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.

(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.

> 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.

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.)

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.

> 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

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

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.

(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.

%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

Also there is a changelog entry missing for 1.4.5

(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.

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.

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.:)

(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.)

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.

(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.

Jens, if Yaakov is working on it, do you (or Till) want to take over the review? Thanks.

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.

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.

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

Taking over review for Michel based on comment 47.

Created attachment 333489 [details]
ghc-X11.spec-3.patch

Patch to latest cabal2spec-0.12.

I think I am basically happy with the package.

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.

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.

(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

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

Jens, don't forget, i need sponsoring.

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.

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

That should be

Branches: F-9 F-10
InitialCC: haskell-sig

cvs done

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.

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.

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

You mean a package change request here right? 
Not a new package?

Indeed I do. Case of copy/paste errors.

Package Change Request
=======================
Package Name: ghc-X11
New Branches: el6
Owners: mathstuf, petersen
InitialCC: haskell-sig

Git done (by process-git-requests).