Bug 808350

Summary: Review Request: racket - Racket development system
Product: [Fedora] Fedora Reporter: Daniel E. Wilson <danw>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: cristian.ciupitu, danw, David.Feuer, eli, garrett.mitchener, gemi, i, jan.dvorak, knight, loganjerry, mikhail, mordae, msuchy, omajid, relrod, ricardof, sgraf, steve, travis.bugzilla, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-10-20 16:16:33 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
Racket 5.3.2 spec file none

Description Daniel E. Wilson 2012-03-30 04:18:09 EDT
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.
Comment 1 Eli Barzilay 2012-03-30 08:40:01 EDT
See also https://bugzilla.redhat.com/show_bug.cgi?id=676124
Comment 2 Jerry James 2012-03-30 13:39:53 EDT
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.
Comment 3 Daniel E. Wilson 2012-04-02 05:54:35 EDT
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.
Comment 4 Jason Tibbitts 2012-07-08 13:57:57 EDT
*** Bug 676124 has been marked as a duplicate of this bug. ***
Comment 5 Jason Tibbitts 2012-07-08 14:39:07 EDT
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.
Comment 6 Garrett Mitchener 2012-07-08 17:05:52 EDT
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?
Comment 7 Jason Tibbitts 2012-07-08 17:42:14 EDT
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.
Comment 8 Eli Barzilay 2012-07-09 19:38:13 EDT
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.)
Comment 9 Daniel E. Wilson 2012-07-15 02:24:48 EDT
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.
Comment 10 Eli Barzilay 2012-07-17 01:04:03 EDT
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.
Comment 11 Robert Knight 2012-09-07 08:27:35 EDT
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.
Comment 12 Travis Suel 2013-02-05 00:18:46 EST
Created attachment 693153 [details]
Racket 5.3.2 spec file
Comment 13 Travis Suel 2013-02-05 00:20:33 EST
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.
Comment 14 Jerry James 2013-02-05 10:17:33 EST
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.
Comment 15 Travis Suel 2013-02-06 10:00:56 EST
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".
Comment 16 Jerry James 2013-02-06 10:51:19 EST
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.
Comment 17 Eli Barzilay 2013-02-11 02:35:03 EST
Matthew had committed a change that might resolve this issue:

    http://git.racket-lang.org/plt/commitdiff/689b62a
Comment 18 Jerry James 2013-02-11 15:25:01 EST
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.
Comment 19 Ricky Elrod 2013-05-06 00:51:31 EDT
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.
Comment 20 Robert Knight 2013-05-06 05:22:05 EDT
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.
Comment 21 Ricky Elrod 2013-05-07 06:44:22 EDT
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.
Comment 22 Robert Knight 2013-05-07 08:19:22 EDT
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.
Comment 23 Daniel E. Wilson 2013-05-07 15:36:30 EDT
(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.
Comment 24 Ricky Elrod 2013-05-07 15:38:07 EDT
Glad to hear it. Thanks for your work on this! Look forward to trying out the rpm.
Comment 25 Robert Knight 2013-05-07 16:42:27 EDT
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.
Comment 26 Ricky Elrod 2013-05-08 18:59:11 EDT
5.3.4 is out now:
http://blog.racket-lang.org/2013/05/racket-v534.html
Comment 27 Robert Knight 2013-05-08 22:10:57 EDT
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.
Comment 28 Daniel E. Wilson 2013-05-13 04:09:40 EDT
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.
Comment 29 Garrett Mitchener 2013-05-13 15:12:56 EDT
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...
Comment 30 Ricky Elrod 2013-05-13 15:15:11 EDT
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?
Comment 31 Omair Majid 2013-05-30 19:25:16 EDT
(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.
Comment 32 Christopher Meng 2013-06-19 06:42:38 EDT
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.
Comment 33 Daniel E. Wilson 2013-06-23 22:54:18 EDT
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.
Comment 34 Jan Dvořák 2013-07-25 08:10:34 EDT
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?
Comment 35 Michael Schwendt 2013-07-26 03:21:03 EDT
> 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.
Comment 36 Jan Dvořák 2013-08-13 07:02:32 EDT
(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.
Comment 37 Daniel E. Wilson 2013-08-15 03:24:57 EDT
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
Comment 38 Jan Dvořák 2013-08-15 03:44:45 EDT
(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.
Comment 39 Daniel E. Wilson 2013-08-15 03:51:46 EDT
Sorry about that.  Here is the correct one:
http://web.cecs.pdx.edu/~danw/racket-5.3.6-1.fc16.src.rpm
Comment 40 Jan Dvořák 2013-08-15 04:35:45 EDT
(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
Comment 41 Christopher Meng 2013-08-15 04:42:29 EDT
(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.
Comment 42 Michael Schwendt 2013-08-15 06:16:14 EDT
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.
Comment 43 Daniel E. Wilson 2013-08-15 15:30:05 EDT
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
Comment 44 Orion Poplawski 2013-10-20 21:32:21 EDT
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.
Comment 45 Orion Poplawski 2013-10-20 21:44:51 EDT
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.
Comment 46 Daniel E. Wilson 2013-10-20 23:51:11 EDT
This is the first I have seen of of any build bugs with SELinux.  Could you e-mail the build log to me?
Comment 47 Orion Poplawski 2013-10-20 23:54:57 EDT
It's the same problem as reported in comment #5.  http://www.cora.nwra.com/~orion/fedora/racket-build.log
Comment 48 Christopher Meng 2013-10-21 06:36:32 EDT
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.
Comment 49 Jerry James 2013-10-21 09:47:22 EDT
(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.
Comment 50 Orion Poplawski 2013-10-21 11:30:26 EDT
(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.
Comment 51 Orion Poplawski 2013-10-21 11:31:40 EDT
(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.
Comment 52 David.Feuer 2014-05-21 02:34:15 EDT
Has there been any progress on this issue?
Comment 53 Jan Dvořák 2014-08-05 05:52:36 EDT
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.
Comment 54 Christopher Meng 2014-08-05 05:59:51 EDT
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.
Comment 55 Daniel E. Wilson 2014-08-06 05:19:56 EDT
(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.
Comment 56 Daniel E. Wilson 2014-08-08 04:33:13 EDT
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.
Comment 57 Jan Dvořák 2014-08-08 07:00:01 EDT
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.
Comment 58 Robert Knight 2014-08-08 12:05:28 EDT
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.
Comment 59 Daniel E. Wilson 2014-08-09 05:23:19 EDT
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
Comment 60 Jerry James 2014-08-09 14:22:52 EDT
(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.
Comment 61 Daniel E. Wilson 2014-08-09 16:45:56 EDT
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.
Comment 62 Miroslav Suchý 2015-07-21 09:29:27 EDT
Ping! Any progress here?
Comment 63 Daniel E. Wilson 2015-07-21 16:14:45 EDT
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.
Comment 64 Miroslav Suchý 2015-07-22 07:49:07 EDT
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).
Comment 65 Miroslav Suchý 2015-10-20 16:16:33 EDT
Closing per #63 and #64. If the SELinux issue ever settle down, please reopen.
Comment 66 Zbigniew Jędrzejewski-Szmek 2016-01-22 19:10:27 EST

*** This bug has been marked as a duplicate of bug 1301219 ***