I'm maintaining the 2.x series of netatalk (as netatalk 1.6 has problems on amd64 so I can't even test it in chroot), but the current stable version of netatalk is (where present) 1.6.4-r1. I'd like to see 2.0.3 stable as that is the one currently maintained by upstream, and the one I'm maintaining here (1.6 series can be considered unmaintained). ppc64 is actually they only "urgent" stable, as the 1.x series is not 64-bit safe, while 2.0.3 should be (works fine on amd64). Thanks, Diego
Marked stable. There was a -r1 ebuild but I didnt mark that one as the bug title specifically called out 2.0.3. Thanks
-2.0.3 stable on amd64
Marked 2.0.3 ppc stable.
stable 2.0.3 on sh.
I just did some testing on x86 for this bug, it appears that there's a collision with glibc. * checking 160 files for package collisions existing file /usr/include/netatalk/at.h is not owned by this package doing a equerly belongs for the file in question states that it belongs to sys-libs/glibc-2.3.5-r2 (/usr/include/netatalk/at.h).
Joshua is right, I have overseen that before because I merged netatalk having collision-protect disabled the first time I installed it. Arches: please marked -r2 stable as soon as you can that fixes this (quite severe) bug (glibc header overwritten). netatalk 1.6 shown the same behavior.
2.0.3-r2 marked stable on x86
2.0.3-r2 sparc stable.
diego, please feel free to mark it stable on amd64 yourself
sorry, missed the fact about the (nonexisting) stable chroot.. readding amd64
Hansmi has already marked this ppc stable.
did you see: QA Notice: the following files are setXid, dyn linked, and using lazy bindings This combination is generally discouraged. Try re-emerging the package: LDFLAGS='-Wl,-z,now' emerge netatalk LAZY usr/bin/afppasswd at the bottom of the merge process? marked stable on amd64 nevertheless
sh was already stabled, closing bug. Simon, the problem is just a side, but I fixed it anyway (was a misnamed call).