From bugzilla at redhat.com Wed Feb 13 05:37:43 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 13 Feb 2008 00:37:43 -0500 Subject: [Fedora-haskell-list] [Bug 426751] Review Request: ghc-X11 - A Haskell binding to the X11 graphics library. In-Reply-To: Message-ID: <200802130537.m1D5bhfp011034@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 report. Summary: Review Request: ghc-X11 - A Haskell binding to the X11 graphics library. https://bugzilla.redhat.com/show_bug.cgi?id=426751 petersen at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fedora-haskell- | |list at redhat.com, | |petersen at redhat.com Summary|Review Request: ghc681-x11 -|Review Request: ghc-X11 - A |A Haskell binding to the X11|Haskell binding to the X11 |graphics library. |graphics library. ------- Additional Comments From petersen at redhat.com 2008-02-13 00:37 EST ------- IMHO we should follow the upstream naming and use "X11" not "x11". -- 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, or are watching someone who is. From bugzilla at redhat.com Wed Feb 13 05:47:59 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 13 Feb 2008 00:47:59 -0500 Subject: [Fedora-haskell-list] [Bug 426753] Review Request: xmonad - A tiling window manager In-Reply-To: Message-ID: <200802130547.m1D5lx9i031749@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 report. Summary: Review Request: xmonad - A tiling window manager https://bugzilla.redhat.com/show_bug.cgi?id=426753 petersen at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |426754 nThis| | -- 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, or are watching someone who is. From bugzilla at redhat.com Wed Feb 13 05:47:31 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 13 Feb 2008 00:47:31 -0500 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: Message-ID: <200802130547.m1D5lVYq031673@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 report. Summary: Review Request: ghc-X11-xft - Haskell bindings to the Xft, X Free Type interface library, and some Xrender parts https://bugzilla.redhat.com/show_bug.cgi?id=426752 petersen at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fedora-haskell- | |list 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, or are watching someone who is. From bugzilla at redhat.com Wed Feb 13 05:47:38 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 13 Feb 2008 00:47:38 -0500 Subject: [Fedora-haskell-list] [Bug 426753] Review Request: xmonad - A tiling window manager In-Reply-To: Message-ID: <200802130547.m1D5lcJM012761@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 report. Summary: Review Request: xmonad - A tiling window manager https://bugzilla.redhat.com/show_bug.cgi?id=426753 petersen at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fedora-haskell- | |list 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, or are watching someone who is. From bugzilla at redhat.com Wed Feb 13 05:46:22 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 13 Feb 2008 00:46:22 -0500 Subject: [Fedora-haskell-list] [Bug 426750] Review Request: ghc-utf8-string - Support reading and writing UTF8 Strings In-Reply-To: Message-ID: <200802130546.m1D5kMZN012604@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 report. Summary: Review Request: ghc-utf8-string - Support reading and writing UTF8 Strings https://bugzilla.redhat.com/show_bug.cgi?id=426750 petersen at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fedora-haskell- | |list 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, or are watching someone who is. From bugzilla at redhat.com Wed Feb 13 05:51:51 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 13 Feb 2008 00:51:51 -0500 Subject: [Fedora-haskell-list] [Bug 425882] Review Request: ghc-zlib - zlib bindings for ghc In-Reply-To: Message-ID: <200802130551.m1D5ppA6032505@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 report. Summary: Review Request: ghc-zlib - zlib bindings for ghc https://bugzilla.redhat.com/show_bug.cgi?id=425882 petersen at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fedora-haskell- | |list 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, or are watching someone who is. From bugzilla at redhat.com Wed Feb 13 05:48:22 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 13 Feb 2008 00:48:22 -0500 Subject: [Fedora-haskell-list] [Bug 426754] Review Request: ghc-xmonad-contrib - Third party extensions for xmonad In-Reply-To: Message-ID: <200802130548.m1D5mMQG031862@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 report. Summary: Review Request: ghc-xmonad-contrib - Third party extensions for xmonad https://bugzilla.redhat.com/show_bug.cgi?id=426754 petersen at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fedora-haskell- | |list 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, or are watching someone who is. From bugzilla at redhat.com Wed Feb 13 05:50:48 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 13 Feb 2008 00:50:48 -0500 Subject: [Fedora-haskell-list] [Bug 426753] Review Request: xmonad - A tiling window manager In-Reply-To: Message-ID: <200802130550.m1D5omAa013483@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 report. Summary: Review Request: xmonad - A tiling window manager https://bugzilla.redhat.com/show_bug.cgi?id=426753 petersen at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |426751 -- 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, or are watching someone who is. From bugzilla at redhat.com Wed Feb 13 05:50:35 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 13 Feb 2008 00:50:35 -0500 Subject: [Fedora-haskell-list] [Bug 426751] Review Request: ghc-X11 - A Haskell binding to the X11 graphics library. In-Reply-To: Message-ID: <200802130550.m1D5oZkR013433@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 report. Summary: Review Request: ghc-X11 - A Haskell binding to the X11 graphics library. Alias: ghc-X11 https://bugzilla.redhat.com/show_bug.cgi?id=426751 petersen at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Alias| |ghc-X11 -- 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, or are watching someone who is. From bugzilla at redhat.com Wed Feb 13 05:50:48 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 13 Feb 2008 00:50:48 -0500 Subject: [Fedora-haskell-list] [Bug 426751] Review Request: ghc-X11 - A Haskell binding to the X11 graphics library. In-Reply-To: Message-ID: <200802130550.m1D5omql013519@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 report. Summary: Review Request: ghc-X11 - A Haskell binding to the X11 graphics library. Alias: ghc-X11 https://bugzilla.redhat.com/show_bug.cgi?id=426751 petersen at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |426753 nThis| | -- 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, or are watching someone who is. From petersen at redhat.com Wed Feb 13 07:04:30 2008 From: petersen at redhat.com (Jens Petersen) Date: Wed, 13 Feb 2008 17:04:30 +1000 Subject: [Fedora-haskell-list] welcome Message-ID: <47B2967E.4020000@redhat.com> Hi, Welcome to the Fedora Haskell List of the Fedora Haskell SIG. I thought it would be useful to have a list for discussion related to haskell in Fedora and a forum for communication for our SIG. I have added this list to some of the current review bugs, but the idea is not to have this list flooded with bugzilla mails: if it gets too overwhelming perhaps we need to rethink that or even great a separate list for bugs. I guess the main initial focus should be agreeing on the packaging guidelines that Yaakov has started to draft and at the same starting to review some of the current submitted packages to test the draft. Jens From bos at serpentine.com Wed Feb 13 08:26:10 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed, 13 Feb 2008 00:26:10 -0800 Subject: [Fedora-haskell-list] Package guideline feedback Message-ID: <47B2A9A2.1010501@serpentine.com> Brief comments on http://fedoraproject.org/wiki/PackagingDrafts/Haskell > There are three types of packages: Library only, Library and Binary, and Binary only. The program cabal-rpm can generate a SPEC file suited to all three cases. The following templates are the output from cabal-rpm with a few minor changes. Actually, there are really only two: library and binary. Mixing libraries and binaries is deprecated, and we shouldn't support it. > Naming > > I need some input here. I am also not sure how we want to name our packages in CVS. For libraries, ghc-foo and hugs98-foo and nhc-foo and so on. For binaries, the plain name, as for other Fedora packages. > Questions > > * Where should libraries go? > > Libraries are stored at /usr/lib/ghc which is a symlink to the current version. It's actually a regular directory with a subdirectory per version. > * Some libraries (like X11) that are included with GHC are not the newest version. Some packages like xmonad need a newer version. Do we break apart the GHC package into multiple libraries that other packages can also update from other sources? > > I would love to do this. I can't tell who's making these comments. If you're commenting directly in the wiki, could you include your initials or something, so we can tell who's saying what? I'm not thrilled with the idea of splitting up ghc and the extralibs, because it's a pain to have to install a dozen packages after ghc itself on systems that do the split, like Debian. If we can come up with some scheme that does the split, but gets the whole lot installed in one go, then fine. It's also perfectly reasonable, as far as GHC is concerned, to have multiple versions of a package installed at once. > * How do we handle Haddock data? Do we mandate haddock packages go in -doc? -haddock? should we enforce special build time requirements to make sure all haddock packages hyperlink to one another? (I'm new to this, how do we make that work) > > More research is needed here. This will not make it into Fedora 9 most likely. Haddock should pick up links across packages properly by default. > * Using cabal-rpm, -debuginfo packages come up empty. Is something supposed to go in them? > > This is show stopping for the review process. I need someone's input on why this is happening. debuginfo packages shouldn't even be built. GHC doesn't emit DWARF debug data. > -devel sub-package > > Do we need them? No. > Binaries are packaged by their simple name. xmonad would remain xmonad, as would xmobar. This does not apply to the libraries that are included in the cabal package. A spec file for xmonad would generate two rpms, both of which are required for runtime, xmonad and ghc-xmonad. xmonad would require ghc-xmonad, but not vica versa. ghc-xmonad would contain a line in the description explaining that these are the libraries necessary for xmonad to run. > > Rationale: binary packages tend to become popular on their name alone, and sometimes people may be looking for a program not caring that it is written in Haskell or Brainfuck. If a package containing a binary named xmobar is named xmobar, as upstream calles the entire thing xmobar, xmobar will be the easiest way for the user to find the package. More to the point, a built binary doesn't depend on the compiler it was built with, so there's no reason to include the compiler name. > Good Haskell libraries should be as generic and algorithmic as possible. It's possible that someone may want to use an algorithm provided by a library such that when the upstream provider releases the project as a cabal package generating both binaries and libraries, we would want to treat the library component the same as any other Haskell library for the sake of that user. I cannot understand these sentences. > Documentation > > I have to do a bit of research on making Haddock interact correctly with all the other included packages. The biggest challenge is making sure all packages are hyperlinked to each other correctly. This may require an expensive post package install relinking phase for every Haskell library. I would like to avoid this, so it will involve some research. It ought to simply work. References: <47B2A9A2.1010501@serpentine.com> Message-ID: <7f692fec0802131929s270e3ed8k7900b04382c4efa5@mail.gmail.com> On Feb 13, 2008 3:26 AM, Bryan O'Sullivan wrote: > Brief comments on http://fedoraproject.org/wiki/PackagingDrafts/Haskell > > > There are three types of packages: Library only, Library and Binary, and Binary only. The program cabal-rpm can generate a SPEC file suited to all three cases. The following templates are the output from cabal-rpm with a few minor changes. > > Actually, there are really only two: library and binary. Mixing > libraries and binaries is deprecated, and we shouldn't support it. Ok, I understood this bit differently. xmonad uses a hybrid package however though, publishing parts of it as a binary and parts as a library. The cabal file should yield an rpm that builds two packages in this case, unless the xmonad guys plan on changing things. cabal-rpm already supports it, and as you probably know, my patches fix it up a bit. You say this is deprecated. My original goal is to get xmonad in fedora, so as long as xmonad keeps doing this, i'm going to try to support it as best as I can. > > Naming > > > > I need some input here. I am also not sure how we want to name our packages in CVS. > > For libraries, ghc-foo and hugs98-foo and nhc-foo and so on. > > For binaries, the plain name, as for other Fedora packages. Thanks for your input! > > > Questions > > > > * Where should libraries go? > > > > Libraries are stored at /usr/lib/ghc which is a symlink to the current version. > > It's actually a regular directory with a subdirectory per version. Ok, my error here. > > > * Some libraries (like X11) that are included with GHC are not the newest version. Some packages like xmonad need a newer version. Do we break apart the GHC package into multiple libraries that other packages can also update from other sources? > > > > I would love to do this. > > I can't tell who's making these comments. If you're commenting directly > in the wiki, could you include your initials or something, so we can > tell who's saying what? These are my comments. Sorry for the omission. > > I'm not thrilled with the idea of splitting up ghc and the extralibs, > because it's a pain to have to install a dozen packages after ghc itself > on systems that do the split, like Debian. I'm not sure which part you don't like. If GHC comes with libs foo and bar, I would suggest that the package ghc112 depends on foo >=1 and bar >=1.1. This way, 'yum install ghc' would pull in those two packages automatically. When a new version of foo comes out, we can install ghc-foo-1.1-1, and have it override the version that comes with GHC upstream. I am presuming we only want to support one version of a library at a time, which I am all for. If this doesn't work, then we'll have to do something else. While i'm on the topic of the ghc (and possibly other haskell compilers) package, I want to suggest a change as well. Currently cabal-rpm maintains a list of libraries and versions that are provided with a ghc compiler. This list needs to be maintained by hand. When generating an rpm spec file from a cabal file, it removes the dependency that resulting package has on those libraries, because it is known that it is included in the GHC main package. What if the GHC package were to 'provide' libraries such as 'ghc-foo' and 'ghc-bar' when it has them, so that we don't need this long list in cabal-rpm? Then, when yum tries to resolved those dependencies, ghc${ver} can provide them automatically. This gives us the added advantage in the edge case where a ghc package has been compiled without the extra libraries. Since it won't 'provide' those libraries, the administrator will know he needs a separate set of packages for those standard libraries. > If we can come up with some scheme that does the split, but gets the > whole lot installed in one go, then fine. Other than yum? > It's also perfectly reasonable, as far as GHC is concerned, to have > multiple versions of a package installed at once. Do we want to support this? > > * How do we handle Haddock data? Do we mandate haddock packages go in -doc? -haddock? should we enforce special build time requirements to make sure all haddock packages hyperlink to one another? (I'm new to this, how do we make that work) > > > > More research is needed here. This will not make it into Fedora 9 most likely. > > Haddock should pick up links across packages properly by default. I wasn't sure how well it worked. It's something I want to guarantee to work though, so I think we'll probably have bugs here, as all good software does. > > * Using cabal-rpm, -debuginfo packages come up empty. Is something supposed to go in them? > > > > This is show stopping for the review process. I need someone's input on why this is happening. > > debuginfo packages shouldn't even be built. GHC doesn't emit DWARF > debug data. Ok, best we instruct cabal-rpm not to generate spec files that build debug-info packages at all, and specify this is the guidelines. Thanks for the answer. > > -devel sub-package > > > > Do we need them? > > No. Also good to know. > > Binaries are packaged by their simple name. xmonad would remain xmonad, as would xmobar. This does not apply to the libraries that are included in the cabal package. A spec file for xmonad would generate two rpms, both of which are required for runtime, xmonad and ghc-xmonad. xmonad would require ghc-xmonad, but not vica versa. ghc-xmonad would contain a line in the description explaining that these are the libraries necessary for xmonad to run. > > > > Rationale: binary packages tend to become popular on their name alone, and sometimes people may be looking for a program not caring that it is written in Haskell or Brainfuck. If a package containing a binary named xmobar is named xmobar, as upstream calles the entire thing xmobar, xmobar will be the easiest way for the user to find the package. > > More to the point, a built binary doesn't depend on the compiler it was > built with, so there's no reason to include the compiler name. Sure, I was having fun being wordy that night. > > Good Haskell libraries should be as generic and algorithmic as possible. It's possible that someone may want to use an algorithm provided by a library such that when the upstream provider releases the project as a cabal package generating both binaries and libraries, we would want to treat the library component the same as any other Haskell library for the sake of that user. > > I cannot understand these sentences. This goes back to the possibility of a cabal file that ultimately yields both binary and library packages. The philosophy is to enable package developers to create packages that put as much code in library format and include a very slim binary package. I'm not sure what the design philosophy *should* be, so please advise. > > Documentation > > > > I have to do a bit of research on making Haddock interact correctly with all the other included packages. The biggest challenge is making sure all packages are hyperlinked to each other correctly. This may require an expensive post package install relinking phase for every Haskell library. I would like to avoid this, so it will involve some research. > > It ought to simply work. I hope so, but I want to make that a bullet item for testing. Thanks alot for your input! I'm glad you finally have some time for this :). -Yaakov From bugzilla at redhat.com Thu Feb 14 07:27:35 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 14 Feb 2008 02:27:35 -0500 Subject: [Fedora-haskell-list] [Bug 250767] RPMs for ghc-gtk2hs, ghc661-gtk2hs, won't install with 256 MB RAM In-Reply-To: Message-ID: <200802140727.m1E7RZ4B020058@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 report. Summary: RPMs for ghc-gtk2hs, ghc661-gtk2hs, won't install with 256 MB RAM https://bugzilla.redhat.com/show_bug.cgi?id=250767 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Version|f7 |7 petersen at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fedora-haskell- | |list 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, or are watching someone who is. From petersen at redhat.com Fri Feb 15 07:22:08 2008 From: petersen at redhat.com (Jens Petersen) Date: Fri, 15 Feb 2008 17:22:08 +1000 Subject: [Fedora-haskell-list] ghc doesn't build under gcc43 Message-ID: <47B53DA0.4050907@redhat.com> Yesterday I tried rebuilding ghc-6.8.2 for rawhide with gcc-4.3. It got all the way to the network libray before hitting: Socket.hsc: In function 'main': Socket.hsc:1144: error: invalid application of 'sizeof' to incomplete type 'struct ucred' Socket.hsc:1144: error: invalid application of 'sizeof' to incomplete type 'struct ucred' Socket.hsc:1144: error: invalid application of 'sizeof' to incomplete type 'struct ucred' Socket.hsc:1150: error: invalid use of undefined type 'struct ucred' Socket.hsc:1151: error: invalid use of undefined type 'struct ucred' Socket.hsc:1152: error: invalid use of undefined type 'struct ucred' Socket.hsc:2419: error: 'NI_MAXHOST' undeclared (first use in this function) Socket.hsc:2419: error: (Each undeclared identifier is reported only once Socket.hsc:2419: error: for each function it appears in.) Socket.hsc:2420: error: 'NI_MAXSERV' undeclared (first use in this function) compiling dist/build/Network/Socket_hsc_make.c failed The full buildlog is . I sent a mail to glasgow-haskell-users asking if anyone else has tried already. Otherwise we need to fix it for f9. Jens From petersen at redhat.com Fri Feb 15 09:29:31 2008 From: petersen at redhat.com (Jens Petersen) Date: Fri, 15 Feb 2008 19:29:31 +1000 Subject: [Fedora-haskell-list] Package guideline feedback In-Reply-To: <47B2A9A2.1010501@serpentine.com> References: <47B2A9A2.1010501@serpentine.com> Message-ID: <47B55B7B.1010002@redhat.com> Bryan O'Sullivan wrote: > Brief comments on http://fedoraproject.org/wiki/PackagingDrafts/Haskell : >> This is show stopping for the review process. I need someone's input on why this is happening. > > debuginfo packages shouldn't even be built. GHC doesn't emit DWARF debug data. Right, and at least in some of the haskell packages we explicitly disable debuginfo. That could probably be included in a sample haskell spec file. >> -devel sub-package >> >> Do we need them? > > No. Agree, probably not - at least non to date. Though I was tinkering a little recently with the idea of put .a files into -devel and .o files into the library packages, but I am not sure yet if it makes full sense or would be useful. Perhaps we should ship .o files anyway rather than generating them at install time. Jens From opensource at till.name Fri Feb 15 09:46:02 2008 From: opensource at till.name (Till Maas) Date: Fri, 15 Feb 2008 10:46:02 +0100 Subject: [Fedora-haskell-list] ghc doesn't build under gcc43 In-Reply-To: <47B53DA0.4050907@redhat.com> References: <47B53DA0.4050907@redhat.com> Message-ID: <200802151046.11275.opensource@till.name> On Fri February 15 2008, Jens Petersen wrote: > Yesterday I tried rebuilding ghc-6.8.2 for rawhide with gcc-4.3. > > It got all the way to the network libray before hitting: > Socket.hsc:2419: error: 'NI_MAXHOST' undeclared (first use in this There are several packages that do not build anymore because of this: https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01220.html Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From loupgaroublond at gmail.com Fri Feb 15 15:17:54 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Fri, 15 Feb 2008 10:17:54 -0500 Subject: [Fedora-haskell-list] Package guideline feedback In-Reply-To: <47B55B7B.1010002@redhat.com> References: <47B2A9A2.1010501@serpentine.com> <47B55B7B.1010002@redhat.com> Message-ID: <7f692fec0802150717i9585dfdsf7cce430d60469eb@mail.gmail.com> On Fri, Feb 15, 2008 at 4:29 AM, Jens Petersen wrote: > >> -devel sub-package > >> > >> Do we need them? > > > > No. > > Agree, probably not - at least non to date. Though I was tinkering a > little recently with the idea of put .a files into -devel and .o files > into the library packages, but I am not sure yet if it makes full sense > or would be useful. Perhaps we should ship .o files anyway rather than > generating them at install time. The analogy between the two is slim, but the Python spec does things the other way around, where the .o files are not generated until install time. This has to do with the nature of source code in python. Which ever method we utilize, we have precedent for both. I would like to encourage the notion though that Haskell is more like Python than in C, so we can interest a variety of high level programmers. From bugzilla at redhat.com Sun Feb 17 23:36:16 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 17 Feb 2008 18:36:16 -0500 Subject: [Fedora-haskell-list] [Bug 425882] Review Request: ghc-zlib - zlib bindings for ghc In-Reply-To: Message-ID: <200802172336.m1HNaGNM002767@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 report. Summary: Review Request: ghc-zlib - zlib bindings for ghc https://bugzilla.redhat.com/show_bug.cgi?id=425882 ------- Additional Comments From loupgaroublond at gmail.com 2008-02-17 18:36 EST ------- With much further ado, here is an updated version of the package. It should be closer to what the final spec is going to look like. SRPM: http://ynemoy.fedorapeople.org/review/ghc-zlib-0.4.0.2-2.fc8.src.rpm spec: http://ynemoy.fedorapeople.org/review/ghc-zlib.spec Reviewing it will probably have to work like this. This file is going to closely match the Haskell Packaging Guidelines draft. (in fact so closely, that the actual text of this spec file will be linked to it, as an example.) This package needs to be checked against the rest of the review processes and rules. If there are any conflicts between this and the review rules, we'll edit the draft to match something more correct. The same applies to other issues or problems. -- 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, or are watching someone who is. From loupgaroublond at gmail.com Sun Feb 17 23:41:55 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sun, 17 Feb 2008 18:41:55 -0500 Subject: [Fedora-haskell-list] Progress Update: 17th February 2008 Message-ID: <7f692fec0802171541q23b92f16s2ed0cb0257710556@mail.gmail.com> Hey List, I've been doing some work on the haskell guidelines this weekend. * Some of the comments from this list that seemed relevant to guidelines directly have been copied over and attributed * Some of the comments have been properly attributed * The guidelines have been edited for clarity or based on new knowledge * I have some minor patches for cabal-rpm to fix a few of the random criticisms I've received, i'll send them up in a bit * I've repackaged zlib as a sample library package, and updated the review request to reflect this * I have not yet packaged the newest version of xmonad. Hopefully I'll have this done before my trip :/ * Probably other stuff I just can't remember Anyways, please poke around if you have the time and pass along comments. -Yaakov