Problems packaging Racket 8.0 for Fedora.

[danw1965]

For some reason the Chez Scheme executables seem to have the build root directory in them and as a consequence rpm will not complete building the package. I am including a copy of the racket.spec file so that you can see the commands that I am using to build and install Racket 8.0 with. I created a package with just the byte code version of racket and that works fine.

I don't know enough about your build system to figure out how these directories find their way in the executable gracketcs. Could really use some help here.

Here is the relevant Error:

• /usr/lib/rpm/check-buildroot
  Binary file /home/danw/rpmbuild/BUILDROOT/racket-8.0-2.fc32.x86_64/usr/lib64/racket/gracketcs matches
  Found '/home/danw/rpmbuild/BUILDROOT/racket-8.0-2.fc32.x86_64' in installed files; aborting
  error: Bad exit status from /var/tmp/rpm-tmp.EyFzW2 (%install)

I used the strings program to find the strings in the executable in gracketcs and here is the result:
-xnllanguage
-xrm
-singleInstance
bINARy tYPe:ris
%s: X Window System flag "%s" expects %d arguments, %d provided
[Replace me for EXE hack ]
BooT FilE OffsetS:
coNFIg dIRECTORy:/home/danw/rpmbuild/BUILDROOT/racket-8.0-2.fc32.x86_64/etc/racket

---

coLLECTs dIRECTORy:/home/danw/rpmbuild/BUILDROOT/racket-8.0-2.fc32.x86_64/usr/share/racket/collects

---

rktio_init
rktio_destroy
rktio_free
rktio_set_dll_path
rktio_get_dll_path
rktio_system_fd
rktio_fd_system_fd

racket.spec.txt

[mflatt]

That path should get replaced as one of the last steps of make install-cs DEST=.... via the fix-paths target, and I'm not clear on why it didn't work. But there's a different problem with make install install-cs ...., and the solution to that problem may also fix the fix-paths step.

The issue is that make install with a prefix is not set up to overlay BC on top of CS or vice versa. The ".zo" files for only one or the other will end up installed — whichever one installs last. Support for an overlay installation was only really intended for development, not for deployment.

For Gentoo, @tgbugs make it work anyway by staging either the CS or BC build to an intermediate directory, and then merging that to the main DESTDIR with something like cp -r -p.

[tgbugs]

So I actually have the same problem. For some reason when I was doing my test installation the build path did not get removed so the executables were not able to find coNFIg dIRECTORy and not able to find coLLECTs dIRECTORy. Those locations need to be updated one final time to match the final install location, DESTDIR still needs to be set to the sandboxed (aka build root) location so that calls to raco setup during build can succeed.

I have fixed the problem manually before by hand editing the binaries, but I can't seem to spot it now. A simple find and replace doesn't work because they are padded fields.

At one point I think I had found the right place to insert a second update to those two fields in the binaries, it sounds from what @mflatt is saying we might be able to run the fix-paths target again with the final DESTDIR set to the actual install location?

[danw1965]

I went ahead and set up the package for the Chez Scheme version with out the byte code interpreter and even with that change what I get is this error when I attempt to run racket. Considering that you want people to transition from the byte code interpreter to Chez Scheme this seems like an important issue.

[danw@grainne RPMS]$ racket
malformed fasl-object header in petite
malformed boot file petite
Aborted (core dumped)

When I check the strings I still find portions of the build root directory in the racket executable. Here is what I found.

coNFIg dIRECTORy:/etc/racket
mbuild/BUILDROOT/racket-8.0-1.fc32.x86_64/etc/racket

---

coLLECTs dIRECTORy:/usr/share/racket/collects
T/racket-8.0-1.fc32.x86_64/usr/share/racket/collects

---

At this point I am forced to conclude that these are symptoms of an underlying problem with your build system. It would figure that the Gentoo crowd would discover such a work around but not all packagers are willing to go to such lengths and the Fedora crowd are likely to have a problem with such methods. I very much doubt I could get that through their automatic package checking system for a start.

Here is the spec file for the Chez Scheme version.
racket.spec.txt

[mflatt]

In the light of a fresh day, I see that a gracket executable with a suffix (as in gracketcs) is not updated by the fix-paths step. (I think I lost the thread last night and started looking only at racket and racketcs). I've pushed a repair for that as 5e1df80. If it's worth patching v8.0 sources to install executables with a suffix, then a simpler patch would be to duplicate line 272 of "collects/setup/unixstyle-install.rkt" to try "gracketcs" and/or "gracketbc".

It's true that the fix-paths step can leave a tail of the DESTDIR path in the executable, since it only writes the new path and leaves trailing bytes as-is. That could be improved, but it's not new to CS.

I'm able to replicate the "malformed fasl-object" problem by running rpmbuild with your most recent "racket.spec.txt". The problem is that a step in rpmbuild strips the ".rackboot" ELF section from the racket executable. After some digging and searching (it seems that Rust has the same kind of issue) it appears that adding

%global _find_debuginfo_opts --keep-section .rackboot

to "racket.spec.txt" solves the problem.

[tgbugs]

Since I only have a minimal racket install working when building directly from the git repo I will report back here when the next snapshot build is available from https://www.cs.utah.edu/plt/snapshots/.

[danw1965]

Thank you @mflatt. That did the trick. The tail remnants of the build root directory are not causing a problem with my current incarnation of the racket package but that is just a happy accident. The hard part is getting the Fedora people to accept it but I now have a shot at it.

[tgbugs]

Reporting fixed on my end at Snapshot: 20210314-5e1df80 at 5e1df80.

[danw1965]

Just looked at the most recent snapshot build and the bug looks like it has been corrected from here. Thank you for your quick response @tgbugs and @mflatt. You guys are much easier to deal with than the Fedora crew which I will now have to contend with.

As far as I am concerned the bug is closed.