Yesterday I added an ebuild for latest version of netatalk, 2.0.3, which should fix at least a few bugs, and which seems to be 64-bit safe as I can't reproduce the "2009" bug here on amd64. I used the same keywords of 2.0.1 (~x86 ~ppc) and the on I can test on (~amd64), but from 2.0.1 were dropped ~sparc and ~ppc64 keywords. Can arch teams test this to see if it's possible to mark the 2.x series, as I don't think I'll be able to maintain 1.x series? Thanks, Diego
i did a quick test on the ppc64 machine that shows the time shifting mentioned in the other place. i made an "emerge -uD world" to get everything up to date so i hopefully dont have any old or buggy libs on it. i had to emerge the ~ppc64 cracklib and pam packages. i had to add USE="pam_console" because netatalk complains at runtime of that missing pam_console.so file. so i came across the pam 'bug' that fails to compile with USE="pam_console" enabled. i had to manually export CC=gcc and CXX=g++ to compile pam successfully. so compilation was ok after all. init startup seems good. this was an upgrade from version 2.0.1. everyhting seemed right but the clients were unable to connect to the server. the server is selectable and it asks for a password. after that the client gets an error immediatly saying something like "could not connect to server. please try again later". so i cant even select the shared volumes on the server. i didnt see any great changes in the config files from 2.0.1 -> 2.0.3, did i miss something? i cant post any logs atm, sorry. but they didnt seem to reveal any interesting.. at least to me. i try to get some more info when needed the next time i try to upgrade. since this machine is actually used i cannot test and break thing like i want so i went back to 2.0.1 working flawless (execpt the date issue). off topic: concerning the date issue. it is exactly 156337200 seconds in the future. maybe someone sees a clue in this number?
pam_console is needed only if you have pam_console in your system-auth pamd file, so that problem is not concerned with netatalk. The login problem.. I think it can be a problem with your system-auth pamd file, here works fine and if you built with +pam, pam is what takes care of it, and pamd file completely changed between 2.0.1 and 2.0.3: the 2.0.1 version uses pam_pwdb to load the data from local files, but 2.0.3 uses include to get into system-auth authorization (which should be used by all the login facilities).
Moving to sparc as corsair keyworded for ppc64.
Added ~sparc keyword. Thanks for the bug report.