[Pkg-netatalk-devel] Time for a build?

[Brian Campbell]

On Sat, Apr 19, 2014 at 5:55 AM, Chris Boot <debian at bootc.net> wrote:
> On 18/04/2014 17:09, Brian Campbell wrote:
>> On Fri, Apr 18, 2014 at 6:00 AM, Chris Boot <debian at bootc.net> wrote:
>>> What needs doing
>>> right now to get something usable back into testing ASAP?
>>
>> I think that what I've pushed to the "team" branch is ready to be
>> uploaded to unstable and should be able to make it into testing, as it
>> fixes the FTBFS that caused Netatalk to be kicked out of testing in
>> the first place.
>
> Great, I'll take a look and see if I can come up with any comments.
>
>>> Has anyone put
>>> any work into packaging netatalk 3.x?
>>
>> Yes, actually, I've done some Netatalk 3 packaging work, but it will
>> probably need a little more love before it's ready to go into the
>> archive.
>
> Ooh that's good news, I'll try to take a look at that too over the
> weekend, though I think getting 2.2.5 into unstable ASAP is the most
> important.

Agreed.

> We should probably get netatalk 3.x into a sensible shape and put that
> into experimental ASAP too. It can live in there for a while until we're
> happy to put that into unstable, and may benefit from a few more
> eyeballs in there.

That sounds like a good plan. What state should it be in before it's
ready to be uploaded to experimental? I suppose fixing up the
copyright file is probably important. Is there anything else that's
particularly important before we can do this?

> I do think we should aim to get netatalk 3.x into jessie by the freeze
> in November though, or we'll be stuck having to maintain the 2.x branch
> without much in terms of upstream support.

Yep, I've already been having trouble getting upstream support on
2.2.5, which is why I've finally moved to 3. Upstream mostly supports
two release branches, which at this point is 3.0.x and 3.1.x.

>> * We need to make a decision if Jessie will ship both netatalk 2 and
>> netatalk 3 to ease the transition, and thus would need to name the
>> netatalk 3 packaging "netatalk3", or if we'll just unconditionally
>> upgrade and make people update their config upon updating, and can
>> just leave it named "netatalk". For my use case, the latter is fine,
>> as our management tools generate the appropriate config files
>> automatically, but for the wider Debian userbase we may want to ship
>> both at once for one release to allow people to upgrade at their
>> leisure.
>
> I would personally be very reluctant to maintain two branches in stable,
> especially as 2.x is essentially EOL already. We'd have to provide
> security support without much help from upstream for approximately 3
> years from now, which is no small task.

That makes sense. I'm fine with only supporting one version.

>> * I had no idea what to do with the changelog in the process of doing
>> this, so it may mention several unreleased builds (such as the 2.2.5
>> version that has been sitting around unreleased for a while), so it
>> may need to be cleaned up and consolidated into one big changelog
>> entry, or maybe it's OK to leave in unreleased builds in the
>> changelog, I'm not sure.
>
> If the builds were never uploaded to Debian, we probably shouldn't have
> changelog entries for them.
>
>> * We may want to review the included default afp.conf, to make sure
>> those are reasonable defaults. I haven't paid much attention to it as
>> our software configures it fairly differently.
>
> Yes, that makes sense. I haven't yet looked, but do the Debian packages
> ship config files that are significantly different from upstream? If so,
> we should definitely go over things again to make sure we aren't
> changing defaults unnecessarily for example.

Here's the default config shipped upstream:

    ;
    ; Netatalk 3.x configuration file
    ;

    [Global]
    ; Global server settings

    ; [Homes]
    ; basedir regex = /xxxx

    ; [My AFP Volume]
    ; path = /path/to/volume

And here's the one that's currently in the Debian packaging.

    ;
    ; Netatalk 3.x configuration file
    ;
    ; Edited to serve as example for Debian/Ubuntu by
    ; Martin Loschwitz <madkiss at debian.org>
    ;

    [Global]
    ; Global server settings
    vol preset = default_for_all
    log file = /var/log/netatalk.log
    uam list = uams_randnum.so,uams_dhx.so,uams_dhx2_passwd.so
    save password = no

    [default_for_all]
    file perm = 0664
    directory perm = 0774
    cnid scheme = dbd
    ; Uncomment the following line to restrict access to specific users
    ; valid users = someuser

    [Homes]
    basedir regex = /home

    ; The following is an example for a TimeMachine compatible volume,
    ; limited to a size of round about 1.5 Terabyte.
    ; [TimeMachine]
    ; path = /mnt/backup/someuser
    ; time machine = yes
    ; vol size limit = 1500000

So, upstream just ships a minimal skeleton with a few comments
indicating what you can do, the one currently included enables home
shares and provides some default permissions, sets a log file, and so
on.

>>> To answer Brian's question, the 'team' upload isn't really that special.
>>> You either need to be a DD or a DM with upload allowed to make any
>>> uploads whatsoever, being part of a team doesn't give you any specific
>>> privileges. It does mean, however, that uploads wouldn't be NMUs. In the
>>> longer run it's probably easier to just add all team members to the
>>> Uploaders list unless we get too numerous.
>>
>> Right, that's what I thought.
>>
>> What determines if you're part of a team? Just if you're subscribed to
>> the mailing list? Part of the alioth project?
>
> As far as the archive is concerned, nothing at all. It's a human thing,
> so if someone random did a team upload without us thinking they are part
> of the team, things would be frowned upon. For the purposes of netatalk,
> I'd assume anyone part of the Alioth project would be a member of the team.
>
>>> Also, I was going to review the changes in the 'team' branch, but I
>>> don't see any such branch on Alioth / collab-maint. Am I looking in the
>>> wrong place?
>>
>> Yeah, the repo is now in a Git repository for the pkg-netatalk Alioth
>> project, not collab-maint:
>> ssh://git.debian.org/git/pkg-netatalk/netatalk
>
> Aha, that's why I've missed it. Thanks for the pointer.
>
>>> I'm a DM and would be happy to make uploads, assuming you are happy to
>>> give me upload privileges.
>>
>> I don't know if there's anything I can do to give you upload
>> privileges; or when you said "you", were you referring to Jonas? You
>> are an admin on the alioth project, if that's what's required to make
>> you a part of the team and give you upload privileges.
>
> All DDs have automatic upload privileges. DMs can be given upload
> privileges for specific packages by any DD. It would be very bad form
> for a random DD to give a DM upload privileges for a package that said
> random DD didn't have any authority over, though.
>
> Effectively, Jonas would have to give me DM upload privileges for
> netatalk, or at the very least give someone else the authority to do so
> on his behalf.

Thanks for the answers on process questions.

> I'll crack on with reviewing netatalk-2.2.5 in the first instance and
> come back with my thoughts ASAP.
>
> Cheers,
> Chris
>
> --
> Chris Boot
> debian at bootc.net
> GPG: 8467 53CB 1921 3142 C56D  C918 F5C8 3C05 D9CE EEEE
>
> --
> Chris Boot
> debian at bootc.net
> GPG: 8467 53CB 1921 3142 C56D  C918 F5C8 3C05 D9CE EEEE