The openafs-ebuild has just been resurrected. Bugs are open requesting non-x86 support (e.g. sparc64). The previous ebuild's mention of archs was very limited. OpenAFS seems to have at least some support for all archs in CC, I'd love to hear which of them actually build. (1.3.x is the important one in my opinion, as it's steadily going for a release candidate, 1.2.x won't even work if you use a linux 2.4 kernel) Thanks in advance, Stefaan
It appears to be working on ~ppc. Added keyword to 1.3.x
I have downloaded the 1.3.87 ebuild one week ago, but i can't find the ebuilds now ... In the portage tree are ebuild's for: openafs-kernel-1.2.13.ebuild, openafs-kernel-1.3.85.ebuild, openafs-kernel-1.4.0_rc2.ebuild but i'm missing the actual stable openafs-kernel-1.3.87.ebuild. I can't find (on www.openafs.org) a changelog for 1.4.0_rc2. I think a short summary should be in bugs to have a better way to backtrace failures in the working afscells. con
1.3.87 has never been in portage. It has been in bug #100837 though, and you were supposed to bump openafs-kernel-1.3.85 to openafs-kernel-1.3.87 yourself because it hadn't changed. And the 1.3 / 1.4 series aren't stable yet, and won't be for another month. Everything is still in testing. Upstream has never published a 1.4.0-rc2 announcement as far as I know. The closest thing to changelogs from upstream can be found in https://lists.openafs.org/pipermail/openafs-announce/2005/thread.html. The Gentoo changelogs currently do not reflect any changes from upstream, also because the changelogs from upstream usually say: "It includes several Linux client fixes as well as portability changes."
I think this won't work on ppc-macos for this reason: econf --with-linux-kernel-headers=${KV_DIR} ppc-macos has no linux kernel headers and probably will never have.
I can't argue with that. But on the other hand, upstream has support for MacOS, so if we could fix this it might be worth it (or might not, one can only tell after trying). Unfortunately, I lack the infrastructure (I won't buy a Mac just to try) and currently the knowledge (but I'm willing to learn) to try this out. I'm a fresh developer, I don't know how this kind of situation is usually handled?
added ~ppc64
Created attachment 70035 [details] the new ebuild that includes the additional einfo request In addition to the above patch, I thought I'd include the current ~x86 ebuild featuring the new einfo lines I added, just so you can see the whole thing.
(In reply to comment #7) > Created an attachment (id=70035) [edit] > the new ebuild that includes the additional einfo request > > In addition to the above patch, I thought I'd include the current ~x86 ebuild > featuring the new einfo lines I added, just so you can see the whole thing. Oops. Not sure how this ended up here, but it was intended to be posted to Bug 77332 , the one requesting a reference to the OpenAFS guide. Actually, this works..kinda. Anyway, I came up with an addition to the existing ebuild as per the request made in bug 77332.
net-fs/openafs-kernel-1.4.0-r1 failed to compile for me on ppc (cpu 740/750, aka G3 Blue&White). In brief, I get: In file included from /var/tmp/portage/openafs-kernel-1.4.0-r1/work/openafs-1.4.0/src/afs/afsincludes.h:44, from /var/tmp/portage/openafs-kernel-1.4.0-r1/work/openafs-1.4.0/src/libafs/MODLOAD-2.6.15-gentoo-r1-SP/afs_analyze.c:36: /var/tmp/portage/openafs-kernel-1.4.0-r1/work/openafs-1.4.0/src/afs/afs.h:901:5: warning: "AFS_USEBUFFERS" is not defined make[6]: *** [/var/tmp/portage/openafs-kernel-1.4.0-r1/work/openafs-1.4.0/src/libafs/MODLOAD-2.6.15-gentoo-r1-SP/afs_analyze.o] Error 1 make[5]: *** [_module_/var/tmp/portage/openafs-kernel-1.4.0-r1/work/openafs-1.4.0/src/libafs/MODLOAD-2.6.15-gentoo-r1-SP] Error 2 [...] !!! ERROR: net-fs/openafs-kernel-1.4.0-r1 failed. Call stack: ebuild.sh, line 1532: Called dyn_compile ebuild.sh, line 929: Called src_compile openafs-kernel-1.4.0-r1.ebuild, line 40: Called die I have a pretty standard environment (can post emerge --info if you like) with the only exception that I'm trying the new modular X, and thus am using portage-2.1_pre7-r5. I have heimdal-0.7.2 on this machine, so I'm hoping to use openafs with it as I do on x86 machines. Thanks again for working on openafs, Stefaan!
Created attachment 84755 [details] emerge --info for failing PPC (Mac G3) case Since I forgot to include the kernel version, 2.6.15-gentoo-r1, I thought I might as well give you emerge --info. I can send along the portage log if you want. /Mike
(In reply to comment #9) > In file included from > /var/tmp/portage/openafs-kernel-1.4.0-r1/work/openafs-1.4.0/src/afs/afsincludes.h:44, > from > /var/tmp/portage/openafs-kernel-1.4.0-r1/work/openafs-1.4.0/src/libafs/MODLOAD-2.6.15-gentoo-r1-SP/afs_analyze.c:36: > /var/tmp/portage/openafs-kernel-1.4.0-r1/work/openafs-1.4.0/src/afs/afs.h:901:5: > warning: "AFS_USEBUFFERS" is not defined Hi Mike, you don't seem to be using -Werror, so I'm wondering if there was error previous to the AFS_USEBUFFERS warning that caused make to abort. Could you please check that? Thanks, Stefaan
Created attachment 84787 [details] compiler output with -Werror on PPC (In reply to comment #11) OK, here it is with -Werror, I've attached the whole thing, but the step with the error appears to be the following. I'm not sure why the PPC would be more sensative to this (or perhaps only the PPC executes this code?): cc -O3 -mcpu=G3 -mtune=G3 -fno-strict-aliasing -fomit-frame-pointer -pipe -Werror -I/var/tmp/portage/openafs-kernel-1.4.0-r1/work/openafs-1.4.0/src/config -I. -I. -I/var/tmp/portage/openafs-kernel-1.4.0-r1/work/openafs-1.4.0/include -I/var/tmp/portage/openafs-kernel-1.4.0-r1/work/openafs-1.4.0/include/afs -I/var/tmp/portage/openafs-kernel-1.4.0-r1/work/openafs-1.4.0/include/rx -I/var/tmp/portage/openafs-kernel-1.4.0-r1/work/openafs-1.4.0 -I/var/tmp/portage/openafs-kernel-1.4.0-r1/work/openafs-1.4.0/src -I/var/tmp/portage/openafs-kernel-1.4.0-r1/work/openafs-1.4.0/src -O2 -D_LARGEFILE64_SOURCE -c strng_to_key.c strng_to_key.c: In function `des_string_to_key': strng_to_key.c:110: warning: passing arg 1 of `des_fixup_key_parity' from incompatible pointer type strng_to_key.c:113: warning: passing arg 1 of `des_key_sched' from incompatible pointer type strng_to_key.c:119: warning: passing arg 1 of `des_fixup_key_parity' from incompatible pointer type make[3]: *** [strng_to_key.o] Error 1 /Mike
Created attachment 84789 [details] MIPS config.log (sysname error) I tried compiling openafs for MIPS (mips64 R5000 V2.1 FPU V1.0 SGI O2 GNU/Linux) and got the following. I have also attached the complete /var/tmp/portage/openafs-kernel-1.4.0/work/openafs-1.4.0/config.log. The kernel involved is 2.6.14.4-mipsgit-20051030-ip32r5k checking your AFS sysname... configure: error: An AFS sysname is required !!! Please attach the config.log to your bug report: !!! /var/tmp/portage/openafs-kernel-1.4.0/work/openafs-1.4.0/config.log !!! ERROR: net-fs/openafs-kernel-1.4.0 failed. !!! Function econf, Line 495, Exitcode 0 !!! econf failed /Mike
Created attachment 84823 [details] Compiler output on sparc64 (dies after mkvers.c for no clear reason) I tried compiling OpenAFS on a recently gentooed Ultra 10 running Portage 2.0.54 (default-linux/sparc/sparc64/2006.0, gcc-3.4.5, glibc-2.3.5-r3, 2.6.15-gentoo-r7 sparc64). It makes it though the configure step in net-fs/openafs-kernel-1.4.0 before dying without error after compiling mkvers.c. I attached the ebuild output. Hope it helps. /Mike
Hi Mike! I just uploaded openafs-1.4.1. They've toyed with some variables you seem to have problems with on PPC, so I'm hoping this will be fixed. Could you check that again? wrt MIPS, I have no reason to assume it will work out of the box now. I'm not familiar with this architecture. Could you look in acinclude.m4 under AC_MSG_CHECKING(your OS) to see if something fits? ppc64 then. This doesn't sound like an openafs problem at all. Moreover, the ppc64-arch team seems to have tested openafs succesfully. Looks more like compiler or a system problem. In any case, I'm afraid I won't be able to draw many conclusions from your log file. Do you think you could track down the source of the problem a bit more? (like starting make by yourself in a sandbox, trying if individual command line-initiated compiles fail, ...) Thanks for all the work! Stefaan
Created attachment 85201 [details] compiler output with -Werror on PPC (openafs-kernel-1.4.1) Hej Stefaan! Unfortunately, openafs-kernel-1.4.1 died in the same way on the PPC. I've attached the compile log so you can see the whole thing if you like. Note this is ppc not ppc64. Unfortuantely, I don't own one of those ;-) piggy ~ # tail /var/log/portage/2959-openafs-kernel-1.4.1.log !!! ERROR: net-fs/openafs-kernel-1.4.1 failed. Call stack: ebuild.sh, line 1532: Called dyn_compile ebuild.sh, line 929: Called src_compile openafs-kernel-1.4.1.ebuild, line 40: Called die !!! Failed: make !!! If you need support, post the topmost build error, and the call stack if relevant. piggy ~ # tail /var/log/portage/2953-openafs-kernel-1.4.0-r1.log !!! ERROR: net-fs/openafs-kernel-1.4.0-r1 failed. Call stack: ebuild.sh, line 1532: Called dyn_compile ebuild.sh, line 929: Called src_compile openafs-kernel-1.4.0-r1.ebuild, line 40: Called die !!! Failed: make !!! If you need support, post the topmost build error, and the call stack if relevant. /Mike
(In reply to comment #15) > wrt MIPS, I have no reason to assume it will work out of the box now. I'm not > familiar with this architecture. Could you look in acinclude.m4 under > AC_MSG_CHECKING(your OS) to see if something fits? I'll give it a go. I'm not so familiar with MIPS myself, but under IRIX several years back you could run AFS, so I don't really see any reason this shouldn't work in principle. > ppc64 then. This doesn't sound like an openafs problem at all. Moreover, the > ppc64-arch team seems to have tested openafs succesfully. Be sure to note that I tested on a sparc64 not ppc64. I'm new to sparc64, but I believe it is only recently they started running 2.6.x kernels. I tested under 2.6.15-gentoo-r7. My guess is that has not been well tested with OpenAFS yet. I'll do what I can to look into it too. As with MIPS, I'm no expert. I recently got hold of a hppa, so--assuming I get Gentoo running on it--I could also try there, should you need more arch testing. /Mike
(In reply to comment #15) > I just uploaded openafs-1.4.1. I resynced on sparc64, but it is still openafs-1.4.0 there for me. Perhaps my mirror is just slow to pick up 1.4.1, (however, ppc found it). If you haven't released 1.4.1 for sparc64, perhaps you could give it a go. Thanks /Mike
(In reply to comment #16) > Created an attachment (id=85201) [edit] > compiler output with -Werror on PPC (openafs-kernel-1.4.1) Hi Mike, I'm sorry, I must have confused you by mentioning "-Werror". I only asked whether you had used this, because the information you showed me at that time only contained warnings, and your compilation stopped anyway, which it shouldn't have. A full compiler log did however reveal that the real error happened far before those warnings. Could you please retry without "-Werror", as the OpenAFS code (and a lot of other code as well, I think) isn't meant to be warning-free. Thanks, Stefaan
Created attachment 85295 [details] compiler output on PPC (Mac G3), openafs-kernel-1.4.1 (rlim error) Hi Stefaan, Here is the output on a ppc (Mac G3 Blue and White). The error seems to be related to rlim: /var/tmp/portage/openafs-kernel-1.4.1/work/openafs-1.4.1/src/afs/LINUX/osi_machdep.h:55:2: #error Not sure what to do about rlim (should be in the Linux task struct somewhere....) make[6]: *** [/var/tmp/portage/openafs-kernel-1.4.1/work/openafs-1.4.1/src/libafs/MODLOAD-2.6.15-gentoo-r1-SP/afs_analyze.o] Error 1 I have not tried looking into what rlim is yet, but thought I would pass this along. /Mike
Created attachment 85296 [details] compiler output on PPC (Mac G4), openafs-kernel-1.4.1 (rlim error again) I also tried compiling openafs on a newer Mac (though not a ppc64): a Mac G4. It is using a different set of compiler options than the G3, but seems to die on the same (rlim) problem. I didn't look too deeply into it yet, but I did notice the size of the compiler output on the G3 is much bigger than the G4 even though they both appeared to stop in the same place. The G3 is using O3, while the G4 is at O2, perhaps that is why. Anyway, I was definitely confused about the Werror thing. I'd never used or even heard of that one before. It's off in these last two attachments. /Mike
no luck on ppc-macos: * Determining the location of the kernel source code * Unable to find kernel sources at /usr/src/linux * This package requires Linux sources. * Please make sure that /usr/src/linux points at your running kernel, * (or the kernel you wish to build against). * Alternatively, set the KERNEL_DIR environment variable to the kernel sources location !!! ERROR: net-fs/openafs-kernel-1.4.1 failed. Call stack: , line : Called die We don't have linux sources, sorry. :)
Closing because all arches for which it is sensible to have this tested, probably have already done so.
