On Sat, Oct 7, 2017 at 9:34 AM, Jerry James <loganjerry@xxxxxxxxx> wrote: > I don't believe that anybody looks at those pull requests on a regular > basis. Should somebody be doing so? There are 8 pull requests, > dating back to about the time of the above conversation. Five of > those don't contain a single comment. > > I opened one for gcl on July 29, and added a comment a month later > asking if somebody was going to look at it. No response. This is a > bit annoying, considering that I opened a bugzilla request asking for > the same thing 4 years ago, and no action has ever been taken on it. > I thought maybe a PR would finally get something to happen. Nearly a week has gone by, and no answer. I'm really stumped about what to do. Let me summarize the whole long saga and solicit help. GCL is a Common Lisp implementation. It is known for its speed compared to other CL implementations. It has a long lineage, summarized here: https://en.wikipedia.org/wiki/GNU_Common_Lisp. I took over maintenance of the package in late 2008 when the previous maintainer did not have time to continue. At that point, the package did not build in Rawhide and was slated to be dropped from Fedora soon. I got it working with help from upstream and Daniel Walsh, who provided advice on putting together an SELinux policy to account for the fact that GCL produces executable code on the fly by calling mprotect on selected pages. Fast forward to 2013. By that time, the GCL policy also had to mention maxima executables, since executables built with GCL also use the GCL memory allocator. I figured that meant it was time to merge the GCL policy into the system policy, and consequently opened a bugzilla ticket. In spite of me trying to reboot the conversation a couple of times, those involved who held the SELinux reins for Fedora, Just. Could. Not. Stay. On. Topic. We talked about the execheap permission in general, and its place in the universe. Some of them sneeringly, condescendingly wondered why upstream and I were both so incompetent that we didn't just rewrite the allocator to use mmap. (Hint: it isn't easy, and upstream isn't interested in the exercise.) After multiple failures on my part to get something to happen, I gave up in despair. Fast forward to 2017. Attempts to build maxima with gcl on aarch64 started hanging at package install time. See https://bugzilla.redhat.com/show_bug.cgi?id=1435395. This was blamed on gcl, incorrectly I believe. As I pointed out in the bug, nothing built from gcl sources runs at package install time, so the hang must be happening inside one of fixfiles, semodule, or restorecon, which ARE run from the gcl install scripts because GCL has to install its own SELinux policy, due to that policy not being merged into the system policy. So, policycoreutils maintainers! Something Is Afoot on aarch64! But that's not the end of the fun. GCL failed the mass rebuild this summer. It built successfully on every architecture but s390x. On s390x, the build failed due to a failed call to mprotect(), almost certainly a sign that SELinux was in enforcing mode on the builder. Was that a known issue with s390x builders? And, if so, has it been rectified since? If so, I'll try building again. I still want the system policy to account for GCL, in some way or another. But, as you can see from the quoted text above, submitting a pull request to the relevant git repository has resulted in months of <crickets chirping>. And pointing that out on this list last weekend has resulted in still more of the crickets. So ... what is a packager supposed to do???? Why is it so hard to get any attention for submissions to the system SELinux policy? There should be a barrier to entry; I understand that. But I can't even get the gatekeeper to have a conversation with me. Heeeeellllllppppp!!! Frustratedly yours, -- Jerry James http://www.jamezone.org/ _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
