I've just tested the actual feature release 1.5.33 of openafs. Kernel module (against 2.6.22-vs2.2.0.7-gentoo) and openafs utils build fine. I would like to see a "-Wno-strict-prototypes" in cf/osconf.m4 because there are a lot of warnings because of prototypes like: extern int afs_setpag(); with empty parameter lists. (the same situation in 1.4.x) @stefaan: Can I support you in any way to get the new release into the tree? I didn't append the ebuilds because I didn't need to edit just to rename them. What's the reason for hardmask 1.5.x in /usr/portage/profile/portage.mask? Wouldn't it be enough to set ~arch? tanks in advance, mueli
Hi Michael, you've probably noticed that the release notes for OpenAFS 1.5.x read: "the recommend production ready release of OpenAFS is 1.4.x" or similar. Also, my own tests (some while ago) indicated problems when combining 1.5.x and 1.4.x servers. In any case, I wouldn't want to put any 1.5.x in the stable tree. And everything that ends up in ~arch, is meant to be tested for introduction into stable. That's why I've always hard masked the 1.5.x releases. I've added 1.5.33 to the tree (even though it didn't seem to compile on my 2.6.24 kernel). I haven't looked further at your "-Wno-strict-prototypes" suggestion, as I currently don't have much time. I will reconsider this at a later moment. Thank you very much for your report and suggestions, Stefaan
Thx for your fast reply! If it is ok for you (and not wasted time of me - it's easier for you to judge this) i would implement and test a patch to reduce the noisy warnings on openafs in the next days. If you say that makes no sense than it's ok for me too - I would say this could also be a benefit for 1.4.x. I'll also try to compile it on 2.6.24 - I haven't tried it yet. I acknowledge the fact of hardmasking 1.5.x - I must recognize that I don't have your experience on mixing openafs versions. g, mueli
(In reply to comment #2) > If it is ok for you (and not wasted time of me - it's > easier for you to judge this) i would implement and test a patch to reduce the > noisy warnings on openafs in the next days. If you say that makes no sense than > it's ok for me too - I would say this could also be a benefit for 1.4.x. If you tackle the real reason behind the warnings, instead of just trying to suppress them, I think that would be a benefit to the source code and something they would probably be happy to accept upstream. If your changes would result in code that cannot be compiled on some compilers, adding a compiler flag may be a sensible option (don't know if any such case exists, haven't looked into this). Thanks, Stefaan
> If you tackle the real reason behind the warnings, instead of just trying to > suppress them, I think that would be a benefit to the source code and something > they would probably be happy to accept upstream. Perhaps it's possible with the usage of preprocessor macros to define the function prototypes as clear as the gcc requires. I'll have a look on that. I do acknowledge to not suppress the warnings even though they make it hard to debug the code.... we'll see what's possible. Can I leave the bug open until I can (or can not) provide a patch for the strict-prototype warnings? The next week is already fully planned so it will last a bit until I can have a look on the topic. g, mueli
(In reply to comment #4) > Can I leave the bug open until I can (or can not) provide a patch for the > strict-prototype warnings? The next week is already fully planned so it will > last a bit until I can have a look on the topic. Sure thing. It would be a mistake to close bugs when they are being worked on. It would also be a mistake to deny someone's efforts if they take longer than a couple of days, I could as well be resigning from Gentoo in that case :)
*** Bug 311451 has been marked as a duplicate of this bug. ***
it would be nice if this request get solved soon. its posted in 2008. :)) thx
Created attachment 246514 [details] Patch-Files for 1.5.77 Modified Patchset to work with 1.5.77 The ebuild can be created by just renaming the file and changing the patchset to 17
With the 1.5.77-version openafs(,-kernel) even compiles and runs with my hardened 2.6.34 kernel
what about kernel 2.6.36x? all failed
1.6 pre2 has been released meanwhile, which builds fine against 2.6.37.x kernels (at least on my ARM Debian box). Please bump version.
well if someone want to test in the bleeding-edge overlay are some working ebuild which is up to date. i have no clue what the develop in portage is waiting for. this request is from 2008 and in portage is currently release 1.4x. and a not working hard masked ebuild. for anyone who no anymore want to waiting : emerge layman layman -a bleeding-edge emerge -uDN world and all is fine
From what I can see in portage, the lastest afs test release is 1.5.34. Prior to seeing this thread, I twiddled that ebuild to run several later test releases, the last being 1.5.78, though I was running it unpatched, not seeing your patchset. At some point in there, I quit the testing release and moved to 1.4.14. This week I found that the 1.4.14 kernel module won't build against 2.6.38, so I decided to resurrect my testing branch and move it to 1.6_pre3. (I don't really understand the ebuild naming convention, so I've kludged it up, hard-coding the path to the tarball.) There's nothing special about it at all, simplest tweaks possible, basically skipping patching and accepting upstream. In the process of writing this comment, I decided to double-check what is happening. At about this point I realize that I don't know enough about ebuilds to patch together the whole set of naming conventions for a _pre package that adds "-kernel" to the main package name. Does anyone have an ebuild for the 1.6_pre series OpenAFS?
Those who feel adventurous may want to give openafs-1.6.0_pre3 a try. I haven't gotten to testing it yet, just porting patches etc - it's hard masked for a reason. Feedback is appreciated (but take backups if your data is precious).
(In reply to comment #14) > Those who feel adventurous may want to give openafs-1.6.0_pre3 a try. I haven't > gotten to testing it yet, just porting patches etc - it's hard masked for a > reason. Feedback is appreciated (but take backups if your data is precious). Where does one find openafs-1.6.0_pre3 ? I scanned back through this bug, and found references to a bleeding-edge overlay. This morning I added that overlay, and only find openafs-1.6.78 in there, no 1.6.*. You also say "it's hard masked for a reason." Do you have known problems, or is it that it's just too new? I've had failures at early 1.5.7* and succussful use of later versions. Theoretically 1.6.0_rc* are of course supposed to be release candidates, so should be "better" than the 1.5.7* stuff I've already had success with. Right now I'm just looking to use the 2.6.38 kernel, need OpenAFS, and anticipate that openafs-1.6.* is going to be the most likely path to that end.
(In reply to comment #15) > Where does one find openafs-1.6.0_pre3 ? In portage. It shows up in http://packages.gentoo.org/package/net-fs/openafs, so you should be able to emerge it after "emerge sync". It's been about since I posted my comment, maybe you have a slow mirror? > You also say "it's hard masked for a reason." Do you have known problems, or > is it that it's just too new? I've had failures at early 1.5.7* and succussful > use of later versions. I've had failures with 1.5.* as well, which is part of the reason I'm giving a warning. The other reason is that I don't have as much spare time as I'd like, and have simply have not been able to use, let alone test, this new version. If you've had success with more recent versions, than there's a chance 1.6 may work for you. I hope it does, but I can't guarantee anything.
I checked, and the 1.6.0_pre ebuilds hit my portage trees on Sunday. A few days back I installed, and this morning I got in early and took a few minutes to boot Gentoo - 2.6.38 with openafs-1.6.0_pre3. Everything looked happy, as far as I took it. I was able to get a token and access various stuff in AFS. I didn't do any write checking at this time. Then I had to boot back to an rpm-based distribution so I could do "real work". Ain't it great when software uses rpm-based "platform checks" to test whether it should run on a system or not. Incidentally, on my experiences with the 1.5 client, I had miserable luck with either 1.5.71 or 1.5.72, better luck with the next release, but still not good enough. After that the releases were good enough for my normal use. There was an interval where I was forced to use 1.5.7x because the stable 1.4.12 wouldn't work with newer kernels, and 1.4.14 wasn't out yet. When 1.4.14 came out I went back to it - until 2.6.38.
It's bumped, to ask for unmasking them -> open a new bug report with your reasoning
(In reply to comment #18) > It's bumped, to ask for unmasking them -> open a new bug report with your > reasoning Actually, at this point it's time for me to instead file a bug report asking for the released 1.6.0 and make masked by ~arch only.
