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

Fri Apr 18 16:09:45 UTC 2014

Hi, Chris! Thanks for the reply!

On Fri, Apr 18, 2014 at 6:00 AM, Chris Boot <debian at bootc.net> wrote:
> On 19/03/2014 14:47, Brian Campbell wrote:
>> On Mon, Mar 17, 2014 at 7:53 PM, Brian Campbell
>> <brian.campbell at editshare.com> wrote:
>>> On Mon, Mar 17, 2014 at 9:28 AM, Jonas Smedegaard <dr at jones.dk> wrote:
>>>> This is a team.
>>>>
>>>> Sponsoring is for packages maintained solely by a non-DD.  Does not
>>>> apply here.
>>>>
>>>> NMUs are for package updates done by others than the maintainer(s).
>>>> Does not apply here.
>>>
>>> OK, my apologies. I know you're pretty busy, so I thought that maybe
>>> we could spread the burden around a little. AFAIK, you're the only DD
>>> on pkg-netatalk-devel, so you're the only person who can actually
>>> upload a package. I didn't know that a team managed package couldn't
>>> be sponsored.
>>
>> OK, I think I may have misunderstood. I've now gone back through the
>> Debian Developer's Reference and noticed that there's a separate type
>> of upload, a Team Upload. I've re-done last commit as a team upload,
>> pushed to branch "team", though as far as I know I still can't
>> actually upload it without being a DD or DM (unless I've missed
>> something).
>
> Hi folks,
>
> After a period of prolonged abscence I now have some time to pick up on
> my pledge to help out with netatalk. Not only that but it's a nice long
> weekend so I potentially have time to do quite a lot of work, and all my
> other packages are in order. Winner.
>
> What's the current state of affairs with netatalk?

Right now, Jonas has updated the packaging to Netatalk 2.2.5 and
merged in most of the proposed patches from various issues. I then
found a few more small issues with that and fixed them, as well as
creating a netatalk-dbg package because I find that very helpful when
trying to debug a difficult to reproduce problems on a customer's
system; being able to just install the debug package and start
debugging a process that's behaving oddly without having to do a
separate build for them is quite useful.

We've been running with that Netatalk 2.2.5 packaging, plus a few
local changes specific to my company, for a few months now, and it
seems to be working out pretty well, but we are about to switch to
Netatalk 3.

> 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.

> 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. I have been building packages for use by my company based on
this, it has been going through our QA process and seems to work
fairly well for our purposes. We are about to switch to Netatalk 3 now
that I've ported our management tools to understand the Netatalk 3
config file format.

There have been a few Netatalk 3 packaging branches floating around
GitHub and the issue tracker. I took the latest one, from Adrian
Knoth, and rebased it on top of the latest 2.2.5 branch mentioned
above, then updated it to the latest Netatalk 3.1.1, fixing up any
problems I found along the way. It was a bit tricky to do this rebase
as one of the commits in there was a merge commit that contained not
only a merge but also added significant changes to the Debian
packaging; the end result seems to work, however.

I've just now pushed this work to the "netatalk3" branch in:
ssh://git.debian.org/git/pkg-netatalk/netatalk .

I hope that I've done this correctly; I'm relatively new to Debian
packaging, and in particular git-buildpackage.

What it still needs, at least as far as I know:

* Update the copyright file
* I've noticed a few issues with the man pages including @pkgconfdir@
instead of its expansion; I haven't looked into why that happens yet,
whether it's an upstream bug or a packaging bug.
* 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 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.
* 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.

As I mentioned, this has been in my company's QA process for a few
weeks, and seems to be working reasonably well for us; however, we
have our own layer of management software on top of it, so our QA
department doesn't look at anything outside of the way our software
configures the system.

> 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?

> 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

>
> 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.

https://alioth.debian.org/projects/pkg-netatalk/

You can find the build of Netatalk 2.2.5 that I did on Debian Mentors:

https://mentors.debian.net/package/netatalk

And as mentioned, the code is in the "team" branch of:

ssh://git.debian.org/git/pkg-netatalk/netatalk

> Cheers,
> Chris
>
> --
> Chris Boot
> debian at bootc.net
> GPG: 8467 53CB 1921 3142 C56D  C918 F5C8 3C05 D9CE EEEE