[Fedora-haskell-list] [Bug 517366] Review Request: emacs-haskell-mode - Haskell editing mode for Emacs
by Red Hat Bugzilla
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=517366
Chitlesh GOORAH <chitlesh(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|nobody(a)fedoraproject.org |chitlesh(a)gmail.com
Flag|fedora-review? |fedora-review+
--- Comment #36 from Chitlesh GOORAH <chitlesh(a)gmail.com> 2009-12-19 13:24:22 EDT ---
- MUST: The package is named according to the Package Naming Guidelines.
- MUST: The spec file name matches the base package emacs-%{name}
- MUST: The package meets the Packaging Guidelines.
- MUST: The package is licensed with an open-source compatible license and meet
other legal requirements as defined in the legal section of Packaging
Guidelines.
- MUST: The License field in the package spec file matches the actual license.
- MUST: The spec file must be written in American English.
- MUST: The spec file for the package is be legible.
- MUST: The sources used to build the package must matches the upstream source,
as provided in the spec URL.
- MUST: The package successfully compiles and builds into binary rpms on at
least i686.
- MUST: All build dependencies is listed in BuildRequires.
- MUST: The spec file handles locales properly. Emacs-haskell-mode does not
have
any.
- MUST: If the package does not contain shared library files located in the
dynamic linker's default paths. Emacs-haskell-mode does not have any.
- MUST: the package is not designed to be relocatable
- MUST: the package owns all directories that it creates.
- MUST: the package does not contain any duplicate files in the %files listing.
- MUST: Permissions on files are set properly.
- MUST: The package has a %clean section, which contains rm -rf %{buildroot}
(or $RPM_BUILD_ROOT).
- MUST: The package consistently uses macros, as described in the macros
section of Packaging Guidelines.
- MUST: The package contains code, or permissible content. This is described in
detail in the code vs. content section of Packaging Guidelines.
- MUST: There are no Large documentation files. Emacs-spice-mode does not have
any.
- MUST: %doc does not affect the runtime of the application. To summarize: If
it is in %doc, the program must run properly if it is not present.
- MUST: There are no Header files or static libraries
- MUST: The package does not contain library files with a suffix
- MUST: Package does NOT contain any .la libtool archives
- MUST: Package containing GUI applications includes a %{name}.desktop file,
and that file must be properly installed with desktop-file-install in the
%install section.
- MUST: Package does not own files or directories already owned by other
packages.
SHOULD Items:
- SHOULD: mock builds successfully in i686.
- SHOULD: The reviewer tested that the package functions as described. A
package should not segfault instead of running, for example.
- SHOULD: No scriptlets were used, those scriptlets must be sane.
APPROVED
--
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.
14 years, 4 months
[Fedora-haskell-list] [Bug 547997] New: rpmbuild -bs became more strict and chokes on undefined macros in Requires
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: rpmbuild -bs became more strict and chokes on undefined macros in Requires
https://bugzilla.redhat.com/show_bug.cgi?id=547997
Summary: rpmbuild -bs became more strict and chokes on
undefined macros in Requires
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: medium
Component: rpm
AssignedTo: pmatilai(a)redhat.com
ReportedBy: petersen(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: pmatilai(a)redhat.com, jnovy(a)redhat.com,
ffesti(a)redhat.com, fedora-haskell-list(a)redhat.com
Classification: Fedora
Target Release: ---
Description of problem:
I can understand on BuildRequires but rpm now seems to need
to be able to expand macros in Requires to build srpms?
Version-Release number of selected component (if applicable):
4.8.0-0.beta1.3
How reproducible:
every time
Steps to Reproduce:
1. use macro like %ghc_version not defined in rpm or redhat-rpm-config (base)
in package .spec file
2. try to build in dist-f13 in koji
3. job fails while generating srpm
Actual results:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1874770
Expected results:
Be allowed like in dist-f12?
Additional info:
We need ghc macros in rpm or redhat-rpm-config like we have for ocaml.
See ghc-rpm-macros package for %ghc_version and more.
Without fixing this we can't build ghc library packages for rawhide
and ghc-6.12.1 was just released so we need to rebuild them all.
--
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.
14 years, 4 months
Re: [Fedora-haskell-list] Need adding to the list
by Jens-Ulrik Petersen
Oops missed this too.
----- "Bryan O'Sullivan" <bos(a)serpentine.com> wrote:
> Could whoever owns the list please whitelist bos(a)fedoraproject.org ? I get bounces every time I do something in CVS.
It is a "known" problem (to me anyway) and I got so used to...
(It is caused by the haskell-sig on packages in Package DB
we should ask fedora infrastructure what to do about it
though now is probably not the best time...)
I talked to the infrastructure guys and it should be better
now but cvs commits are not reaching the list yet so
it needs to be tweaked a bit more.
Jens
14 years, 4 months
Re: [Fedora-haskell-list] RFE: GHC packaging improvement proposal
by Jens-Ulrik Petersen
Hi Lorenzo,
and welcome to the SIG! :) Just noticed your mail.
> I am a newcomer to Haskell (thanks to xmonad) and I plan to do some
> serious things with it (as soon as I get proficient with this elegant FP
> language).
Great (BTW I just pushed xmonad-0.9 into f12-testing - should appear soon.)
> During the last two-three weeks I've been secretly working on the GHC
> package (6.12). As you know, GHC can now create shared libraries so I deemed
> that a little change in the .spec file was necessary.
Okay cool - better not to work in secret though :) -
I think the current ghc.spec in pkg cvs already supports shared libs
quite a bit now but look forward to looking at your ideas. :)
> * ghc: contains only the compiler, tools (such as ghc-pkg, etc) and
> libHSrts.a which seems to be (statically) linked in every application.
> In general: stuff needed only at compile time.
Yeah but I have seen ghc package install errors when static libs
are not around - probably something that upstream needs to fix.
> * ghc-libs (and ghc-libs-static): contains the dynamic version of
> libHSghc
> which is *HUGE* (and I guess it's needed only by programs which want
> to access
> GHC internals -- I don't have it installed and xmonad, xmobar and such
> things work).
Cool - guess we could have done that long ago...
> * ghc-common: This subpackage contains packages.d/*.config files and
> owns core library directories, it is (mostly) empty and is required by
> ghc-runtime and ghc-runtime-static.
> * ghc-runtime (and ghc-runtime-static): nothing to say, it contains
> just the core libraries and their interface files (.hi/.dyn_hi)
I think shared libs and interfaces should be separated.
> + cabal-install 0.7.5 (from darcs) seems to work decently with this
That's right.
> + I decided to take libHSghc off the runtime package(s) because of
> its huge size and because it is not generally needed by other
> libraries/applications, thus making the runtime package small:
Aha good idea.
> I still can't get Cabal to link shared libraries instead of static
Pass the option "--ghc-option=-dynamic" to cabal configure.
> http://gitorious.org/lvillani/specs/blobs/master/haskell/ghc/ghc.spec
> + I'm 101% sure that there are errors in that .spec file.
It is shame you branched off 6.12.0.20091010-2.fc13, Bryan and
I committed quite few changes in cvs since then. I know cvs is not
a DVCS - fedora pkg cvs may be moving to git next year... :)
The current spec file works for rc2 anyway and provides shared
libraries.
Going to look through your spec file now.
In future it would be helpfil if you could send us a patch or
put it into bugzilla if you like and I can review and integrate
to cvs.
And join us on freenode #fedora-haskell if you care for irc.
Thanks, Jens
14 years, 4 months