netatalk: update to version 3.1.9 and grab maintainership

[dangowrt]

Maintainer: @MikePetullo
Compile tested: oxnas/generic, LEDE git HEAD
Run tested: oxnas/generic, LEDE git HEAD

Description:

• now a single config file in /etc/afp.conf
• convert services to procd while at it

Signed-off-by: Daniel Golle daniel@makrotopia.org

[dangowrt]

@mstorchak @champtar

[hnyman]

Well, there was no reaction from the maintainer to the previous pull request for a year, so you should maybe also grab the maintainership...

[mstorchak]

My only contribution was to replace +attr with +libattr, so...
Anyway, ACK, if you are asking :)

[dangowrt]

Hm, maybe someone actually owning a Mac to regularly test netatalk would be a better choice for the mainterner job. Anyway, if nobody else volunteers I can still try my best... Ideas?

[dangowrt]

@hgl @hnyman @thess

[yousong]

I think it's agreed that we want packages to be actively maintained and I have no objection against the maintainership transfer. The problem is that we still have no written-down conclusion (#153) about when and how a package's maintainership should be transferred. I think a private email to the current maintainer is needed, maybe just for the sake of formality.

Sorry guys, the following text is apparently for another issue and I was on the wrong page when clicking "close and comment"...

Close this as the node.js build error is now fixed by disabling mips16

[hnyman]

There has been no reaction from the current netatalk maintainer @MikePetullo to the whole discussion, so I would take the silence as an ack. (especially as he did not react to several review requests in #1550 )

Activate maintainers are a necessity. A compromise might be to add you as the second maintainer at this point. Some of the packages have several maintainers mentioned.

In general, waiting for an explicit acknowledgement from an inactive maintainer may be futile. We have quite a lot of packages that were imported in the summer 2014 transfer rush, but which packages have not seen any activity from the original maintainer since then.

[flyn-org]

Sorry, here I am. I fully support a new maintainer, as I no longer own any computers which run Mac OS X. I apologize if not hearing from me slowed progress on this.

[usr-sse2]

Doesn't build:
make[7]: Nothing to be done for all-am'. Making all in afpd /Applications/Xcode.app/Contents/Developer/usr/bin/make all-am CC afpd-afp_dsi.o {standard input}: Assembler messages: {standard input}:2443: Error: unknown pseudo-op: .reference'
{standard input}:2463: Error: unknown pseudo-op: .reference' {standard input}:2490: Error: unknown pseudo-op: .reference'
{standard input}:2510: Error: unknown pseudo-op: .reference' {standard input}:2753: Error: unknown pseudo-op: .reference'
{standard input}:2773: Error: unknown pseudo-op: .reference' {standard input}:2800: Error: unknown pseudo-op: .reference'
{standard input}:2820: Error: unknown pseudo-op: `.reference'
make[7]: *** [afpd-afp_dsi.o] Error 1

[dangowrt]

@usr-sse2: It does build on the buildbots, what you describe looks like a toolchain problem. Which version of OpenWrt/LEDE are you using?

[usr-sse2]

@dangowrt, I'm using OpenWRT 15.05.
I noticed that it's already 3.1.10 in master, so now I try compiling it in master.

[usr-sse2]

@dangowrt, unfortunately, it doesn't build also, but with a different error:
Making all in unicode
Making all in charsets
CC mac_japanese.lo
cc1: note: someone does not honour COPTS correctly, passed 2 times
mac_japanese.c:27:0: error: expected identifier or '(' at end of input

^
make[7]: *** [mac_japanese.lo] Error 1

I looked at that file, there is an empty line. If I remove it, the error remains, saying about the next line. The line before the empty line is #include <stdlib.h>, what can be wrong with that...

[Neustradamus]

Updated by:

• netatalk: upgrade to version 3.1.11 #4402