From bugzilla at redhat.com Fri Aug 8 17:51:44 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 8 Aug 2008 13:51:44 -0400 Subject: [Fedora-haskell-list] [Bug 250767] ghc-gtk2hs won't install with only 256MB RAM In-Reply-To: References: Message-ID: <200808081751.m78HpiHL009033@bz-web2.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=250767 --- Comment #9 from Gregory D. Weber 2008-08-08 13:51:43 EDT --- (In reply to comment #8) > (In reply to comment #6) ... > > > # time make install > > -- completed in 41 seconds > > Does that install .o files too? > ... Yes, it did: [root at squirrel gtk2hs]# pwd /opt/lib/gtk2hs [root at squirrel gtk2hs]# ls cairo.package.conf HSglade.o include libHSsourceview.a gconf.package.conf HSglib.o libHScairo.a libHSsvgcairo.a glade.package.conf HSgtkglext.o libHSgconf.a soegtk.package.conf glib.package.conf HSgtk.o libHSglade.a sourceview.package.conf gtkglext.package.conf HSsoegtk.o libHSglib.a svgcairo.package.conf gtk.package.conf HSsourceview.o libHSgtk.a HScairo.o HSsvgcairo.o libHSgtkglext.a HSgconf.o imports libHSsoegtk.a -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bos at serpentine.com Sun Aug 10 22:14:52 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sun, 10 Aug 2008 15:14:52 -0700 Subject: [Fedora-haskell-list] Not getting far with GHC 6.8.3 docs Message-ID: I haven't figured out yet why the docs aren't being installed with the current GHC 6.8.3 spec file in rawhide. They're built without problem. Since I'm finishing off a book and about to move house, this isn't something I'll have much time for soon. If someone else can take a look, that would be great. From loupgaroublond at gmail.com Wed Aug 13 15:01:16 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 13 Aug 2008 17:01:16 +0200 Subject: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 Message-ID: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> Hi Lists, I've revised the guidelines once again to cover the issues brought up when I brought them before the packaging committee. As follows is a list of the issues I've heard, and how they are fixed. * %buildsubdir is not a common way of doing things ** we need this macro in the install phase to get at the working dir we used to compile the package. This was only needed by the rather scary looking file seeking code, so I put it into a macro that is called by another macro, and hid it from public view. The user should not need this in the spec file anymore. * this looks scary, use macros ** done, the guidelines include them * how do runtime requirements work, vis a vis build time, etc... ** GHC apparently uses static linking for haskell libraries and dynamic for C libraries. *** This is quite similar to OCaml ** all the dynamic links to C libraries can be automagically detected by RPM's wonderful automagic. ** the -devel packages still need to be put in by hand in the BuildRequires ** most packages only need their dependency libraries at build time. ** Some packages, notably xmonad, do code generation and require the dependencies at run time. *** the packager is responsible for tracking this bit * this file detection stuff is scary ** I've put it into a series of macros and documented it * this register stuff looks kinky ** for starters, it's needed so the compiler knows where to look for certain packages ** it's been converted to a bunch of macros I also think that if we can make this any more simple, then the only thing that cabal-rpm really really needs to do is detect if a package is a library, binary, or both, and then fill in some of the dependencies automatically, whcih it's not clever enough yet to do properly anyways. We may just need to create a few rpm templates, and be done with it. Anyways, I present the guidelines once more for review. I will try to comandeer the help of the people in the SIG to start putting together a repo of packages using these macros. The deadeline for the F10 feature is coming up soon, and I want to have it in a relatively stable shape, even though we have time to fine tune the details later. -Yaakov From bos at serpentine.com Wed Aug 13 15:15:43 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed, 13 Aug 2008 08:15:43 -0700 Subject: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> Message-ID: On Wed, Aug 13, 2008 at 8:01 AM, Yaakov Nemoy wrote: > I've revised the guidelines once again to cover the issues brought up > when I brought them before the packaging committee. Thanks, Yaakov. > * how do runtime requirements work, vis a vis build time, etc... > ** GHC apparently uses static linking for haskell libraries and > dynamic for C libraries. > *** This is quite similar to OCaml Right. At some point in the next year or so, GHC should be able to generate shared libraries, so the AutoReqProv mechanism will then work. > * this file detection stuff is scary > ** I've put it into a series of macros and documented it The reason that the file detection code is complicated is that GHC emits a number of .o and .a files. These change depending on the compilation options used. The files follow a consistent naming convention, so it is far easier and more reliable to gather them up using a find script than to enumerate all of the possibilities by hand. I'm pleased with the current state of the guidelines. Thanks for working on this! From petersen at redhat.com Fri Aug 22 07:53:33 2008 From: petersen at redhat.com (Jens Petersen) Date: Fri, 22 Aug 2008 17:53:33 +1000 Subject: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> Message-ID: <48AE707D.60500@redhat.com> Hi Yaakov, Sorry for the slow response. I was away last week. > I've revised the guidelines once again to cover the issues brought up > when I brought them before the packaging committee. As follows is a > list of the issues I've heard, and how they are fixed. Thanks for your ongoing work on this. :) > * %buildsubdir is not a common way of doing things > ** we need this macro in the install phase to get at the working dir > we used to compile the package. This is not haskell specific and should really not be needed. Let's try to get rid of it. But how are packages supposed to get these macros? Surely each package is not going to include all of http://ynemoy.fedorapeople.org/haskell/macros.ghc ? The macros are not really that ghc specific: they should be prefixed cabal not ghc. IMHO some of it seems to be overkill. - if %ghc_autotools is necessary, can the -p option be made optional? I attach an (untested) which cleans up the macro file a bit. > * this file detection stuff is scary > ** I've put it into a series of macros and documented it Ok, that might be useful. :) > * this register stuff looks kinky > ** for starters, it's needed so the compiler knows where to look for > certain packages > ** it's been converted to a bunch of macros Less worried about that than I used to be. Again the macros don't really buy much. I don't quite understand %ghc_preinst_script and %ghc_postun_script: why do we need them? > I also think that if we can make this any more simple, then the only > thing that cabal-rpm really really needs to do is detect if a package > is a library, binary, or both, and then fill in some of the > dependencies automatically, which it's not clever enough yet to do > properly anyways. We may just need to create a few rpm templates, and > be done with it. Yes, maybe. > Anyways, I present the guidelines once more for review. I will try to > comandeer the help of the people in the SIG to start putting together > a repo of packages using these macros. The deadline for the F10 > feature is coming up soon, and I want to have it in a relatively > stable shape, even though we have time to fine tune the details later. We really need to get some packages in the queue reviewed first to check the sanity of the draft. And IMHO better to use KISS than too much overengineering. We can add more macros if necessary after more experience at a later revision. Jens -------------- next part -------------- A non-text attachment was scrubbed... Name: macros.haskell.patch Type: application/mbox Size: 2941 bytes Desc: not available URL: From bugzilla at redhat.com Fri Aug 22 08:13:29 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 22 Aug 2008 04:13:29 -0400 Subject: [Fedora-haskell-list] [Bug 426752] Review Request: ghc-X11-xft - Haskell bindings to the Xft, X Free Type interface library, and some Xrender parts In-Reply-To: References: Message-ID: <200808220813.m7M8DTHN022589@bz-web1.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=426752 --- Comment #2 from Jens Petersen 2008-08-22 04:13:28 EDT --- Can you add a URL field and a url for the source? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Fri Aug 22 09:09:27 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 22 Aug 2008 05:09:27 -0400 Subject: [Fedora-haskell-list] [Bug 426751] Review Request: ghc-X11 - A Haskell binding to the X11 graphics library. In-Reply-To: References: Message-ID: <200808220909.m7M99RLb030798@bz-web2.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=426751 --- Comment #13 from Jens Petersen 2008-08-22 05:09:25 EDT --- Created an attachment (id=314784) --> (https://bugzilla.redhat.com/attachment.cgi?id=314784) ghc-X11.spec.patch-1 Patch to cleanup and simplify spec file. Unfortunately the filelist generation does not work yet for me. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Fri Aug 22 09:39:54 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 22 Aug 2008 05:39:54 -0400 Subject: [Fedora-haskell-list] [Bug 426753] Review Request: xmonad - A tiling window manager In-Reply-To: References: Message-ID: <200808220939.m7M9dsB0009379@bz-web1.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=426753 --- Comment #4 from Jens Petersen 2008-08-22 05:39:53 EDT --- Created an attachment (id=314788) --> (https://bugzilla.redhat.com/attachment.cgi?id=314788) xmonad.spec.patch-1 cleanup and simplification -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Fri Aug 22 09:44:35 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 22 Aug 2008 05:44:35 -0400 Subject: [Fedora-haskell-list] [Bug 426753] Review Request: xmonad - A tiling window manager In-Reply-To: References: Message-ID: <200808220944.m7M9iZsJ010409@bz-web1.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=426753 --- Comment #5 from Jens Petersen 2008-08-22 05:44:34 EDT --- I am tempted to drop hsc_name too, it just seems to make everything more verbose. I suggest just changing %{hsc_name} to ghc. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From tmoertel at gmail.com Fri Aug 22 14:15:32 2008 From: tmoertel at gmail.com (Tom Moertel) Date: Fri, 22 Aug 2008 10:15:32 -0400 Subject: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <48AE707D.60500@redhat.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> Message-ID: <48AECA04.5080704@gmail.com> Jens Petersen wrote: > I don't quite understand %ghc_preinst_script and %ghc_postun_script: why > do we need them? Here's the rationale for those bits: http://www.serpentine.com/blog/2007/02/20/haskell-cabal-now-with-extra-crunchy-rpm-goodness/#comment-20132 Quoting: Let me point out a wrinkle I encountered when registering RPM-installed packages with GHC. When upgrading an RPM file that contains the same Cabal name+version of a package as the previously installed version (say with only an RPM release being different), the %pre, %post, %preun, and %postun scripts will all be asking GHC to register/unregister what it thinks are the same library. As a result, when the %preun script is called, which occurs *after* the new package is installed but before the old package is removed, its unregister script will actually unregister the newly installed library, leaving the new library unregistered with GHC. To test for the problem, take the existing spec file for an already-installed package, bump its RPM release, rebuild the RPMs, and then try to upgrade to the new version. After the upgrade, GHC will no longer know about the package. To avoid this problem, I?ve worked out the following spec-script dance... Cheers, Tom From bugzilla at redhat.com Wed Aug 27 00:09:18 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 26 Aug 2008 20:09:18 -0400 Subject: [Fedora-haskell-list] [Bug 426753] Review Request: xmonad - A tiling window manager In-Reply-To: References: Message-ID: <200808270009.m7R09IWC004852@bz-web2.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=426753 --- Comment #6 from Yaakov Nemoy 2008-08-26 20:09:18 EDT --- I've redone the guidelines completely to use macros. I'll be going over this in the coming weeks to make some badly needed updates to everything. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Wed Aug 27 07:16:07 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 27 Aug 2008 03:16:07 -0400 Subject: [Fedora-haskell-list] [Bug 426753] Review Request: xmonad - A tiling window manager In-Reply-To: References: Message-ID: <200808270716.m7R7G75r023429@bz-web1.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=426753 --- Comment #7 from Jens Petersen 2008-08-27 03:16:05 EDT --- The templates should be made self-contained by including the necessary macros. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Wed Aug 27 13:45:29 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 27 Aug 2008 09:45:29 -0400 Subject: [Fedora-haskell-list] [Bug 426753] Review Request: xmonad - A tiling window manager In-Reply-To: References: Message-ID: <200808271345.m7RDjTXP029435@bz-web1.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=426753 --- Comment #8 from Yaakov Nemoy 2008-08-27 09:45:28 EDT --- Theoretically yeah, but these macros are going to go in the GHC package, based on advice from the Packaging Committee. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Wed Aug 27 14:05:26 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 27 Aug 2008 10:05:26 -0400 Subject: [Fedora-haskell-list] [Bug 426753] Review Request: xmonad - A tiling window manager In-Reply-To: References: Message-ID: <200808271405.m7RE5QN5000822@bz-web1.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=426753 --- Comment #9 from Jason Tibbitts 2008-08-27 10:05:25 EDT --- The guidelines were approved (and hopefully will be accepted by FESCo today) but of course we need to see a ghc package rev with those macros included before reviews can really move forward. I guess this package (and perhaps others) will also need an update to conform to the new prettified specfule template. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From loupgaroublond at gmail.com Wed Aug 27 22:47:05 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 27 Aug 2008 18:47:05 -0400 Subject: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <48AE707D.60500@redhat.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> Message-ID: <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> On Fri, Aug 22, 2008 at 3:53 AM, Jens Petersen wrote: > Hi Yaakov, > > Sorry for the slow response. I was away last week. Ditto. >> * %buildsubdir is not a common way of doing things >> ** we need this macro in the install phase to get at the working dir >> we used to compile the package. > > This is not haskell specific and should really not be needed. > Let's try to get rid of it. It's needed for the macros that do file detection later on. Once we cd into the buildroot, we need a way of accessing the old dir we used to compile the package. Therefore, I've put it in a macro, and both sets of macros are mandatory. If you have a better solution, please fix it. > But how are packages supposed to get these macros? > Surely each package is not going to include all of > http://ynemoy.fedorapeople.org/haskell/macros.ghc ? That file is going to be packaged with ghc itself. I've submitted the following bug. https://bugzilla.redhat.com/show_bug.cgi?id=460304 > The macros are not really that ghc specific: they should be prefixed cabal > not ghc. Technically no, but I want to differentiate between what the theoretical command might be for foo haskell compiler, and what nuances there might be between compilers. > > IMHO some of it seems to be overkill. How so? For the most part, i'm converting the work that Bryan has done into macros, and polished it up. Every step that's there is stuff that Bryan has decided is necessary. > - if %ghc_autotools is necessary, can the -p option be made optional? What should the default be? > I attach an (untested) which cleans up the macro file a bit. I've attached that to the bug report to add them to GHC. > >> * this file detection stuff is scary >> ** I've put it into a series of macros and documented it > > Ok, that might be useful. :) > >> * this register stuff looks kinky >> ** for starters, it's needed so the compiler knows where to look for >> certain packages >> ** it's been converted to a bunch of macros > > Less worried about that than I used to be. > Again the macros don't really buy much. > > I don't quite understand %ghc_preinst_script and %ghc_postun_script: why do > we need them? Bryan answered this. > >> I also think that if we can make this any more simple, then the only >> thing that cabal-rpm really really needs to do is detect if a package >> is a library, binary, or both, and then fill in some of the >> dependencies automatically, which it's not clever enough yet to do >> properly anyways. We may just need to create a few rpm templates, and >> be done with it. > > Yes, maybe. > >> Anyways, I present the guidelines once more for review. I will try to >> comandeer the help of the people in the SIG to start putting together >> a repo of packages using these macros. The deadline for the F10 >> feature is coming up soon, and I want to have it in a relatively >> stable shape, even though we have time to fine tune the details later. > > We really need to get some packages in the queue reviewed first to check the > sanity of the draft. And IMHO better to use KISS than too much > overengineering. We can add more macros if necessary after more experience > at a later revision. I have a couple of volunteers. Gotta follow up on this. -Yaakov From petersen at redhat.com Wed Aug 27 23:55:09 2008 From: petersen at redhat.com (Jens Petersen) Date: Thu, 28 Aug 2008 09:55:09 +1000 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> Message-ID: <48B5E95D.7070400@redhat.com> Jason L Tibbitts III ????????: >>>>>> "YN" == Yaakov Nemoy writes: > > YN> I have a couple of volunteers. Gotta follow up on this. > > Well, perhaps you're unaware, but the draft has passed FPC and a few > hours ago passed FESCo and will become official next week unless > significant objections are raised. Sigh, how is that possible when we are still discussing the details? > Of course, we need those macros in > GHC before things will actually build, and I don't think all of the > submitted packages actually conform to the approved draft so there may > be a bit of work before they can pass a review. I really wanted to have the horse in front of the cart... Jens From bugzilla at redhat.com Wed Aug 27 23:59:36 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 27 Aug 2008 19:59:36 -0400 Subject: [Fedora-haskell-list] [Bug 460304] Add macros to GHC for packaging cabal packages for GHC In-Reply-To: References: Message-ID: <200808272359.m7RNxaDY027654@bz-web2.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=460304 Jens Petersen changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #315097|application/octet-stream |text/plain mime type| | -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Wed Aug 27 23:58:53 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 27 Aug 2008 19:58:53 -0400 Subject: [Fedora-haskell-list] [Bug 460304] Add macros to GHC for packaging cabal packages for GHC In-Reply-To: References: Message-ID: <200808272358.m7RNwrqj027523@bz-web2.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=460304 Jens Petersen changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fedora-haskell-list at redhat. | |com Customer Facing| |--- -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From petersen at redhat.com Thu Aug 28 00:26:35 2008 From: petersen at redhat.com (Jens Petersen) Date: Thu, 28 Aug 2008 10:26:35 +1000 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> <48B5E95D.7070400@redhat.com> Message-ID: <48B5F0BB.2020908@redhat.com> Hi Jason, > Because the draft was submitted to us as complete, and we voted on it. I understood that it was submitted as a draft for comments... > If someone didn't want us to vote on it, it would have been nice > if someone had let us know. I thought that was what this discussion was about: https://www.redhat.com/archives/fedora-packaging/2008-August/thread.html#00040 Thanks for the headsup anyway. :) Jens From loupgaroublond at gmail.com Thu Aug 28 01:00:01 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 27 Aug 2008 21:00:01 -0400 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <48B5F0BB.2020908@redhat.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> <48B5E95D.7070400@redhat.com> <48B5F0BB.2020908@redhat.com> Message-ID: <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> On Wed, Aug 27, 2008 at 8:26 PM, Jens Petersen wrote: > Hi Jason, > >> Because the draft was submitted to us as complete, and we voted on it. > > I understood that it was submitted as a draft for comments... Long ago, i got tired of submitting drafts for comments to have to wait. I took spot's advice and just submitted them for review and comment simultaneously. The principle idea was that I put a deadline on the commenting period, and if there were no comments by a certain time, then it would go straight to review. This way, two groups of people got a chance to look at the drafts at the same time. Finally, it went for a review by the Committee, and they made their comments. We also discussed your comments. I addressed their comments, which was the final request for review. Like I said (accidentally offlist), it's not set in stone either, I'm still listening. -Yaakov From bos at serpentine.com Thu Aug 28 03:03:36 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed, 27 Aug 2008 20:03:36 -0700 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> <48B5E95D.7070400@redhat.com> <48B5F0BB.2020908@redhat.com> <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> Message-ID: Frankly, I think that the current version of the guidelines is fine. It's much better to have something not quite perfect where we can make progress than to be permanently stuck. So moving forwards with what we have suits me. On 8/27/08, Yaakov Nemoy wrote: > On Wed, Aug 27, 2008 at 8:26 PM, Jens Petersen wrote: >> Hi Jason, >> >>> Because the draft was submitted to us as complete, and we voted on it. >> >> I understood that it was submitted as a draft for comments... > > Long ago, i got tired of submitting drafts for comments to have to > wait. I took spot's advice and just submitted them for review and > comment simultaneously. The principle idea was that I put a deadline > on the commenting period, and if there were no comments by a certain > time, then it would go straight to review. This way, two groups of > people got a chance to look at the drafts at the same time. > > Finally, it went for a review by the Committee, and they made their > comments. We also discussed your comments. I addressed their > comments, which was the final request for review. > > Like I said (accidentally offlist), it's not set in stone either, I'm > still listening. > > -Yaakov > > _______________________________________________ > Fedora-haskell-list mailing list > Fedora-haskell-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-haskell-list > From bugzilla at redhat.com Thu Aug 28 03:24:59 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 27 Aug 2008 23:24:59 -0400 Subject: [Fedora-haskell-list] [Bug 426751] Review Request: ghc-X11 - A Haskell binding to the X11 graphics library. In-Reply-To: References: Message-ID: <200808280324.m7S3OxgC030565@bz-web2.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=426751 --- Comment #14 from Jens Petersen 2008-08-27 23:24:58 EDT --- Created an attachment (id=315171) --> (https://bugzilla.redhat.com/attachment.cgi?id=315171) ghc-X11.spec.patch-2 Patch to fix the filelist generation. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From petersen at redhat.com Thu Aug 28 07:23:11 2008 From: petersen at redhat.com (Jens Petersen) Date: Thu, 28 Aug 2008 17:23:11 +1000 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> <48B5E95D.7070400@redhat.com> <48B5F0BB.2020908@redhat.com> <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> Message-ID: <48B6525F.8050900@redhat.com> Hi, Bryan O'Sullivan ????????: > Frankly, I think that the current version of the guidelines is fine. > It's much better to have something not quite perfect where we can make > progress than to be permanently stuck. So moving forwards with what we > have suits me. I finally took a deep look at cabal-rpm (never actually used it before!;) and realised that that is largely the source of all my problems with the current guidelines... Below is a patch against darcs head which backports most of my changes to the guidelines to cabal-rpm. If we're using cabal-rpm for packaging then we really don't need to add rpm macros IMHO. Thanks for all the comments. Jens -------------- next part -------------- A non-text attachment was scrubbed... Name: cabal-rpm-fedora.patch Type: application/mbox Size: 10937 bytes Desc: not available URL: From fedora at krishnan.cc Thu Aug 28 08:16:15 2008 From: fedora at krishnan.cc (Rajesh Krishnan) Date: Thu, 28 Aug 2008 01:16:15 -0700 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <48B6525F.8050900@redhat.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48B6525F.8050900@redhat.com> Message-ID: <200808280116.15960.fedora@krishnan.cc> > If we're using cabal-rpm for packaging > then we really don't need to add rpm macros IMHO. I am very much in favor of having good set of base macros (under /etc/rpm/). I have developed some simple rpms using the macros posted by Yaakov and Jens (which needed to be tweaked a bit), and was quite happy with the results. I will share those in the following email. -Rajesh On 2008-08-28-Thu 12:23:11 am Jens Petersen wrote: > Hi, > > Bryan O'Sullivan ????????: > > Frankly, I think that the current version of the guidelines is fine. > > It's much better to have something not quite perfect where we can make > > progress than to be permanently stuck. So moving forwards with what we > > have suits me. > > I finally took a deep look at cabal-rpm (never actually used it > before!;) and realised that that is largely the source of all my > problems with the current guidelines... > > Below is a patch against darcs head which backports most of my changes > to the guidelines to cabal-rpm. If we're using cabal-rpm for packaging > then we really don't need to add rpm macros IMHO. > > Thanks for all the comments. > > Jens From rjones at redhat.com Thu Aug 28 08:38:28 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 28 Aug 2008 09:38:28 +0100 Subject: [Fedora-haskell-list] Any easy reviews? Message-ID: <20080828083828.GB22971@amd.home.annexia.org> Any easy Haskell review requests that I could do? I was considering https://bugzilla.redhat.com/show_bug.cgi?id=425882 (ghc-zlib) but the spec file looks a bit daunting. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From fedora at krishnan.cc Thu Aug 28 09:26:20 2008 From: fedora at krishnan.cc (Rajesh Krishnan) Date: Thu, 28 Aug 2008 02:26:20 -0700 Subject: [Fedora-haskell-list] Any easy reviews? In-Reply-To: <20080828083828.GB22971@amd.home.annexia.org> References: <20080828083828.GB22971@amd.home.annexia.org> Message-ID: <200808280226.20785.fedora@krishnan.cc> I could submit a large number of Haskell packages over the next few days for review once I get clarification with some issues regarding macros. -Rajesh On 2008-08-28-Thu 01:38:28 am Richard W.M. Jones wrote: > Any easy Haskell review requests that I could do? I was considering > https://bugzilla.redhat.com/show_bug.cgi?id=425882 (ghc-zlib) but the > spec file looks a bit daunting. > > Rich. From fedora at krishnan.cc Thu Aug 28 09:50:46 2008 From: fedora at krishnan.cc (Rajesh Krishnan) Date: Thu, 28 Aug 2008 02:50:46 -0700 Subject: [Fedora-haskell-list] Test package - Cabal-1.4.0.2 (using cabal_* macros). was: Re: [Fedora-packaging] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48B5F0BB.2020908@redhat.com> <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> Message-ID: <200808280250.47069.fedora@krishnan.cc> Yaakov / Jens, Have we finally decided if what style of macros we wish to move forward with (ghc_* v/s cabal_*)? I looked at Jens' update for the macros file and liked the syntax, and created this sample package for the latest version of Cabal (1.4.0.2). The specified SPEC below compiles well on F8 and F9 (the rpmbuild command on rawhide (F10) seems to have BuildRoot resolution issues at the moment, and may not build on rawhide). Here are the F9 source and binaries (tested on F9 on amd64, with ghc-6.8.3): RPM(x86_64): http://krishnan.cc/devel/repository/fedora/RPMS/x86_64/ghc-cabal-1.4.0.2-1.fc9.x86_64.rpm RPM(i386): http://krishnan.cc/devel/repository/fedora/RPMS/i386/ghc-cabal-1.4.0.2-1.fc9.i386.rpm SPEC: http://krishnan.cc/devel/repository/fedora/SPECS/ghc-cabal.spec SRPM: http://krishnan.cc/devel/repository/fedora/SRPMS/ghc-cabal-1.4.0.2-1.fc9.src.rpm macros.haskell: http://krishnan.cc/devel/repository/fedora/MISC/macros.haskell (This is the modified file with cabal_* style macros as proposed by Jens. Note that we need to place macros.haskell under /etc/rpm to successfully build with the above .spec). YAAKOV: Note that the macros.haskell file needs another variable called %{internal_name} which needs to get defined in the spec for Hackage that start with a capital letter (like the Cabal example mentioned here). Otherwise it IMHO it is not possible keep the resulting rpm name (ghc-cabal) in all lowercase letters as per the Haskell package building specification. If we have decided stay with the original macros.ghc style macros (ghc_*) then I can update the package and resubmit with the modified macros.ghc file. I am not biased towards either macros.ghc or macros.haskell, and either one of them is fine with me (will need to tweak them a bit of course). And also, could somebody help me with getting some file-hosting space on FedoraPeople or Fedoraproject sites? That would help me upload the packages and spec related files for public sharing. Let me know if anyone is unable to access the files over the URLs mentioned above. -Rajesh - On 2008-08-27-Wed 06:00:01 pm Yaakov Nemoy wrote: > On Wed, Aug 27, 2008 at 8:26 PM, Jens Petersen wrote: > > Hi Jason, > > > >> Because the draft was submitted to us as complete, and we voted on it. > > > > I understood that it was submitted as a draft for comments... > > Long ago, i got tired of submitting drafts for comments to have to > wait. I took spot's advice and just submitted them for review and > comment simultaneously. The principle idea was that I put a deadline > on the commenting period, and if there were no comments by a certain > time, then it would go straight to review. This way, two groups of > people got a chance to look at the drafts at the same time. > > Finally, it went for a review by the Committee, and they made their > comments. We also discussed your comments. I addressed their > comments, which was the final request for review. > > Like I said (accidentally offlist), it's not set in stone either, I'm > still listening. > > -Yaakov > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging From miles at milessabin.com Thu Aug 28 11:17:43 2008 From: miles at milessabin.com (Miles Sabin) Date: Thu, 28 Aug 2008 12:17:43 +0100 Subject: [Fedora-haskell-list] Test package - Cabal-1.4.0.2 (using cabal_* macros). was: Re: [Fedora-packaging] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <200808280250.47069.fedora@krishnan.cc> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48B5F0BB.2020908@redhat.com> <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> <200808280250.47069.fedora@krishnan.cc> Message-ID: <30961e500808280417x32be08e4g4c1d0eafc69edbc4@mail.gmail.com> On Thu, Aug 28, 2008 at 10:50 AM, Rajesh Krishnan wrote: > Have we finally decided if what style of macros we wish to move forward with > (ghc_* v/s cabal_*)? I looked at Jens' update for the macros file and liked > the syntax, and created this sample package for the latest version of Cabal > (1.4.0.2). >From the spec file: %changelog * Wed Aug 27 2008 cabal-rpm - 1.4.0.2-1 - spec file autogenerated by cabal-rpm Is that true? If so, were any manual tweaks to the output for cabal-rpm necessary? Cheers, Miles From bos at serpentine.com Thu Aug 28 13:38:01 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu, 28 Aug 2008 06:38:01 -0700 Subject: [Fedora-haskell-list] Any easy reviews? In-Reply-To: <200808280226.20785.fedora@krishnan.cc> References: <20080828083828.GB22971@amd.home.annexia.org> <200808280226.20785.fedora@krishnan.cc> Message-ID: On Thu, Aug 28, 2008 at 2:26 AM, Rajesh Krishnan wrote: > I could submit a large number of Haskell packages over the next few days for > review once I get clarification with some issues regarding macros. Yep, best to get one or two through cleanly, then open the floodgates :-) From bos at serpentine.com Thu Aug 28 13:44:05 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu, 28 Aug 2008 06:44:05 -0700 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <200808280116.15960.fedora@krishnan.cc> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48B6525F.8050900@redhat.com> <200808280116.15960.fedora@krishnan.cc> Message-ID: On Thu, Aug 28, 2008 at 1:16 AM, Rajesh Krishnan wrote: >> If we're using cabal-rpm for packaging >> then we really don't need to add rpm macros IMHO. > > I am very much in favor of having good set of base macros (under /etc/rpm/). I like to have both the macros and cabal-rpm, where the latter assumes the presence of the former. From loupgaroublond at gmail.com Thu Aug 28 18:12:05 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 28 Aug 2008 14:12:05 -0400 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <48B6525F.8050900@redhat.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> <48B5E95D.7070400@redhat.com> <48B5F0BB.2020908@redhat.com> <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> <48B6525F.8050900@redhat.com> Message-ID: <7f692fec0808281112x7bfe5c8bjbb4770aacab600f8@mail.gmail.com> On Thu, Aug 28, 2008 at 3:23 AM, Jens Petersen wrote: > Hi, > > Bryan O'Sullivan ????????: >> >> Frankly, I think that the current version of the guidelines is fine. >> It's much better to have something not quite perfect where we can make >> progress than to be permanently stuck. So moving forwards with what we >> have suits me. > > I finally took a deep look at cabal-rpm (never actually used it before!;) > and realised that that is largely the source of all my problems with the > current guidelines... > > Below is a patch against darcs head which backports most of my changes to > the guidelines to cabal-rpm. If we're using cabal-rpm for packaging then we > really don't need to add rpm macros IMHO. > I want to move away from cabal-rpm actually. The biggest pro for the macros is that we need the code to make sense to other reviewers that are not experienced with this. Any time a package needs to do something using something other than one of the macros, then we can have an expert come in an evaluate it. Another reason for using the macros is that changes only need to be made to one place. While doing the guidelines, I had to make a number of changes to cabal-rpm, and were we not to use macros, every change to cabal-rpm would have to be backported to the packages in Fedora. I'm going to put together some templates today. -Yaakov From fedora at krishnan.cc Thu Aug 28 18:17:38 2008 From: fedora at krishnan.cc (Rajesh Krishnan) Date: Thu, 28 Aug 2008 11:17:38 -0700 Subject: [Fedora-haskell-list] Test package - Cabal-1.4.0.2 (using cabal_* macros). was: Re: [Fedora-packaging] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <30961e500808280417x32be08e4g4c1d0eafc69edbc4@mail.gmail.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <200808280250.47069.fedora@krishnan.cc> <30961e500808280417x32be08e4g4c1d0eafc69edbc4@mail.gmail.com> Message-ID: <200808281117.38755.fedora@krishnan.cc> Miles, Please don't read too much into the changelog for now. It is just a generated stub. The code that generated that spec is not cabal-rpm (but a fork with my custom modifications). -Rajesh On 2008-08-28-Thu 04:17:43 am Miles Sabin wrote: > On Thu, Aug 28, 2008 at 10:50 AM, Rajesh Krishnan wrote: > > Have we finally decided if what style of macros we wish to move forward > > with (ghc_* v/s cabal_*)? I looked at Jens' update for the macros file > > and liked the syntax, and created this sample package for the latest > > version of Cabal (1.4.0.2). > > > >From the spec file: > > %changelog > * Wed Aug 27 2008 cabal-rpm - 1.4.0.2-1 > - spec file autogenerated by cabal-rpm > > Is that true? If so, were any manual tweaks to the output for > cabal-rpm necessary? > > Cheers, > > > Miles > > _______________________________________________ > Fedora-haskell-list mailing list > Fedora-haskell-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-haskell-list From fedora at krishnan.cc Thu Aug 28 18:24:48 2008 From: fedora at krishnan.cc (Rajesh Krishnan) Date: Thu, 28 Aug 2008 11:24:48 -0700 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <200808280116.15960.fedora@krishnan.cc> Message-ID: <200808281124.49306.fedora@krishnan.cc> Bryan, I have forked cabal-rpm (with due credits to you, and the code is still GPL) that does generation of the Fedora specific SPEC file only, with the new macros. I chose to do that because there were too many changes I needed to get some things right, and get rid of other stuff (like executing rpmbuild) that were irrelevant for my purposes. I would publish the code once it becomes half stable and somewhat working. Please don't take this otherwise, as your code is absolutely great Haskell work and I learned some finer Haskell coding styles while studying your code. -Rajesh On 2008-08-28-Thu 06:44:05 am Bryan O'Sullivan wrote: > On Thu, Aug 28, 2008 at 1:16 AM, Rajesh Krishnan wrote: > >> If we're using cabal-rpm for packaging > >> then we really don't need to add rpm macros IMHO. > > > > I am very much in favor of having good set of base macros (under > > /etc/rpm/). > > I like to have both the macros and cabal-rpm, where the latter assumes > the presence of the former. From loupgaroublond at gmail.com Thu Aug 28 18:28:08 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 28 Aug 2008 14:28:08 -0400 Subject: [Fedora-haskell-list] Re: Test package - Cabal-1.4.0.2 (using cabal_* macros). was: Re: [Fedora-packaging] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <200808280250.47069.fedora@krishnan.cc> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48B5F0BB.2020908@redhat.com> <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> <200808280250.47069.fedora@krishnan.cc> Message-ID: <7f692fec0808281128m4f134917ud30505ab204b3a85@mail.gmail.com> On Thu, Aug 28, 2008 at 5:50 AM, Rajesh Krishnan wrote: > Yaakov / Jens, > > Have we finally decided if what style of macros we wish to move forward with > (ghc_* v/s cabal_*)? I looked at Jens' update for the macros file and liked > the syntax, and created this sample package for the latest version of Cabal > (1.4.0.2). The specified SPEC below compiles well on F8 and F9 (the rpmbuild > command on rawhide (F10) seems to have BuildRoot resolution issues at the > moment, and may not build on rawhide). Here are the F9 source and binaries > (tested on F9 on amd64, with ghc-6.8.3): cabal_* is a no go. It makes it *much* harder to support multiple compilers in the future. Remember these rules. All libraries theoretically need to have a seperate spec file (thus seperate package in CVS) for each compiler we ship. Thus: ghc-foo hugs98-foo barhc-foo For library foo in hackage. All packages that also ship with executables should be compiled with GHC (or give a good justification for using another compiler), thus: xmonad darcs haddock For xmonad, darcs, and haddock. Packages that do code generation, and ship both libraries and executables should also use GHC, but the library component should be named after GHC. Note that the library component is just a subpackage of the executable. Thus: xmonad For xmonad. > > RPM(x86_64): > http://krishnan.cc/devel/repository/fedora/RPMS/x86_64/ghc-cabal-1.4.0.2-1.fc9.x86_64.rpm > > RPM(i386): > http://krishnan.cc/devel/repository/fedora/RPMS/i386/ghc-cabal-1.4.0.2-1.fc9.i386.rpm > > SPEC: > http://krishnan.cc/devel/repository/fedora/SPECS/ghc-cabal.spec > > SRPM: > http://krishnan.cc/devel/repository/fedora/SRPMS/ghc-cabal-1.4.0.2-1.fc9.src.rpm > > macros.haskell: > http://krishnan.cc/devel/repository/fedora/MISC/macros.haskell > (This is the modified file with cabal_* style macros as proposed by Jens. Note > that we need to place macros.haskell under /etc/rpm to successfully build > with the above .spec). > > > YAAKOV: Note that the macros.haskell file needs another variable > called %{internal_name} which needs to get defined in the spec for Hackage > that start with a capital letter (like the Cabal example mentioned here). > Otherwise it IMHO it is not possible keep the resulting rpm name (ghc-cabal) > in all lowercase letters as per the Haskell package building specification. Uh, that part changed. We are now going with upstream names. This was to reduce complexity, since Upstream uses a consistent naming scheme. > If we have decided stay with the original macros.ghc style macros (ghc_*) > then I can update the package and resubmit with the modified macros.ghc file. > I am not biased towards either macros.ghc or macros.haskell, and either one > of them is fine with me (will need to tweak them a bit of course). > > And also, could somebody help me with getting some file-hosting space on > FedoraPeople or Fedoraproject sites? That would help me upload the packages > and spec related files for public sharing. You should have some already with your FAS account. -Yaakov From fedora at krishnan.cc Thu Aug 28 22:20:35 2008 From: fedora at krishnan.cc (Rajesh Krishnan) Date: Thu, 28 Aug 2008 15:20:35 -0700 Subject: [Fedora-haskell-list] Re: Test package - Cabal-1.4.0.2 (using cabal_* macros). was: Re: [Fedora-packaging] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <7f692fec0808281128m4f134917ud30505ab204b3a85@mail.gmail.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <200808280250.47069.fedora@krishnan.cc> <7f692fec0808281128m4f134917ud30505ab204b3a85@mail.gmail.com> Message-ID: <200808281520.35828.fedora@krishnan.cc> Yaakov, For Hackage packages that contain only libraries, or a single executable, the package building specification is clear (name the RPM for library only package xyz as ghc-xyz, and name the RPM for a single executable package xyz as just xyz without the ghc prefix). But the part of the specification is not clear to me is: What would be the RPM name for a Hackage package xyz that contains multiple libraries and multiple executables? Is it OK to create a single RPM called xyz in for such a package, or do they necessarily need to be split up into multiple package fragments? Please explain if you could. Note that the number of such fragmented RPMs would multiply fast (creation of perhaps -prof and -doc etc. if applicable for each subpackage) . Thanks in advance. -Rajesh On 2008-08-28-Thu 11:28:08 am Yaakov Nemoy wrote: > On Thu, Aug 28, 2008 at 5:50 AM, Rajesh Krishnan wrote: > > Yaakov / Jens, > > > > Have we finally decided if what style of macros we wish to move forward > > with (ghc_* v/s cabal_*)? I looked at Jens' update for the macros file > > and liked the syntax, and created this sample package for the latest > > version of Cabal (1.4.0.2). The specified SPEC below compiles well on F8 > > and F9 (the rpmbuild command on rawhide (F10) seems to have BuildRoot > > resolution issues at the moment, and may not build on rawhide). Here are > > the F9 source and binaries (tested on F9 on amd64, with ghc-6.8.3): > > cabal_* is a no go. It makes it *much* harder to support multiple > compilers in the future. Remember these rules. > > All libraries theoretically need to have a seperate spec file (thus > seperate package in CVS) for each compiler we ship. Thus: > ghc-foo > hugs98-foo > barhc-foo > > For library foo in hackage. > > All packages that also ship with executables should be compiled with > GHC (or give a good justification for using another compiler), thus: > xmonad > darcs > haddock > > For xmonad, darcs, and haddock. > > Packages that do code generation, and ship both libraries and > executables should also use GHC, but the library component should be > named after GHC. Note that the library component is just a subpackage > of the executable. Thus: > xmonad > > For xmonad. > > > RPM(x86_64): > > http://krishnan.cc/devel/repository/fedora/RPMS/x86_64/ghc-cabal-1.4.0.2- > >1.fc9.x86_64.rpm > > > > RPM(i386): > > http://krishnan.cc/devel/repository/fedora/RPMS/i386/ghc-cabal-1.4.0.2-1. > >fc9.i386.rpm > > > > SPEC: > > http://krishnan.cc/devel/repository/fedora/SPECS/ghc-cabal.spec > > > > SRPM: > > http://krishnan.cc/devel/repository/fedora/SRPMS/ghc-cabal-1.4.0.2-1.fc9. > >src.rpm > > > > macros.haskell: > > http://krishnan.cc/devel/repository/fedora/MISC/macros.haskell > > (This is the modified file with cabal_* style macros as proposed by Jens. > > Note that we need to place macros.haskell under /etc/rpm to successfully > > build with the above .spec). > > > > > > YAAKOV: Note that the macros.haskell file needs another variable > > called %{internal_name} which needs to get defined in the spec for > > Hackage that start with a capital letter (like the Cabal example > > mentioned here). Otherwise it IMHO it is not possible keep the resulting > > rpm name (ghc-cabal) in all lowercase letters as per the Haskell package > > building specification. > > Uh, that part changed. We are now going with upstream names. This > was to reduce complexity, since Upstream uses a consistent naming > scheme. > > > If we have decided stay with the original macros.ghc style macros > > (ghc_*) then I can update the package and resubmit with the modified > > macros.ghc file. I am not biased towards either macros.ghc or > > macros.haskell, and either one of them is fine with me (will need to > > tweak them a bit of course). > > > > And also, could somebody help me with getting some file-hosting space on > > FedoraPeople or Fedoraproject sites? That would help me upload the > > packages and spec related files for public sharing. > > You should have some already with your FAS account. > > > -Yaakov From loupgaroublond at gmail.com Thu Aug 28 23:29:36 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 28 Aug 2008 19:29:36 -0400 Subject: [Fedora-haskell-list] Re: Test package - Cabal-1.4.0.2 (using cabal_* macros). was: Re: [Fedora-packaging] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <200808281520.35828.fedora@krishnan.cc> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <200808280250.47069.fedora@krishnan.cc> <7f692fec0808281128m4f134917ud30505ab204b3a85@mail.gmail.com> <200808281520.35828.fedora@krishnan.cc> Message-ID: <7f692fec0808281629v6c945435j20e7c88633216d44@mail.gmail.com> On Thu, Aug 28, 2008 at 6:20 PM, Rajesh Krishnan wrote: > Yaakov, > > For Hackage packages that contain only libraries, or a single executable, the > package building specification is clear (name the RPM for library only > package xyz as ghc-xyz, and name the RPM for a single executable package xyz > as just xyz without the ghc prefix). > > But the part of the specification is not clear to me is: > > What would be the RPM name for a Hackage package xyz that contains multiple > libraries and multiple executables? Is it OK to create a single RPM called > xyz in for such a package, or do they necessarily need to be split up into > multiple package fragments? Please explain if you could. Note that the > number of such fragmented RPMs would multiply fast (creation of perhaps -prof > and -doc etc. if applicable for each subpackage) . > > Thanks in advance. > -Rajesh Can you give me an example? It's not unreasonable for a package to install multiple executables either, mind you that they are all connected in some way. It's a bit stranger that there are multiple libraries involved, all coming from a single source tarball. Perhaps upstream needs to split up what it's doing into several source packages? -Yaakov From petersen at redhat.com Thu Aug 28 23:49:51 2008 From: petersen at redhat.com (Jens Petersen) Date: Fri, 29 Aug 2008 09:49:51 +1000 Subject: [Fedora-haskell-list] Re: Test package - Cabal-1.4.0.2 (using cabal_* macros). was: Re: [Fedora-packaging] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <7f692fec0808281128m4f134917ud30505ab204b3a85@mail.gmail.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48B5F0BB.2020908@redhat.com> <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> <200808280250.47069.fedora@krishnan.cc> <7f692fec0808281128m4f134917ud30505ab204b3a85@mail.gmail.com> Message-ID: <48B7399F.6080407@redhat.com> Yaakov Nemoy ????????: > cabal_* is a no go. It makes it *much* harder to support multiple > compilers in the future. Remember these rules. I am not sure. If Cabal is compiler/interpreter agnostic as it is supposed to be I thought, we can just use runhaskell to run it without having to worry about what runtime we are building for? Or is that oversimplying? Of course, sure, we still need build options for different compilers but the running of the build process should not depend heavily on it? Maybe Bryan can clarify this point? Jens From loupgaroublond at gmail.com Thu Aug 28 23:54:33 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 28 Aug 2008 19:54:33 -0400 Subject: [Fedora-haskell-list] Re: Test package - Cabal-1.4.0.2 (using cabal_* macros). was: Re: [Fedora-packaging] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <48B7399F.6080407@redhat.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48B5F0BB.2020908@redhat.com> <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> <200808280250.47069.fedora@krishnan.cc> <7f692fec0808281128m4f134917ud30505ab204b3a85@mail.gmail.com> <48B7399F.6080407@redhat.com> Message-ID: <7f692fec0808281654o4db203fci5b0135aa95dd5db4@mail.gmail.com> On Thu, Aug 28, 2008 at 7:49 PM, Jens Petersen wrote: > Yaakov Nemoy ????????: >> >> cabal_* is a no go. It makes it *much* harder to support multiple >> compilers in the future. Remember these rules. > > I am not sure. If Cabal is compiler/interpreter agnostic as it is supposed > to be I thought, we can just use runhaskell to run it without having to > worry about what runtime we are building for? Or is that oversimplying? Of > course, sure, we still need build options for different compilers but the > running of the build process should not depend heavily on it? > > Maybe Bryan can clarify this point? > > Jens > If we do this, then each 'library' package is going to have to support every single compiler we have. I would rather have one SRPM per library per compiler. Calling runhaskell will only call the default compiler, which in Fedora's case is GHC. -Yaakov From petersen at redhat.com Fri Aug 29 00:00:37 2008 From: petersen at redhat.com (Jens Petersen) Date: Fri, 29 Aug 2008 10:00:37 +1000 Subject: [Fedora-haskell-list] Re: Test package - Cabal-1.4.0.2 (using cabal_* macros). was: Re: [Fedora-packaging] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <7f692fec0808281654o4db203fci5b0135aa95dd5db4@mail.gmail.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48B5F0BB.2020908@redhat.com> <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> <200808280250.47069.fedora@krishnan.cc> <7f692fec0808281128m4f134917ud30505ab204b3a85@mail.gmail.com> <48B7399F.6080407@redhat.com> <7f692fec0808281654o4db203fci5b0135aa95dd5db4@mail.gmail.com> Message-ID: <48B73C25.304@redhat.com> Yaakov Nemoy ????????: > If we do this, then each 'library' package is going to have to support > every single compiler we have. No they don't have to but they can if they want. :) > I would rather have one SRPM per library per compiler. I thought we proposed "haskell-%pkg_name" exactly for this? > Calling runhaskell will only call the default > compiler, which in Fedora's case is GHC. Well it depends what you have installed (it is handled by alternatives). But as I say it should not matter what runtime is used to run Setup.hs? Jens From petersen at redhat.com Fri Aug 29 00:03:36 2008 From: petersen at redhat.com (Jens Petersen) Date: Fri, 29 Aug 2008 10:03:36 +1000 Subject: [Fedora-haskell-list] Re: Test package - Cabal-1.4.0.2 (using cabal_* macros). was: Re: [Fedora-packaging] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <200808281520.35828.fedora@krishnan.cc> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <200808280250.47069.fedora@krishnan.cc> <7f692fec0808281128m4f134917ud30505ab204b3a85@mail.gmail.com> <200808281520.35828.fedora@krishnan.cc> Message-ID: <48B73CD8.1080206@redhat.com> Rajesh Krishnan ????????: > For Hackage packages that contain only libraries, or a single executable, the > package building specification is clear (name the RPM for library only > package xyz as ghc-xyz, and name the RPM for a single executable package xyz > as just xyz without the ghc prefix). The example corresponding to xmonad (which has both an executable and library) is given in the guidelines: the base package name in that case should be just "xmonad". > What would be the RPM name for a Hackage package xyz that contains multiple > libraries and multiple executables? Is it OK to create a single RPM called > xyz in for such a package, or do they necessarily need to be split up into > multiple package fragments? Please explain if you could. Note that the > number of such fragmented RPMs would multiply fast (creation of perhaps -prof > and -doc etc. if applicable for each subpackage) . So do you have a specific package in mind? It is easier to discuss concrete examples than hypothetical cases. :) Jens From loupgaroublond at gmail.com Fri Aug 29 02:25:32 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 28 Aug 2008 22:25:32 -0400 Subject: [Fedora-haskell-list] Re: Test package - Cabal-1.4.0.2 (using cabal_* macros). was: Re: [Fedora-packaging] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <48B73C25.304@redhat.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48B5F0BB.2020908@redhat.com> <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> <200808280250.47069.fedora@krishnan.cc> <7f692fec0808281128m4f134917ud30505ab204b3a85@mail.gmail.com> <48B7399F.6080407@redhat.com> <7f692fec0808281654o4db203fci5b0135aa95dd5db4@mail.gmail.com> <48B73C25.304@redhat.com> Message-ID: <7f692fec0808281925o64575943p9287170264ab893e@mail.gmail.com> 2008/8/28 Jens Petersen : > Yaakov Nemoy ????????: >> If we do this, then each 'library' package is going to have to support >> every single compiler we have. > > No they don't have to but they can if they want. :) It would be messy. > >> I would rather have one SRPM per library per compiler. > > I thought we proposed "haskell-%pkg_name" exactly for this? Nope, that's why it's %haskell_compiler-%pkg_name exactly for this. Otherwise, we can only support one compiler without a lot of weird tricks. (Granted, we could just include multiple macros for multiple compilers in a single spec file, and then build and publish a single RPM for each library that supports multiple compilers. I think this would lead to alot of bloat. Alternatively, we could have a single spec file per library, and have it generate multiple subpackages, one for each compiler. I would rather have one spec per compiler per library.) > >> Calling runhaskell will only call the default >> compiler, which in Fedora's case is GHC. > > Well it depends what you have installed (it is handled by alternatives). > But as I say it should not matter what runtime is used to run Setup.hs? AFAIK, the run time you use to run Setup.hs is the runtime that the library is compiled against. Namely, runhaskell that runs runghc would create a package for GHC. -Yaakov From petersen at redhat.com Fri Aug 29 02:42:13 2008 From: petersen at redhat.com (Jens Petersen) Date: Fri, 29 Aug 2008 12:42:13 +1000 Subject: [Fedora-haskell-list] Re: Test package - Cabal-1.4.0.2 (using cabal_* macros). was: Re: [Fedora-packaging] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <7f692fec0808281925o64575943p9287170264ab893e@mail.gmail.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48B5F0BB.2020908@redhat.com> <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> <200808280250.47069.fedora@krishnan.cc> <7f692fec0808281128m4f134917ud30505ab204b3a85@mail.gmail.com> <48B7399F.6080407@redhat.com> <7f692fec0808281654o4db203fci5b0135aa95dd5db4@mail.gmail.com> <48B73C25.304@redhat.com> <7f692fec0808281925o64575943p9287170264ab893e@mail.gmail.com> Message-ID: <48B76205.1060607@redhat.com> Yaakov Nemoy ????????: > 2008/8/28 Jens Petersen : >> Yaakov Nemoy ????????: >>> If we do this, then each 'library' package is going to have to support >>> every single compiler we have. >> No they don't have to but they can if they want. :) > > It would be messy. > >>> I would rather have one SRPM per library per compiler. >> I thought we proposed "haskell-%pkg_name" exactly for this? > > Nope, that's why it's %haskell_compiler-%pkg_name exactly for this. > Otherwise, we can only support one compiler without a lot of weird > tricks. I quote from PackagingDrafts/Haskell...: "If a library supports multiple Haskell compilers or interpreters, the base name should instead be prefixed with haskell, e.g. haskell-X11." So you want to withtract this? :) > (Granted, we could just include multiple macros for multiple compilers > in a single spec file, and then build and publish a single RPM for > each library that supports multiple compilers. I think this would > lead to alot of bloat. Alternatively, we could have a single spec > file per library, and have it generate multiple subpackages, one for > each compiler. I would rather have one spec per compiler per > library.) Well that is what they do in the Emacs Lisp world for Emacs and XEmacs and it works: it is a really pain having to maintain parallel packages for different compiler. Actually we could face this problem immediately if Rajesh submits haskell-Cabal, since it should really be packaged for both ghc and hugs98. > AFAIK, the run time you use to run Setup.hs is the runtime that the > library is compiled against. Namely, runhaskell that runs runghc > would create a package for GHC. I don't think it matters since it is only "scripting" and cabal is supposed to be portable Haskell98 presumably. Jens From bos at serpentine.com Fri Aug 29 03:26:27 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu, 28 Aug 2008 20:26:27 -0700 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <200808281124.49306.fedora@krishnan.cc> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <200808280116.15960.fedora@krishnan.cc> <200808281124.49306.fedora@krishnan.cc> Message-ID: On 8/28/08, Rajesh Krishnan wrote: > Bryan, > > I have forked cabal-rpm (with due credits to you, and the code is still GPL) > that does generation of the Fedora specific SPEC file only, with the new > macros. That's fine; it was what I intended to do anyway. Please send me patches. > I chose to do that because there were too many changes I needed to > get some things right, and get rid of other stuff (like executing rpmbuild) > that were irrelevant for my purposes. > > I would publish the code once it becomes half stable and somewhat working. > > Please don't take this otherwise, as your code is absolutely great Haskell > work and I learned some finer Haskell coding styles while studying your > code. > > -Rajesh > > > > > > On 2008-08-28-Thu 06:44:05 am Bryan O'Sullivan wrote: >> On Thu, Aug 28, 2008 at 1:16 AM, Rajesh Krishnan >> wrote: >> >> If we're using cabal-rpm for packaging >> >> then we really don't need to add rpm macros IMHO. >> > >> > I am very much in favor of having good set of base macros (under >> > /etc/rpm/). >> >> I like to have both the macros and cabal-rpm, where the latter assumes >> the presence of the former. > > > From petersen at redhat.com Fri Aug 29 04:17:58 2008 From: petersen at redhat.com (Jens Petersen) Date: Fri, 29 Aug 2008 14:17:58 +1000 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <48B6525F.8050900@redhat.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> <48B5E95D.7070400@redhat.com> <48B5F0BB.2020908@redhat.com> <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> <48B6525F.8050900@redhat.com> Message-ID: <48B77876.50500@redhat.com> Jens Petersen ????????: > Below is a patch against darcs head which backports most of my changes > to the guidelines to cabal-rpm. If we're using cabal-rpm for packaging > then we really don't need to add rpm macros IMHO. Here is a slightly improved patch which also fixes rpmbuild and a few more tweaks that bring the output even closer to the current templates. But sounds like this may conflict with Rajesh's changes... :-( Jens From petersen at redhat.com Fri Aug 29 04:20:28 2008 From: petersen at redhat.com (Jens Petersen) Date: Fri, 29 Aug 2008 14:20:28 +1000 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <48B77876.50500@redhat.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> <48B5E95D.7070400@redhat.com> <48B5F0BB.2020908@redhat.com> <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> <48B6525F.8050900@redhat.com> <48B77876.50500@redhat.com> Message-ID: <48B7790C.8040702@redhat.com> Jens Petersen ????????: > Here is a slightly improved patch which also fixes rpmbuild and a few > more tweaks that bring the output even closer to the current templates. attached here -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cabal-rpm-fedora.patch2 URL: From petersen at redhat.com Fri Aug 29 04:28:41 2008 From: petersen at redhat.com (Jens Petersen) Date: Fri, 29 Aug 2008 14:28:41 +1000 Subject: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> Message-ID: <48B77AF9.7010008@redhat.com> (Late followup since I spent most of yesterday working on a cabal-rpm patch.) Yaakov Nemoy ????????: >>> * %buildsubdir is not a common way of doing things >>> ** we need this macro in the install phase to get at the working dir >>> we used to compile the package. >> This is not haskell specific and should really not be needed. >> Let's try to get rid of it. > > It's needed for the macros that do file detection later on. Once we > cd into the buildroot, we need a way of accessing the old dir we used > to compile the package. Therefore, I've put it in a macro, and both > sets of macros are mandatory. If you have a better solution, please > fix it. No it is not needed: you could use ${RPM_BUILD_DIR} for that if necessary (however see also the end of this mail). >> But how are packages supposed to get these macros? >> Surely each package is not going to include all of >> http://ynemoy.fedorapeople.org/haskell/macros.ghc ? > > That file is going to be packaged with ghc itself. I've submitted the > following bug. > https://bugzilla.redhat.com/show_bug.cgi?id=460304 Do any other packages (languages) in Fedora provide rpm macros? One of the things I always liked about fedora is that our spec files are self-contained unlike some other distros. Are we moving anyway from that? Also housing the macros in ghc means that if we need to change them then ghc needs to be rebuild which is a bit expensive - though hopefully that would be not necessary too often. >> The macros are not really that ghc specific: they should be prefixed cabal >> not ghc. > > Technically no, but I want to differentiate between what the > theoretical command might be for foo haskell compiler, and what > nuances there might be between compilers. I would prefer just a few macros suitable for cabal that would work across ghc, hugs, etc, than something very specific to ghc. >> IMHO some of it seems to be overkill. > > How so? For the most part, i'm converting the work that Bryan has > done into macros, and polished it up. Every step that's there is > stuff that Bryan has decided is necessary. I created some patches to cleanup cabal-rpm's output. I wish you had made clear earlier that that was where all this was coming from... if I had known that I could have cleaned it up much earlier... As I noted yesterday: I finally tried cabal-rpm and finally realised where all those macros are coming from. So sorry to Yaakov: it seems most of my quibbles have actually been with cabal-rpm! ;) I think I may submit a cabal-rpm package to fedora so that it can be included. IMHO a couple of self-contained spec templates are still quite sufficient for now and that is the way I am inclined to go. Packaging cabal packages is really not that hard, and to me hiding small incantation in obscure macros really does not buy use much at all. As long as packages follow the templates reviews should be just as straightforward. >> - if %ghc_autotools is necessary, can the -p option be made optional? > What should the default be? Profiling by default? I don't use profile much myself... what do others think? >> I attach an (untested) which cleans up the macro file a bit. > I've attached that to the bug report to add them to GHC. Thanks. There are still more changes that need to be made though. > >> * this file detection stuff is scary > >> ** I've put it into a series of macros and documented it > Ok, that might be useful. :) Has anyone other than me tested them though? The filelist macros in the ghc-X11 review do not work for me, and they seem to be the same as in the current macros... I just submitted a patch for it in ghc-X11 review https://bugzilla.redhat.com/show_bug.cgi?id=426751#c14 now. (Also in my cabal-rpm patches.) Jens From bugzilla at redhat.com Fri Aug 29 07:10:09 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 29 Aug 2008 03:10:09 -0400 Subject: [Fedora-haskell-list] [Bug 426753] Review Request: xmonad - A tiling window manager In-Reply-To: References: Message-ID: <200808290710.m7T7A9P3031453@bz-web1.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=426753 Jens Petersen changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|nobody at fedoraproject.org |petersen at redhat.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Fri Aug 29 07:18:45 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 29 Aug 2008 03:18:45 -0400 Subject: [Fedora-haskell-list] [Bug 426751] Review Request: ghc-X11 - A Haskell binding to the X11 graphics library. In-Reply-To: References: Message-ID: <200808290718.m7T7Ijud025224@bz-web2.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=426751 Jens Petersen changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |177841 Depends on|177841 | -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Fri Aug 29 07:17:37 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 29 Aug 2008 03:17:37 -0400 Subject: [Fedora-haskell-list] [Bug 426751] Review Request: ghc-X11 - A Haskell binding to the X11 graphics library. In-Reply-To: References: Message-ID: <200808290717.m7T7HbZv025049@bz-web2.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=426751 Jens Petersen changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |177841 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla at redhat.com Fri Aug 29 08:02:33 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 29 Aug 2008 04:02:33 -0400 Subject: [Fedora-haskell-list] [Bug 426751] Review Request: ghc-X11 - A Haskell binding to the X11 graphics library. In-Reply-To: References: Message-ID: <200808290802.m7T82Xdn001877@bz-web2.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=426751 --- Comment #15 from 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 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From fedora at krishnan.cc Fri Aug 29 09:34:52 2008 From: fedora at krishnan.cc (Rajesh Krishnan) Date: Fri, 29 Aug 2008 02:34:52 -0700 Subject: [Fedora-haskell-list] Re: Test package - Cabal-1.4.0.2 (using cabal_* macros). was: Re: [Fedora-packaging] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <48B73CD8.1080206@redhat.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <200808281520.35828.fedora@krishnan.cc> <48B73CD8.1080206@redhat.com> Message-ID: <200808290234.53458.fedora@krishnan.cc> > So do you have a specific package in mind? Well I don't have any specific example available just over the top of my head. But from what I know about Cabal file format , it should be quite trivial to create a package that has 1 library and more than 1 executable sections. Though I haven't come across any .cabal file with more than 1 library sections (and a single library section is almost always sufficient), the Cabal documentation does not state clearly if more than 1 library sections could be present or not (I just checked, though I haven't experimentally verified this). -Rajesh On 2008-08-28-Thu 05:03:36 pm Jens Petersen wrote: > Rajesh Krishnan ????????: > > For Hackage packages that contain only libraries, or a single executable, > > the package building specification is clear (name the RPM for library > > only package xyz as ghc-xyz, and name the RPM for a single executable > > package xyz as just xyz without the ghc prefix). > > The example corresponding to xmonad (which has both an executable and > library) is given in the guidelines: the base package name in that case > should be just "xmonad". > > > What would be the RPM name for a Hackage package xyz that contains > > multiple libraries and multiple executables? Is it OK to create a single > > RPM called xyz in for such a package, or do they necessarily need to be > > split up into multiple package fragments? Please explain if you could. > > Note that the number of such fragmented RPMs would multiply fast > > (creation of perhaps -prof and -doc etc. if applicable for each > > subpackage) . > > So do you have a specific package in mind? It is easier to discuss > concrete examples than hypothetical cases. :) > > Jens From fedora at krishnan.cc Fri Aug 29 09:44:48 2008 From: fedora at krishnan.cc (Rajesh Krishnan) Date: Fri, 29 Aug 2008 02:44:48 -0700 Subject: [Fedora-haskell-list] Re: Test package - Cabal-1.4.0.2 (using cabal_* macros). was: Re: [Fedora-packaging] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <48B76205.1060607@redhat.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <7f692fec0808281925o64575943p9287170264ab893e@mail.gmail.com> <48B76205.1060607@redhat.com> Message-ID: <200808290244.48466.fedora@krishnan.cc> > Actually we could face this problem immediately if Rajesh submits > haskell-Cabal, since it should really be packaged for both ghc and hugs98. The package I submitted earlier in this thread IS haskell-cabal. It is named ghc-cabal simply because I used ghc to compile it. Look at the macros.haskell that it depends on, and you will see what I mean. I can see Yaakov's point too, of having the macro file as macros.ghc which is specific to ghc. > Actually we could face this problem immediately if Rajesh submits > haskell-Cabal, since it should really be packaged for both ghc and hugs98. Wait a minute, Jens! You are asking for too much! At this time, I am not too much interested in getting into hugs98, and I don't plan test any packages I submit on Hugs or other Haskell platforms for now. But maybe in future others who join the team might want to create a specific set of packages for Hugs98. They would then have the freedom to create their specific macro file called macros.hugs and create and submit their favorite packages like hugs-.rpm or something. -Rajesh On 2008-08-28-Thu 07:42:13 pm Jens Petersen wrote: > Yaakov Nemoy ????????: > > 2008/8/28 Jens Petersen : > >> Yaakov Nemoy ????????: > >>> If we do this, then each 'library' package is going to have to support > >>> every single compiler we have. > >> > >> No they don't have to but they can if they want. :) > > > > It would be messy. > > > >>> I would rather have one SRPM per library per compiler. > >> > >> I thought we proposed "haskell-%pkg_name" exactly for this? > > > > Nope, that's why it's %haskell_compiler-%pkg_name exactly for this. > > Otherwise, we can only support one compiler without a lot of weird > > tricks. > > I quote from PackagingDrafts/Haskell...: > > "If a library supports multiple Haskell compilers or interpreters, the > base name should instead be prefixed with haskell, e.g. haskell-X11." > > So you want to withtract this? :) > > > (Granted, we could just include multiple macros for multiple compilers > > in a single spec file, and then build and publish a single RPM for > > each library that supports multiple compilers. I think this would > > lead to alot of bloat. Alternatively, we could have a single spec > > file per library, and have it generate multiple subpackages, one for > > each compiler. I would rather have one spec per compiler per > > library.) > > Well that is what they do in the Emacs Lisp world for Emacs and XEmacs > and it works: it is a really pain having to maintain parallel packages > for different compiler. > > Actually we could face this problem immediately if Rajesh submits > haskell-Cabal, since it should really be packaged for both ghc and hugs98. > > > AFAIK, the run time you use to run Setup.hs is the runtime that the > > library is compiled against. Namely, runhaskell that runs runghc > > would create a package for GHC. > > I don't think it matters since it is only "scripting" and cabal is > supposed to be portable Haskell98 presumably. > > Jens From fedora at krishnan.cc Fri Aug 29 10:00:08 2008 From: fedora at krishnan.cc (Rajesh Krishnan) Date: Fri, 29 Aug 2008 03:00:08 -0700 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <48B77AF9.7010008@redhat.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> <48B77AF9.7010008@redhat.com> Message-ID: <200808290300.08887.fedora@krishnan.cc> > self-contained unlike some other distros. Are we moving anyway from that? > > Also housing the macros in ghc means that if we need to change them then > ghc needs to be rebuild which is a bit expensive - though hopefully that > would be not necessary too often. This thread is getting even more confusing. :-( I think what Yaakov mentioned was that these macros would be used only for compiling Hackage/Cabal packages (and the like) and not for building the GHC compiler itself. Right Yaakov? For now I have decided to use a modified version of Yaakov's original macros.ghc file, and build a test package with it and submit it. Will keep everyone updated in the following mails. -Rajesh On 2008-08-28-Thu 09:28:41 pm Jens Petersen wrote: > (Late followup since I spent most of yesterday working on a cabal-rpm > patch.) > > Yaakov Nemoy ????????: > >>> * %buildsubdir is not a common way of doing things > >>> ** we need this macro in the install phase to get at the working dir > >>> we used to compile the package. > >> > >> This is not haskell specific and should really not be needed. > >> Let's try to get rid of it. > > > > It's needed for the macros that do file detection later on. Once we > > cd into the buildroot, we need a way of accessing the old dir we used > > to compile the package. Therefore, I've put it in a macro, and both > > sets of macros are mandatory. If you have a better solution, please > > fix it. > > No it is not needed: you could use ${RPM_BUILD_DIR} for that if > necessary (however see also the end of this mail). > > >> But how are packages supposed to get these macros? > >> Surely each package is not going to include all of > >> http://ynemoy.fedorapeople.org/haskell/macros.ghc ? > > > > That file is going to be packaged with ghc itself. I've submitted the > > following bug. > > https://bugzilla.redhat.com/show_bug.cgi?id=460304 > > Do any other packages (languages) in Fedora provide rpm macros? One of > the things I always liked about fedora is that our spec files are > self-contained unlike some other distros. Are we moving anyway from that? > > Also housing the macros in ghc means that if we need to change them then > ghc needs to be rebuild which is a bit expensive - though hopefully that > would be not necessary too often. > > >> The macros are not really that ghc specific: they should be prefixed > >> cabal not ghc. > > > > Technically no, but I want to differentiate between what the > > theoretical command might be for foo haskell compiler, and what > > nuances there might be between compilers. > > I would prefer just a few macros suitable for cabal that would work > across ghc, hugs, etc, than something very specific to ghc. > > >> IMHO some of it seems to be overkill. > > > > How so? For the most part, i'm converting the work that Bryan has > > done into macros, and polished it up. Every step that's there is > > stuff that Bryan has decided is necessary. > > I created some patches to cleanup cabal-rpm's output. I wish you had > made clear earlier that that was where all this was coming from... if I > had known that I could have cleaned it up much earlier... > > As I noted yesterday: I finally tried cabal-rpm and finally realised > where all those macros are coming from. So sorry to Yaakov: it seems > most of my quibbles have actually been with cabal-rpm! ;) > > I think I may submit a cabal-rpm package to fedora so that it can be > included. > > IMHO a couple of self-contained spec templates are still quite > sufficient for now and that is the way I am inclined to go. Packaging > cabal packages is really not that hard, and to me hiding small > incantation in obscure macros really does not buy use much at all. As > long as packages follow the templates reviews should be just as > straightforward. > > >> - if %ghc_autotools is necessary, can the -p option be made optional? > > > > What should the default be? > > Profiling by default? I don't use profile much myself... what do others > think? > > >> I attach an (untested) which cleans up the macro file a bit. > > > > I've attached that to the bug report to add them to GHC. > > Thanks. There are still more changes that need to be made though. > > > >> * this file detection stuff is scary > > >> ** I've put it into a series of macros and documented it > > > > Ok, that might be useful. :) > > Has anyone other than me tested them though? The filelist macros in the > ghc-X11 review do not work for me, and they seem to be the same as in > the current macros... > > I just submitted a patch for it in ghc-X11 review > https://bugzilla.redhat.com/show_bug.cgi?id=426751#c14 > now. (Also in my cabal-rpm patches.) > > Jens > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging From fedora at krishnan.cc Fri Aug 29 10:45:18 2008 From: fedora at krishnan.cc (Rajesh Krishnan) Date: Fri, 29 Aug 2008 03:45:18 -0700 Subject: [Fedora-haskell-list] Test package available for review -- Cabal-1.4.0.2 (rev2, using ghc_* macros in macros.ghc). In-Reply-To: <200808280250.47069.fedora@krishnan.cc> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> <200808280250.47069.fedora@krishnan.cc> Message-ID: <200808290345.18396.fedora@krishnan.cc> Yaakov, I have built ghc-cabal with a modified version of your macros.ghc file (link below). Here are the resulting packages. The following were tested with F8 and F9 (Did not test against Rawhide(F10) as I think rpmbuild on F10 has some issues related to buildroot resolution). RPM(x86_64 and -prof): http://krishnan.cc/devel/repository/fedora/RPMS/x86_64/ghc-cabal-1.4.0.2-2.fc9.x86_64.rpm http://krishnan.cc/devel/repository/fedora/RPMS/x86_64/ghc-cabal-prof-1.4.0.2-2.fc9.x86_64.rpm RPM(i386 and -prof): http://krishnan.cc/devel/repository/fedora/RPMS/i386/ghc-cabal-1.4.0.2-2.fc9.i386.rpm http://krishnan.cc/devel/repository/fedora/RPMS/i386/ghc-cabal-prof-1.4.0.2-2.fc9.i386.rpm SPEC: http://krishnan.cc/devel/repository/fedora/SPECS/ghc-cabal.spec SRPM: http://krishnan.cc/devel/repository/fedora/SRPMS/ghc-cabal-1.4.0.2-2.fc9.src.rpm macros.ghc: http://krishnan.cc/devel/repository/fedora/MISC/macros.ghc (This is the modified file with ghc_* style macros. Note that we ?need to place macros.ghc under /etc/rpm/ to successfully build with the above .spec). Let me know if you or anyone else has modified macros.ghc recently. It is a small file, so a quickly viewing this in Kompare along with the original should be easy enough to investigate the differences. Note that I foresee some more changes that might need to be introduced into macros.ghc as we gain more expertise in building other cabal packages. BTW, going forward, how would you like me to submit packages for review request? Using the Bugzilla, or any other means? I plan to maintain a link for all the packages I submit on my wiki page, for easy reference (its not there yet). -Rajesh On 2008-08-28-Thu 02:50:46 am Rajesh Krishnan wrote: > RPM(x86_64): > http://krishnan.cc/devel/repository/fedora/RPMS/x86_64/ghc-cabal-1.4.0.2-1. >fc9.x86_64.rpm > > RPM(i386): > http://krishnan.cc/devel/repository/fedora/RPMS/i386/ghc-cabal-1.4.0.2-1.fc >9.i386.rpm > > SPEC: > http://krishnan.cc/devel/repository/fedora/SPECS/ghc-cabal.spec > > SRPM: > http://krishnan.cc/devel/repository/fedora/SRPMS/ghc-cabal-1.4.0.2-1.fc9.sr >c.rpm > > macros.haskell: > http://krishnan.cc/devel/repository/fedora/MISC/macros.haskell > (This is the modified file with cabal_* style macros as proposed by Jens. > Note that we ?need to place macros.haskell under /etc/rpm to successfully > build with the above .spec).