On Thursday 2010-09-23 02:30, Mr Dash Four wrote: > >>You willingly chose to use Redhat/Fedora. Now endure the pain! :-) > >I just wished I hadn't! 5 minutes ago I found yet ANOTHER bug - this >time in selinux-policy - the SELinux context on all iptables >executables is set wrong simply because whoever wrote the policy choose >the wrong location of these files - in FC13 they are all installed in >/sbin, but iptables.fc says /usr/sbin so the context is not set. Lovely >stuff! That starts to sounds like the project is run with an uncorrelated concurrent asynchronous interaction of the manus(es). Suggested anger management should involve the double-agent maintainer who was bribed to put iptables in /sbin in the first place. >> Sounds like another Fedora problem. I know it works in openSUSE, >> but that is probably because they make sure the custom string is >> actually _in_ the version (as evidenced by `uname -r`). > >So is on FC13 - I just checked and it is displayed - version + custom string. >The problem is that the scripts are actually looking for the kernel numbers, >ASSUMING there is nothing after it. How daft is that? (Oh I can tell tales too. The most recent one is a bug report that ended in pretty much "if you don't want to use the graphical installer, live with whatever strange decisions anaconda unilaterally did for you". But... I digress.) >[bugzilla.gentoo.org/325257] >I just found that out to my cost - need to download the patch, update >my source and rebuild the kernel again, then rinse, repeat with xtables >and hope that it I wonder. F13 ships with linux-glibc-devel-2.6.33, F14A with -2.6.35. So where is the actual issue? Nevertheless, I have devised a workaround for 2.6.34 headers. Check out xt-a's b5e2c7255a87f3d981968e21ea7f88401fe8f8ad and let me know. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
