[Bug 808350] New: Review Request: racket - Scheme Interpreter (Replacement for plt-scheme)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
Summary: Review Request: racket - Scheme Interpreter (Replacement for plt-scheme)
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Summary: Review Request: racket - Scheme Interpreter (Replacement for plt-scheme) Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: unspecified Component: Package Review AssignedTo: nobody@fedoraproject.org ReportedBy: danw@bureau-13.org QAContact: extras-qa@fedoraproject.org CC: notting@redhat.com, package-review@lists.fedoraproject.org Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: ---
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.
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=808350
Eli Barzilay eli@barzilay.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eli@barzilay.org
--- Comment #1 from Eli Barzilay eli@barzilay.org 2012-03-30 08:40:01 EDT --- See also https://bugzilla.redhat.com/show_bug.cgi?id=676124
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=808350
Jerry James loganjerry@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |loganjerry@gmail.com
--- Comment #2 from Jerry James loganjerry@gmail.com 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.
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=808350
Daniel E. Wilson danw@bureau-13.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |177841(FE-NEEDSPONSOR)
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=808350
--- Comment #3 from Daniel E. Wilson danw@bureau-13.org 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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Jason Tibbitts tibbs@math.uh.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gemi@bluewin.ch
--- Comment #4 from Jason Tibbitts tibbs@math.uh.edu --- *** Bug 676124 has been marked as a duplicate of this bug. ***
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Jason Tibbitts tibbs@math.uh.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tibbs@math.uh.edu Whiteboard| |BuildFails
--- Comment #5 from Jason Tibbitts tibbs@math.uh.edu --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Garrett Mitchener garrett.mitchener@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |garrett.mitchener@gmail.com
--- Comment #6 from Garrett Mitchener garrett.mitchener@gmail.com --- 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?
https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #7 from Jason Tibbitts tibbs@math.uh.edu --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #8 from Eli Barzilay eli@barzilay.org --- 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.)
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Daniel E. Wilson danw@bureau-13.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?
--- Comment #9 from Daniel E. Wilson danw@bureau-13.org --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Eli Barzilay eli@barzilay.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo? |
--- Comment #10 from Eli Barzilay eli@barzilay.org --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Robert Knight knight@princeton.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |knight@princeton.edu
--- Comment #11 from Robert Knight knight@princeton.edu --- 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.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #12 from Travis Suel travis.bugzilla@gmail.com --- Created attachment 693153 --> https://bugzilla.redhat.com/attachment.cgi?id=693153&action=edit Racket 5.3.2 spec file
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #13 from Travis Suel travis.bugzilla@gmail.com --- Comment on attachment 693153 --> https://bugzilla.redhat.com/attachment.cgi?id=693153 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.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #14 from Jerry James loganjerry@gmail.com --- 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.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=808350
Travis Suel travis.bugzilla@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |travis.bugzilla@gmail.com
--- Comment #15 from Travis Suel travis.bugzilla@gmail.com --- 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".
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #16 from Jerry James loganjerry@gmail.com --- 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.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #17 from Eli Barzilay eli@barzilay.org --- Matthew had committed a change that might resolve this issue:
http://git.racket-lang.org/plt/commitdiff/689b62a
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #18 from Jerry James loganjerry@gmail.com --- 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.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=808350
Ricky Elrod relrod@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |relrod@redhat.com
--- Comment #19 from Ricky Elrod relrod@redhat.com --- 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.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #20 from Robert Knight knight@princeton.edu --- 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.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #21 from Ricky Elrod relrod@redhat.com --- 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.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #22 from Robert Knight knight@princeton.edu --- 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.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #23 from Daniel E. Wilson danw@bureau-13.org --- (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.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #24 from Ricky Elrod relrod@redhat.com --- Glad to hear it. Thanks for your work on this! Look forward to trying out the rpm.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #25 from Robert Knight knight@princeton.edu --- 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.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #26 from Ricky Elrod relrod@redhat.com --- 5.3.4 is out now: http://blog.racket-lang.org/2013/05/racket-v534.html
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #27 from Robert Knight knight@princeton.edu --- 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.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #28 from Daniel E. Wilson danw@bureau-13.org --- 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.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #29 from Garrett Mitchener garrett.mitchener@gmail.com --- 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...
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #30 from Ricky Elrod relrod@redhat.com --- 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?
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Omair Majid omajid@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |omajid@redhat.com
--- Comment #31 from Omair Majid omajid@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Christopher Meng cickumqt@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cickumqt@gmail.com
--- Comment #32 from Christopher Meng cickumqt@gmail.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Daniel E. Wilson danw@bureau-13.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|BuildFails |
--- Comment #33 from Daniel E. Wilson danw@bureau-13.org --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Jan Dvořák jan.dvorak@techlib.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jan.dvorak@techlib.cz
--- Comment #34 from Jan Dvořák jan.dvorak@techlib.cz --- 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?
https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #35 from Michael Schwendt bugs.michael@gmx.net ---
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_Librari...
Btw, libtool archive files are unrelated to static libraries, so putting them into a -static package would be wrong anyway.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Christopher Meng cickumqt@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |danw@bureau-13.org Flags| |needinfo?(danw@bureau-13.or | |g)
https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #36 from Jan Dvořák jan.dvorak@techlib.cz --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Daniel E. Wilson danw@bureau-13.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(danw@bureau-13.or | |g) |
--- Comment #37 from Daniel E. Wilson danw@bureau-13.org --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #38 from Jan Dvořák jan.dvorak@techlib.cz --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #39 from Daniel E. Wilson danw@bureau-13.org --- Sorry about that. Here is the correct one: http://web.cecs.pdx.edu/~danw/racket-5.3.6-1.fc16.src.rpm
https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #40 from Jan Dvořák jan.dvorak@techlib.cz --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #41 from Christopher Meng cickumqt@gmail.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #42 from Michael Schwendt bugs.michael@gmx.net --- Let me point at
https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Librari...
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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Daniel E. Wilson danw@bureau-13.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|package-review@lists.fedora | |project.org |
--- Comment #43 from Daniel E. Wilson danw@bureau-13.org --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=808350
David.Feuer@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |David.Feuer@gmail.com
--- Comment #52 from David.Feuer@gmail.com --- Has there been any progress on this issue?
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Jan Dvořák mordae@anilinux.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mordae@anilinux.org
--- Comment #53 from Jan Dvořák mordae@anilinux.org --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Christopher Meng i@cicku.me changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(danw@bureau-13.or | |g)
--- Comment #54 from Christopher Meng i@cicku.me --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Daniel E. Wilson danw@bureau-13.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(danw@bureau-13.or | |g) |
--- Comment #55 from Daniel E. Wilson danw@bureau-13.org --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Orion Poplawski orion@cora.nwra.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|orion@cora.nwra.com |
--- Comment #56 from Daniel E. Wilson danw@bureau-13.org --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #57 from Jan Dvořák mordae@anilinux.org --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #58 from Robert Knight knight@princeton.edu --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #59 from Daniel E. Wilson danw@bureau-13.org --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #60 from Jerry James loganjerry@gmail.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #61 from Daniel E. Wilson danw@bureau-13.org --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Miroslav Suchý msuchy@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |msuchy@redhat.com Flags| |needinfo?
--- Comment #62 from Miroslav Suchý msuchy@redhat.com --- Ping! Any progress here?
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Daniel E. Wilson danw@bureau-13.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo? |
--- Comment #63 from Daniel E. Wilson danw@bureau-13.org --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=808350
--- Comment #64 from Miroslav Suchý msuchy@redhat.com --- 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).
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Miroslav Suchý msuchy@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Blocks|177841 (FE-NEEDSPONSOR) | Resolution|--- |DEFERRED Last Closed| |2015-10-20 16:16:33
--- Comment #65 from Miroslav Suchý msuchy@redhat.com --- Closing per #63 and #64. If the SELinux issue ever settle down, please reopen.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=177841 [Bug 177841] Tracker: Review requests from new Fedora packagers who need a sponsor
https://bugzilla.redhat.com/show_bug.cgi?id=808350
Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zbyszek@in.waw.pl Resolution|DEFERRED |DUPLICATE
--- Comment #66 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl ---
*** This bug has been marked as a duplicate of bug 1301219 ***
package-review@lists.fedoraproject.org
-
Red Hat Bugzilla