Spec URL: http://web.cecs.pdx.edu/~danw/racket.spec SRPM URL: http://web.cecs.pdx.edu/~danw/racket-5.2.1-1.fc16.src.rpm Description: Racket (formerly called PLT Scheme) is a multi-paradigm programming language in the Lisp/Scheme family, that also serves as a platform for language creation, design, and implementation. The programming language is known for its powerful macro system which enables the creation of embedded and domain-specific languages, language constructs such as classes or modules, and separate dialects of Racket with different semantics.
See also https://bugzilla.redhat.com/show_bug.cgi?id=676124
I took over some packages from Gérard Milmeister in February 2011 because he no longer had time to maintain them (bigloo, clisp, ecl, ffcall, and polyml). Daniel, can you send email to Gérard asking him if he intends to proceed with the racket review? If not, or if he doesn't respond in a reasonable amount of time, then close bug 676124, and mark it as a duplicate of this bug. It is also worth comparing his spec file to yours.
At this point in time I have not heard back from Gérard so I must conclude that he does not have any interest in proceeding with the review. Given that that version 5.0.2 is a really old version that upstream is no longer supporting my inclination would be to close bug 676124. I am unable do this since I do not have the permissions needed to reassign or close the bug 676124 and I do not know who to contact to correct this. I looked at his spec file and incorporated a couple of things from it.
*** Bug 676124 has been marked as a duplicate of this bug. ***
I went ahead and closed the other bug since it's long since gone idle and there's no point in having two review tickets for the same thing. This package isn't really in my field of expertise but I'm just popping my head in here to try and get things moving Could you comment on the bundling issues mentioned in bug 676124? There seems to be come confusion about what URL: and the SourceN: tags are for. URL: should contain a URL for the upstream web site, so you can just visit it with your browser to get more information. Source0: should have the full URL to the tarball. Have you worked out with the rpm maintainers why disabling the debug package is necessary? This seems like a bug somewhere, and if you're going to do this you should at least be able to point to a filed bug or some mailing list discussion or something. No Fedora or EL release needs a %defattr line in any %files list. The first line of %install is unnecessary as well, since you're obviously not intending to support EL5. This package does not build with the mandatory set of compiler flags. You'll need to make it do so or include some justification for not doing so. Finally, the package fails to build for me in mock on rawhide. No idea what that's about: env XFORM_PRECOMP=yes ../racketcgc -cqu ../../../racket/gc2/xform.rkt --setup . --cpp "gcc -E -I./.. -I../../../racket/gc2/../include -pthread -DMZ_USES_SHARED_LIB " --keep-lines -o xsrc/precomp.h ../../../racket/gc2/precomp.c mprotect for generate-code page failed; aborting mprotect for generate-code page failed; aborting mprotect for generate-code page failed; aborting mprotect for generate-code page failed; aborting make[4]: Leaving directory `/builddir/build/BUILD/racket-5.2.1/src/build/racket/gc2' make[4]: *** [xsrc/precomp.h] Segmentation fault Here's a scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=4225863 However, it appears to fail in a different way then my mock build, so it's possible that several things are going wrong. Marking as not building. Please clear the Whiteboard field above if providing a version which builds.
I might be interested in helping. I've been sort of maintaining my own RPM of racket. I thought I'd look at your SPEC file and see what's different: I clicked the koji link in comment #5 but I don't see how to download your SRPM from there. Could you tell me how to get it?
Uh, the SRPM is linked in the original message, where it says "SRPM URL". At least that's the one that failed to build for me.
One obvious issue with the build that I see at http://kojipkgs.fedoraproject.org//work/tasks/5865/4225865/build.log is that Racket uses its own copy of libffi -- my guess is that there's a missing dependency that would get libffi installed, which should make Racket's build use it instead of its own. Also, JFYI, we are going to do a new release soon, so if anyone is working on it then it would be nice to start from that. (It's going to be a major release, probably going to v5.3.)
SPEC File URL: http://web.cecs.pdx.edu/~danw/racket.spec SRPM File URL: http://web.cecs.pdx.edu/~danw/racket-5.2.1-2.fc17.src.rpm I have created a new source package and spec file. The URL tag has been corrected. I am more used to the Gentoo Portage system that uses a similar URL tag to tell the emerge program where to fetch the file from. The %defattr tags were also removed from the spec file. The library bundling issue has been corrected by adding a dependency for libffi and adding an option to the configure command to force racket to use the library already installed in the system rather than the one packaged with racket. The other libraries mentioned in bug 676124 appear to have been replaced with scheme code long before this version of racket was released. At least that is what the comment left by Eli Barzilay in bug 676124 would indicate. The RPM debug package is still removed because the mred program is a stand-alone scheme program that has been turned into an executable. This process involves embedding the scheme code into a copy of the mzscheme executable. The result is two executable programs with the same build id. This does not strike me as a bug in RPM but rather a use case that was not considered when the build id rule was created. Unless someone knows how to change a build id number in an executable the RPM debug package is going to stay disabled. What do you mean this package does not build with the mandatory set of compiler flags? As far as I can tell if CFLAGS is set by RPM then the racket build process should use them. The new package completed the build but will not install during the mock build process. Looking at the build.log file I can't even tell what running when the process fails. The build log is at http://kojipkgs.fedoraproject.org//work/tasks/705/4240705/build.log but the relevant lines are: make[1]: Leaving directory `/builddir/build/BUILD/racket-5.2.1/src/build' make[1]: *** [install-3m] Aborted make: *** [install] Error 2 make: Leaving directory `/builddir/build/BUILD/racket-5.2.1/src/build' RPM build errors: error: Bad exit status from /var/tmp/rpm-tmp.nZ0dpY (%install) Bad exit status from /var/tmp/rpm-tmp.nZ0dpY (%install) Child returncode was: 1 EXCEPTION: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target i686 --nodeps builddir/build/SPECS/racket.spec'] Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/mockbuild/trace_decorator.py", line 70, in trace result = func(*args, **kw) File "/usr/lib/python2.6/site-packages/mockbuild/util.py", line 352, in do raise mockbuild.exception.Error, ("Command failed. See logs for output.\n # %s" % (command,), child.returncode) Error: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target i686 --nodeps builddir/build/SPECS/racket.spec'] LEAVE do --> EXCEPTION RAISED The build process works fine on my box so I have no way to track this failure down when I can't even see the command that is failing. I have disabled the x86_64 architecture for the moment to simplify debugging since my Fedora box is i686. Unless anyone has any idea how to get the information I need to fix this problem out of the mock build system this is as far as I can go.
The build failre is a little before these lines, where it says "about to suspend in atomic mode". I think that this is a problem that was fixed since 5.2.1 came out, so it's worth trying with the current sources. (Like I said, we've just started a new release now anyway.) There shouldn't be any problem with libraries now, and as long as there's a dependency on libffi there's not even a need to disable it in the configure line since it defaults to using the one in the system if it is found.
You can install your own mock. If you do that, you'll be able to use --shell to get into the installation directories and attack this problem. The particular failures you encountered, I believe, were because the build needs cairo, pango and gtk+ (at least) to work if you're building the docs (which seems to be done by default.) However, it only goes a step or two more before it dies again. Perhaps Eli can tell us (if you do not already know) the trick to get raco to be verbose, while we are looking for other missing packages for the mock environment. Later, you will also need, at build time, desktop-file-utils to make the desktop-file-install at the end work.
Created attachment 693153 [details] Racket 5.3.2 spec file
Comment on attachment 693153 [details] Racket 5.3.2 spec file I updated an old plt-scheme SRPM (from Fedora 12 I think, I've been keeping a personal SRPM around for a while) to Racket 5.3.2. I used that spec file as a starting point and incorporated changes from the one posted in comment 9. I've left quite a few BuildRequires in, but commented out which I had planned to remove upon successfully building with mock. It builds fine unless building with mock. In which case, the Racket build process provokes the ire of SELinux: SELinux is preventing /builddir/build/BUILD/racket-5.3.2/src/racket/.libs/lt-racketcgc from execmod access on the chr_file /dev/zero. I'm not sure if this is a bug in the Racket build process or, if not, how best to rectify it. I could allow that action on my system, but it doesn't seem like that'll pass muster. It's also still necessary to disable the debuginfo package as explained in comment 9.
The configure script src/racket/configure.ac does this: if test "${check_for_mprotect}" = "yes" ; then [ msg="for mmap and mprotect" ] AC_MSG_CHECKING($msg) AC_TRY_RUN( [ #include <sys/mman.h> ] [ #include <fcntl.h> ] int main() { void *p; p = mmap(0, 2 << 16, PROT_READ | PROT_WRITE, MAP_PRIVATE, open("/dev/zero", O_RDWR), 0); mprotect(p, 2 << 16, PROT_READ | PROT_WRITE | PROT_EXEC); return 0; }, use_mprotect=yes, use_mprotect=no, use_mprotect=no) AC_MSG_RESULT($use_mprotect) if test "${use_mprotect}" = "yes" ; then AC_DEFINE(HAVE_MMAP_MPROTECT,1,[Have mmap and mprotect]) fi fi That mprotect() call is what brings down the wrath of SELinux. Perhaps upstream could check for mmap() that accepts PROT_EXEC first, and only if that fails check for mprotect(). If you've got the former, you don't need the latter, and SELinux-enabled systems won't let you have the latter anyway.
That lead me to src/racket/src/salloc.c where HAVE_MMAP_PROTECT is used, and specifically to this code segment starting on line 1299 (in void* scheme_malloc_gcable_code()): { int r; r = mprotect ((void *) page, length, PROT_READ | PROT_WRITE | PROT_EXEC); if (r == -1) { scheme_log_abort("mprotect for generate-code page failed; aborting"); } } It appears to be that call to mprotect() causing the SELinux trouble and the mock build failures (the same errors as in comment 5). At least that's the only place that seems to produce the error message "mprotect for generate-code page failed; aborting".
If the mprotect() calls cannot be folded into mmap() calls, then an alternative is to talk to the SELinux people about writing policy for racket that allows it to call mprotect() with PROT_EXEC. I had to do that for the gcl package. Gcl allocates blocks of memory, then repurposes those blocks, so sometimes they need to be executable and sometimes not. There is no way to avoid using mprotect() to flip PROT_EXEC on and off with its memory management scheme, so we wrote a policy to create a gcl_exec_t type to allow that. I don't recommend it, but it is a possible avenue to take if all else fails.
Matthew had committed a change that might resolve this issue: http://git.racket-lang.org/plt/commitdiff/689b62a
That change just adds PROT_EXEC to the mmap() call. It does not remove PROT_EXEC from the mprotect() call. The latter is what causes SELinux denials.
I'm wondering what the status is here. Does 5.3.3 still fail to build in mock with selinux enabled? Travis, can you upload a full srpm (with the patch)? Daniel, are you still interested in maintaining this? If not (or if nothing is heard back), I'd consider taking a stab at it. I would like to see Racket in Fedora.
I reported in January that I had successfully built the current Racket on Fedora 17, but I only reported it to the E-mail address which shows when I hover over Daniel's name in this ticket. I admit I didn't follow up further as I was involved with other things (work). Here's what I said: "The only things that I added were additional BuildRequires lines: BuildRequires: libffi BuildRequires: libjpeg-turbo BuildRequires: cairomm ghostscript-fonts libgudev1 libev BuildRequires: libXtst picviz BuildRequires: gtk2 libfontenc libXfont BuildRequires: libXcomposite xorg-x11-font-utils BuildRequires: desktop-file-utils I have only tried F17. Since my only contribution has been persistence is searching for the missing packages, I thought I'd start by reporting these additional requirements to you and see where you want to go from here. I'd be absolutely fine with your carrying on from this point. It probably needs a little architecture love, since, even on x86_64, it puts the .so files into /usr/lib, rather than /usr/lib64. And those doc files are enormous. I haven't yet gone back to look at plt-scheme to see how it was broken up, but, as I understand it, racket is substantially changed from plt-scheme. I'm certainly willing to help in any direction that will of help. I have access to 32 and 64 bit Intel systems as well as 64 bit Power systems and can try builds and installations on F16, F17 and F18 (such as it is.)" I have different versions now but I'm still willing to help, althought I can't spend enough time on it to be maintainer.
Robert: Thanks for the info. Yeah, depending on what I hear in the next few days from other people in this ticket, I might take a stab at this. I think it would be nice to have Racket in Fedora.
So, that Racket that I built in January was 5.3.1. I downloaded the 5.3.3, changed my hacked spec file (I started with Daniel's) and tried again on Fedora 18. And, again, it built without trouble. To run it, I have had to put links in /usr/lib64 to the /usr/lib racket so's, but it does build and start with that change.
(In reply to comment #22) > So, that Racket that I built in January was 5.3.1. I downloaded the 5.3.3, > changed my hacked spec file (I started with Daniel's) and tried again on > Fedora 18. And, again, it built without trouble. > > To run it, I have had to put links in /usr/lib64 to the /usr/lib racket > so's, but it does build and start with that change. I have attempted to build 5.3.3 from the racket site. In the mock build system the racket build process actually completes. It still doesn't finish creating the .rpm files in the mock build process but I think I have a handle on that issue. I still have to get the thing to build for both i686 and x86_64. I am hoping to have a new source RPM this weekend. I am still in the process of testing some changes.
Glad to hear it. Thanks for your work on this! Look forward to trying out the rpm.
Daniel, perhaps this spec file will be of help: http://www.princeton.edu/~knight/fedora/racket.spec It was based on your original one. This may be the problem that the racket build process changes executables after they have been linked, running into problems with duplicate buildids.
5.3.4 is out now: http://blog.racket-lang.org/2013/05/racket-v534.html
Just changed the 5.3.3 to 5.3.4 in the spec, downloaded the new "Unix source" and rebuilt. It built for Fedora 18 x86_64 in mock as well, but I'll have to wait until morning to test it.
I have updated the racket package to version 5.3.3. I need people to test it and tell me how well it works. The files can be downloaded from the following URLs: http://web.cecs.pdx.edu/~danw/racket.spec http://web.cecs.pdx.edu/~danw/racket-5.3.3-1.fc18.src.rpm This package appears to compile in the mock build system for both 32 and 64 bit systems.
I was able to build your rpm on fedora 18 i686. My fractal drawing program seems to work properly with it. So far, so good...
Daniel: Works well (scratch build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=5372444 ), but upstream has 5.3.4 out now :) Hopefully an easy spec change?
(In reply to Daniel E. Wilson from comment #28) > I have updated the racket package to version 5.3.3. I need people to test > it and tell me how well it works. The files can be downloaded from the > following URLs: > > http://web.cecs.pdx.edu/~danw/racket.spec > http://web.cecs.pdx.edu/~danw/racket-5.3.3-1.fc18.src.rpm Builds and works fine for me on F17.
Some problems IMO: 1. Upstream has release 5.35 so far. Please update again. 2. Why do you preserve %{_libdir}/*.*a files? 3. %{_usr}/share/ should be replaced by %{_datadir} 4. Better replace all ${RPM_BUILD_ROOT} by %{buildroot} 5. desktop-file-install must not add vendor. Besides, I suggest you should desktop-file-validate the file(but don't do that in spec, just outside the building sandbox) 6. In build section, make should with %{?_smp_mflags} 7. All subpackages Requires tag should have %{_isa} 8. Please put the %define debug_package %{nil} at the top of the spec. And please don't use %define, please use %global. 9. # These are the old names for this program. Obsoletes: plt-scheme Obsoletes: drscheme Where are they now? In Fedora I cannot find either of them. 10. Group tag can be removed as Fedora doesn't need this.(optional) 11. Remove the "." in the Summary tag.
Updated package to use version 5.3.5 of Racket. Can be downloaded from the following URL: http://web.cecs.pdx.edu/~danw/racket.spec http://web.cecs.pdx.edu/~danw/racket-5.3.5-1.fc18.src.rpm I did make some the modifications that were suggested but not all of them. Those that I didn't implement seemed to not be a good idea in light of my interpretation of what the packaging guide had to say. For example, I am still using ${RPM_BUILD_ROOT} because the guide is neutral on the issue provided that I am consistent about using ${RPM_BUILD_ROOT} or the %{buildroot} macro. The same applies to the use of the %{_isa} macro which the guide does not also appear to recommend. I am leaving the debug_package macro where it is since there is a large comment explaining why it is there. I will naturally accept suggestions that will eliminate the need for that macro. I moved the the static libraries into a racket-static package because I have at times linked to static libraries during development of a program to make debugging easier. It is not intended that the static libraries would ever be used by anyone other than a developer and they should not be used in production code.
Hi, I believe that the /usr/lib64/racket/mzdyn3m.o file should be in the -devel package. It is used by extensions as per http://docs.racket-lang.org/inside/overview.html#%28part._3m_.Extensions%29 ... By the way, I have been using Racket built from your .spec file for some time and it seems to be OK. Fedora devs: what's the holdup?
> the %{_isa} macro which the guide does not also appear to recommend. Sure it does. https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package > Requires: cairo > Requires: pango > Requires: gtk2 > Requires: gtkmm24 > Requires: libffi > Requires: libjpeg-turbo https://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires > %{_libdir}/racket/buildinfo https://fedoraproject.org/wiki/Packaging:UnownedDirectories > %{_datadir} Certainly you do not want to include /usr/share, but only: %{_datadir}/* > %files static > %{_libdir}/*.la | Libtool archives, foo.la files, should not be included. | https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries Btw, libtool archive files are unrelated to static libraries, so putting them into a -static package would be wrong anyway.
(In reply to Michael Schwendt from comment #35) > > Requires: cairo > > Requires: pango > > Requires: gtk2 > > Requires: gtkmm24 > > Requires: libffi > > Requires: libjpeg-turbo > > https://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires I believe that the gui collection dlopens these. Well, except for libffi, that one should be removed from the requires.
Updated spec file for version 5.3.6 of racket. I moved the static libraries back into the racket-devel package. No doubt someone will complain about this but the upstream developer documentation makes it clear that these files are necessary for developing extensions for the racket interpreter. The racket documentation is huge and so it was easy to overlook, thanks Jan for the link. Jan is correct about the reason for the explicit dependences. The link for the source RPM file is: http://web.cecs.pdx.edu/~danw/racket-5.2.1-1.fc16.src.rpm
(In reply to Daniel E. Wilson from comment #37) > The link for the source RPM file is: > http://web.cecs.pdx.edu/~danw/racket-5.2.1-1.fc16.src.rpm The link is not working and seems to be another version. I believe that the static libraries were correctly placed in the -static package as the libracket3m.so is included in the main package and together with headers from -devel allows for racket embedding. Same goes for extensions, which only needed the additional .o file (now too in -devel) in order to link properly. Can you please revert the last change and continue using -static package for static libraries. They are only needed if someone wants to statically link with racket.
Sorry about that. Here is the correct one: http://web.cecs.pdx.edu/~danw/racket-5.3.6-1.fc16.src.rpm
(In reply to Daniel E. Wilson from comment #39) > Sorry about that. Here is the correct one: > http://web.cecs.pdx.edu/~danw/racket-5.3.6-1.fc16.src.rpm 500 Internal Server Error
(In reply to Daniel E. Wilson from comment #39) > Sorry about that. Here is the correct one: > http://web.cecs.pdx.edu/~danw/racket-5.3.6-1.fc16.src.rpm Hi, I saw f16 in the SRPM name, I guess you used Fedora 16 to generate the racket package, right? I hope you can use a Fedora 19 machine, or use Koji to scratch a build for rawhide. Thanks.
Let me point at https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries In case there are questions, please ask! [...] And: https://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires In particular: | When explicit library Requires are necessary, explicit library | dependencies should typically be arch-specific (unless the packages | involved are noarch) and there should be a spec file comment justifying it: That's why I mentioned this part of the packaging guidelines. The explanation _why_ there are explicit Requires needs to be added to the spec file as a comment. [...] When providing updated packages, please add a bugzilla comment with valid "Spec URL:" and "SRPM URL:" fields as you've done at the top of this ticket. Then give "fedora-review -b 808350" a try.
This is what I get for doing things late at night. I am using Fedora 18. Try this URL: http://web.cecs.pdx.edu/~danw/racket-5.3.6-1.fc18.src.rpm
Please file a bug against rpm about the build ID issue to get their take on it. This won't get addressed until a report is filed.
I'm also still seeing the build failure due to SELinux in mock. Has any work be done on this? This needs to get addressed.
This is the first I have seen of of any build bugs with SELinux. Could you e-mail the build log to me?
It's the same problem as reported in comment #5. http://www.cora.nwra.com/~orion/fedora/racket-build.log
Please paste an availale SPEC URL here so we can see what you've written instead of downloading 18M pack and open it. 1. # Disabled debug_package to fix the following error: # *** ERROR: same build ID in nonidentical files! # /usr/bin/mzscheme # and /usr/bin/mred %global debug_package %{nil} This might be a bug. As Orion said, please report. 2. -devel subpackage has: Requires: %{name} = %{version}-%{release}, automake First, %{name} = %{version}-%{release} should be: %{name}%{?_isa} = %{version}-%{release} Next, why requires automake? 3. I think this package's summary should be Racket Scheme Interpreter. But I'm not a native English speaker, I just changed bug summary to match the one being used in SPEC. 4. cp ${RPM_SOURCE_DIR}/plt-48x48.png ${RPM_BUILD_ROOT}%{_datadir}/pixmaps Can you tell me where does it come from? And you should cp with -a option to preserve timestamp. Also it's an icon of 48*48, I think it should be put under /usr/share/hicolor/icon/, if you want to put it under pixmaps, you'd better rename it to "plt" 5. %{_datadir}/man/man*/* --> %{_mandir}/man*/* 6. %{_datadir}/doc/* I think you should use %doc to mark files as docs. And I can see %{name}-%{version} in doc path, which has been changed in f20 to %{name} only.
(In reply to Orion Poplawski from comment #47) > It's the same problem as reported in comment #5. > http://www.cora.nwra.com/~orion/fedora/racket-build.log Also see comment 13 through comment 18.
(In reply to Christopher Meng from comment #48) > 6. %{_datadir}/doc/* > > I think you should use %doc to mark files as docs. I'm pretty sure rpm automatically marks everything in %{_datadir}/doc as %doc.
(In reply to Jerry James from comment #49) > (In reply to Orion Poplawski from comment #47) > > It's the same problem as reported in comment #5. > > http://www.cora.nwra.com/~orion/fedora/racket-build.log > > Also see comment 13 through comment 18. Indeed. The larger concern is not building the package but that racket works on SELinux enabled systems.
Has there been any progress on this issue?
Well, Racket builds fine for me with following files: Spec URL: https://anilinux.org/~mordae/racket/racket.spec SRPM URL: https://anilinux.org/~mordae/racket/racket-6.1.0.3-3.fc20.src.rpm It removes the problematic mred binaries and the static library. The only problem with the package is an issue with RPM's /usr/lib/rpm/check-buildroot that excludes Python and Emacs files but not Racket's compiled modules (*.zo). I have not tested the build with enforcing SELinux.
Hi D, I will close this review and submit my work to the queue after 1 week(one year after your last comment) because in more than 2 years you still stay in stage NEEDSPONSOR. This is ridiculous if racket can't be included in Fedora as someone can't continue packaging it.
(In reply to Christopher Meng from comment #54) > Hi D, > > I will close this review and submit my work to the queue after 1 week(one > year after your last comment) because in more than 2 years you still stay in > stage NEEDSPONSOR. > > This is ridiculous if racket can't be included in Fedora as someone can't > continue packaging it. At last someone is as frustrated as I am about this. Among other things, I have been working seven days a week for the last couple of months. This in itself would not have stopped me but evidence has been mounting for some that this was going nowhere. Given the increasing demands on my time and my inability to submit my work to the queue, it is irrational for me to put a high priority on this. There are two things that I am curious about. First, where did you get the idea that removing a program from a system as big as racket is a good idea? Making a users life more difficult strikes me as the sort of thing that Debian would do, one of the reasons I no longer use that distribution. Debian goes out their way to make things hard on their users. Second is what led you to the solution with the *.zo files. Bottom line is that as long as I am unable to submit my build I see no reason to spend any more time working on this. If this changes then I will be happy to continue, otherwise someone else will have to do it.
Here my latest version of the racket package version 6.1. Here is the the page for the spec file: http://s000.tinyupload.com/index.php?file_id=38337276796836710101 Here is the page to download the source RPM: http://s000.tinyupload.com/index.php?file_id=05827266922974593676 This wasn't my first choice of storage locations.
I've successfully built my SRPM in COPR, disabling /usr/lib/rpm/check-buildroot. Spec: http://anilinux.org/~mordae/racket/racket.spec SRPM: http://anilinux.org/~mordae/racket/racket-6.1.0.4-2.fc20.src.rpm COPR: http://copr.fedoraproject.org/coprs/mordae/racket/ I've fixed all relevant rpmlint complaints, but I won't fix the "#!r6rs" and non-executable script complaints (for the resulting binary packages) as these should be consulted with Matthew Flatt and rest of the Racket team. The package is now split into racket, -devel, -doc and -debuginfo.
I have an x86_64 system on which I could test the SELinux aspects of these builds. I'm not sufficiently familiar with Racket to know whether there's a "run all tests" operation that I could just launch, recording the results.
As I recall the problem with SELinux was a build error. After all, build-checkroot is a tool used in the Fedora build process. For some reason the racket site had their file incorrectly labeled as version 6.1 rather thanthe actual version of 6.0.1 and so I have corrected the spec file. I have updated the build with the correct version number. It would be best to stick with the version that has been officially released from the racket web site. This version among other things maintains the mred and mred-text executables by the use of links since the executables are identical to gracket and racket respectively. Page for the spec file: http://s000.tinyupload.com/index.php?file_id=87323174182019233579 Page for the source RPM: http://s000.tinyupload.com/index.php?file_id=34758987078146269583
(In reply to Daniel E. Wilson from comment #59) > As I recall the problem with SELinux was a build error. After all, > build-checkroot is a tool used in the Fedora build process. The problem with SELinux is described in comment 14 through comment 18. I just downloaded your source RPM to take a look. Nothing has changed in the source code to fix this problem. See http://www.akkadia.org/drepper/selinux-mem.html for more information.
I have sent an e-mail about this to one of the upstream developers. I copied you so that Eli would know to try to get the details from you since I don't use SELinux.
Ping! Any progress here?
So far, I have heard nothing on this issue. I do have version 6.2 and I will upload those files when I have the time. The only problem will be that as near as I can tell there is no way this package is getting into Fedora.
So does it have sense to persuede this review? You may get more attention if you start Copr project at: https://copr.fedoraproject.org and reopen this review when the SElinux issue settle down (if ever).
Closing per #63 and #64. If the SELinux issue ever settle down, please reopen.
*** This bug has been marked as a duplicate of bug 1301219 ***