Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Nye Liu]

On Fri, 3 Feb 2017 01:55:10 -0800 Nye Liu  wrote:
> Why is /lib/systemd/system/nfs-common.service being linked to /dev/null
> in debian/nfs-common.links?

Ignore. I see that statd, idmpad, and gssd have their own systemd units now.

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Nye Liu]

Also a stupid question:

Why is /lib/systemd/system/nfs-common.service being linked to /dev/null
in debian/nfs-common.links?

It seems to prevent idmapd, statd, and gssd from being started if
systemd is used, unless you remove the link and forcibly "systemctl
enable nfs-common"

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Nye Liu]

On Sat, 17 Dec 2016 04:54:21 +0100 =?UTF-8?Q?Rapha=c3=abl_Halimi?=
 wrote:
> Please explain exactly in what way would my patch introduce
> *incompatible* changes. It's *trivial*, it only adds a single option,
> and a comment to hint that NFSv4 must be disabled in rpc.nfsd in
> addition of rpc.mountd. Why do you deem this change as "incompatible"?
> Just because of a single conffile prompt that would affect a minority
> of users ?

Even worse, NFSv2 was silently disabled by default:

http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=6b4e4965a6b82e8d49cea1c0316b951ba4e9e83e

Which broke every single one of my clients that require NFSv2.

The RPCNFSDOPTS has STILL (inexplicably) not been implemented, despite
the availability of a (working) patch:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738063

And don't even get me started on the systemd folly of wanting to get rid
of /etc/defaults.

The whole thing is getting ridiculous.

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Raphaël Halimi]

Hi Andreas Henriksson,

Le 14/12/2016 à 08:21, Andreas Henriksson a écrit :
> Congrats on completely derailing a thread that for once was about
> proper mainenance and solving a bigger problem into becoming
> about your pet peeve. Please feel free to stop CCing me if you
> don't actually want my feedback.

That wasn't my intention at all. I was sincerely happy to see some
growing activity in the maintenance of NFS packages and I seized this
opportunity to point out a trivial patch rotting for one year in the BTS
that could fix two separate bugs, and allow to effectively close them.
In other words, I was *trying to help*.

On the contrary, it's you who, as usual, treated people who don't use
systemd with utter contempt, by suggesting to close both bugs as
wontfix, and by doing so, transformed part of this thread in a potential
mini-flamewar. Or maybe it is a personal vendetta against me about our
previous quarrel in #773915 ? Frankly, I don't care, but I'd like to say
that I just contribute to Debian in the hope that it (and its
derivatives) will work out-of-the-box for most people, but it seems to
me that you want Debian to work exclusively for systemd and GNOME users,
purposefully brushing aside other people's efforts in the opposite
direction.

Now for the technical side of the problem:

>> Since it's so easy to override
>> these settings with systemd (I'm not ironical here, I really don't know
>> how it's done), what harm would this patch do if it was applied to
>> satisfy sysvinit users ?
> 
> If you think it's about making it easy to do it in multiple separate
> ways, then you don't understand the problem. You want exactly
> *one* way to do it that's supported by all, so we can continue
> keeping that one way working and avoid incompatible upgrades.

Exactly, and AFAIK /etc/default snippets *are* this universal way. How
else would you do it for it to work with both systemd and sysvinit ?

Besides, rpcbind already uses this mechanism through
/lib/systemd/system/rpcbind.service (line
"EnvironmentFile=-/etc/default/rpcbind"). Why would it be such a bad
idea for nfs-utils ?

> You know Debian cares alot about integration and easy upgrades, right?

Please stop being condescending. I use Debian since 1998 so yes, I know
that, but "caring about easy upgrades" does not mean "leave bugs unfixed
just to avoid a conffile prompt during upgrades".

>> They would have at last the possibility of modifying rpcnfsdopts through
>> /etc/default/nfs-kernel-server, and thus reliably disable nfsv4, and
>> systemd users could still do the same through whatever facility systemd
>> provides and that I'm not aware of.
> 
> You already have this option. These files are conffiles. Please read
> up on what that means (in policy for example).

I know what a conffile means in the Debian jargon, and I'm perfectly
fine with modifying them, except for init scripts. When the maintainer
changes an init script, reconciling the differences with local
modifications is both cumbersome and error-prone, and I do my best to
avoid that.

> Maybe also think a bit about why making incompatible changes to
> conffiles and shipping new versions of them in a package is something
> you want to avoid as a maintainer, and why a user don't want a
> maintainer to do that either.

Please explain exactly in what way would my patch introduce
*incompatible* changes. It's *trivial*, it only adds a single option,
and a comment to hint that NFSv4 must be disabled in rpc.nfsd in
addition of rpc.mountd. Why do you deem this change as "incompatible" ?
Just because of a single conffile prompt that would affect a minority of
users ?

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Daniel Pocock]

On 15/12/16 11:44, Daniel Pocock wrote:
> 
> 
> On 14/12/16 23:41, Ben Hutchings wrote:
>> On Tue, 2016-12-13 at 20:55 +0100, Daniel Pocock wrote: [...]
>>> Thanks for providing this feedback
>>>
>>> I've done the following: - forked the upstream repository
>>
>> The existing packaging repos are also based on the upstream git
>> repo.
>>
> 
> OK, I see that now, but I notice that the debian/* files have been
> committed on the master branch.  This was confusing for me as it is
> not clear which commits are real upstream commits on that branch and
> which commits are the work of maintainers (unless you look inside the
> commit to see what changes).
> 
> It would be nicer to have the master branch as a pure copy of
> upstream's master branch and then have a branch called debian/sid with
> the commits made by package maintainers.  Is there an easy way to
> adapt the existing repository to that model?  If so, I could very
> quickly re-apply my changes on top of it.
> 
> I think the master branch in that repo can simply be renamed to
> debian/sid and then a new master created based on upstream's master.
> Then we can periodically merge the tags (or tarballs) from the
> upstream master into the debian/sid branch.
> 

I tried to construct another repository based on this approach and added
my changes into it:

git://git.debian.org/git/collab-maint/nfs-utils-alt-repo.git

Regards,

Daniel

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Daniel Pocock]

On 14/12/16 23:41, Ben Hutchings wrote:
> On Tue, 2016-12-13 at 20:55 +0100, Daniel Pocock wrote: [...]
>> Thanks for providing this feedback
>> 
>> I've done the following: - forked the upstream repository
> 
> The existing packaging repos are also based on the upstream git
> repo.
> 

OK, I see that now, but I notice that the debian/* files have been
committed on the master branch.  This was confusing for me as it is
not clear which commits are real upstream commits on that branch and
which commits are the work of maintainers (unless you look inside the
commit to see what changes).

It would be nicer to have the master branch as a pure copy of
upstream's master branch and then have a branch called debian/sid with
the commits made by package maintainers.  Is there an easy way to
adapt the existing repository to that model?  If so, I could very
quickly re-apply my changes on top of it.

I think the master branch in that repo can simply be renamed to
debian/sid and then a new master created based on upstream's master.
Then we can periodically merge the tags (or tarballs) from the
upstream master into the debian/sid branch.


>> - created a debian/sid branch - copied debian/* from jessie into
>> that branch and committed - copied debian/* from sid into that
>> branch and committed - used "git format-patch" and "git am" to
>> copy in changes from your repo - merged upstream's 1.3.4 tag into
>> debian/sid - updated patches (many could be dropped) - other
>> small updates (home page, VCS fields) - pushed my repo into a new
>> location, collab-maint/nfs-utils
> 
> This throws away all the packaging history, which I don't think is
> a good idea.
> 

I agree and if we can have the history and have a pure copy of
upstream's master branch that would be ideal.

>> Please have a look at my repository structure and tell me if you
>> feel it is useful for this project.  If not, my changes could be
>> extracted easily enough with git format-patch and applied into
>> your repository with git am and then we could start the
>> collab-maint/nfs-utils repository over again.
>> 
>> Are you happy for this to live in collab-maint now?  Maybe that
>> will encourage more collaborators.  I've added a README.source
>> inviting contributions too.
> 
> I'm happy for nfs-utils to move away from the kernel team, and
> that implies it should go in a different project on Alioth.  I've
> never been very comfortable with collab-maint and I don't see the
> value in allowing everyone to push to a git repository (versus
> sending a pull request).  However, as I'm not going to be
> maintaining it any more I don't claim a right to veto that.
> 

In this case, I'm simply trying to find a safe way to move forward
with a package that is probably used quite widely.

> I think you should check whether Anibal and Steve want to continue 
> being co-maintainers for nfs-utils and if so what their opinions
> are.
> 

Yes, I was waiting for them to comment on all of this.  I don't want
to be the only person involved in this package either so I'll let it
sit the way it is for a bit longer and give them time to respond.

Regards,

Daniel

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Daniel Pocock]

On 15/12/16 09:50, Sven Geggus wrote:
> Daniel Pocock schrieb am Mittwoch, den 14. Dezember um 13:35 Uhr:
> 
>> If the latest NFS / kernel combination in sid definitely won't work
>> without gss-proxy then you could open an RC bug against the nfs-utils
>> package on that basis.
> 
> I assume, that it does work (as it also works in stable), but it definitely
> comes with a DOS included:
> 
> If your kerberos tickets get too big the whole NFS server freezes.  In
> practice this kind of kerberos ticket will arise in AD environments where
> people are members of a lot of groups.
> 


Could you please open a specific bug for that issue and include the options:

- include svcgssd with this known risk

- stop including svcgssd in nfs-utils, people who want this
functionality need to follow the gssproxy ITP

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Sven Geggus]

Daniel Pocock schrieb am Mittwoch, den 14. Dezember um 13:35 Uhr:

> If the latest NFS / kernel combination in sid definitely won't work
> without gss-proxy then you could open an RC bug against the nfs-utils
> package on that basis.

I assume, that it does work (as it also works in stable), but it definitely
comes with a DOS included:

If your kerberos tickets get too big the whole NFS server freezes.  In
practice this kind of kerberos ticket will arise in AD environments where
people are members of a lot of groups.

Regards

Sven

-- 
/* Fuck me gently with a chainsaw... */
(David S. Miller in /usr/src/linux/arch/sparc/kernel/ptrace.c)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Robbie Harwood]

Sven Geggus  writes:

> Daniel Pocock schrieb am Mittwoch, den 14. Dezember um 11:01 Uhr:
>
>> Would you consider uploading it or proposing it in mentors.debian.net?
>> Please also send details on the gss-proxy ITP bug.
>
> Robbie is the one with the ITP bug, not me :)
>
> I just pushed my custom package data to github though:
> https://github.com/giggls/gssproxy

Hi, glad the github fork was useful.

I have the bulk of my package done for the ITP, but haven't gotten
init-related functionality working yet.

Upstream (that's Simo and me, though this is Simo's decision) prefer the
name "GSS-Proxy" for anything written in a sentence, and "gssproxy" for
everything else.  The package in Fedora and RHEL/CentOS is called
"gssproxy", for instance.

As for the NFS pieces: upstream, we package example configuration files
for an NFS server, apache (mod_auth_gssapi), and an NFS client.  We
don't provide any additional scripting for NFS; NFS takes care of that.

Hope that helps,
--Robbie


signature.asc
Description: PGP signature

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Ben Hutchings]

On Wed, 2016-12-14 at 09:38 +0100, Daniel Pocock wrote:
> 
> On 14/12/16 08:24, Andreas Henriksson wrote:
> > On Wed, Dec 14, 2016 at 08:11:52AM +0100, Daniel Pocock wrote:
> > > I agree the loss of Debian packaging history is a concern, that is one
> > > reason I didn't clobber the existing repository and I wrote that we can
> > > blow this away if there isn't consensus about it.
> > 
> > Yeah, but ever more importantly now is to not get stuck on details I guess.
> > 
> 
> 
> It will not be too hard to switch back and forth between the two
> approaches, so lets leave the final decision on that for another couple
> of weeks.
> 
> The bigger issues:
> 
> - should it live in the kernel section on alioth (where only members of
> that team can commit) or collab-maint (where any DD can commit)?

I would suggest a new project.  That gives you mailing lists and the
ability to add your own repository hooks.  (Hooks are restricted in
collab-maint for hopefully obvious reasons.)

rpcbind probably also belongs in that project.  Maybe gssproxy too. 
(Even though neither is strictly specific to NFS.)

> - should it continue to list the kernel packaging team as the
> maintainer, or is there potentially another team suitable for it?  Given
> the server-side stuff is partly kernel code, there is a strong reason
> for the kernel team to see all the bug reports

Now I remember, that was one of my reasons for wanting to move nfs-
utils to kernel team maintenance.  At the time, many or even most of
the open bugs against 'nfs-kernel-server' were kernel bugs, not bugs in
that package.  However, that hasn't been a big issue and it shouldn't
be hard for nfs-utils maintainers to continue reassigning obvious
kernel-side bugs.

> - does it actually work for more people?  I only did basic tests of the
> new 1.3.4 package with NFS 3 and a single client in a jessie system  the
> latest kernel from jessie-backports.  Somebody should probably test the
> package on a system running stretch or sid and also try the NFSv4 stuff.

Ideally you would have some sort of automated tests that spin up
different configurations of NFS servers and clients in some
containers or VMs.  (Containers would be way quicker but VMs would let
you control the kernel version too.)

> - does anybody have time to fully review major upstream changes?  These
> are things I noticed:
> 
> Upstream now installs nfsdcltrack to /sbin - does the Debian kernel look
> for it in that location too or does it want /usr/sbin/nfsdcltrack or was
> that just a bug in the jessie package putting it in the wrong place?
[...]

The kernel's default has always been /sbin/nfsdcltrack.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice
versa.


signature.asc
Description: This is a digitally signed message part

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Ben Hutchings]

On Tue, 2016-12-13 at 20:55 +0100, Daniel Pocock wrote:
[...]
> Thanks for providing this feedback
> 
> I've done the following:
> - forked the upstream repository

The existing packaging repos are also based on the upstream git repo.

> - created a debian/sid branch
> - copied debian/* from jessie into that branch and committed
> - copied debian/* from sid into that branch and committed
> - used "git format-patch" and "git am" to copy in changes from your repo
> - merged upstream's 1.3.4 tag into debian/sid
> - updated patches (many could be dropped)
> - other small updates (home page, VCS fields)
> - pushed my repo into a new location, collab-maint/nfs-utils

This throws away all the packaging history, which I don't think is a
good idea.

> Please have a look at my repository structure and tell me if you feel it
> is useful for this project.  If not, my changes could be extracted
> easily enough with git format-patch and applied into your repository
> with git am and then we could start the collab-maint/nfs-utils
> repository over again.
>
> Are you happy for this to live in collab-maint now?  Maybe that will
> encourage more collaborators.  I've added a README.source inviting
> contributions too.

I'm happy for nfs-utils to move away from the kernel team, and that
implies it should go in a different project on Alioth.  I've never been
very comfortable with collab-maint and I don't see the value in
allowing everyone to push to a git repository (versus sending a pull
request).  However, as I'm not going to be maintaining it any more I
don't claim a right to veto that.

I think you should check whether Anibal and Steve want to continue
being co-maintainers for nfs-utils and if so what their opinions are.

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.



signature.asc
Description: This is a digitally signed message part

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Daniel Pocock]

On 14/12/16 12:12, Sven Geggus wrote:
> Daniel Pocock schrieb am Mittwoch, den 14. Dezember um 11:01 Uhr:
> 
>> Would you consider uploading it or proposing it in mentors.debian.net?
>> Please also send details on the gss-proxy ITP bug.
> 
> Robbie is the one with the ITP bug, not me :)
> 
> I just pushed my custom package data to github though:
> https://github.com/giggls/gssproxy
> 
>> Personally, I am very unlikely to have time to do that test before the
>> freeze in January.
> 
> Hm, I consider a non working NFS4 client/server a release critical bug.
> 

If it is definitely not working, you are welcome to open an RC bug, then
more members of the community can comment on the severity - but first
somebody needs to test and see if such a bug exists.

If the latest NFS / kernel combination in sid definitely won't work
without gss-proxy then you could open an RC bug against the nfs-utils
package on that basis.

Regards,

Daniel

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Sven Geggus]

Daniel Pocock schrieb am Mittwoch, den 14. Dezember um 11:01 Uhr:

> Would you consider uploading it or proposing it in mentors.debian.net?
> Please also send details on the gss-proxy ITP bug.

Robbie is the one with the ITP bug, not me :)

I just pushed my custom package data to github though:
https://github.com/giggls/gssproxy

> Personally, I am very unlikely to have time to do that test before the
> freeze in January.

Hm, I consider a non working NFS4 client/server a release critical bug.

Regards

Sven

-- 
# Turn on/off security.  Off is currently the default
(found in MongoDB default configfile)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Daniel Pocock]

On 14/12/16 10:31, Sven Geggus wrote:
> Daniel Pocock schrieb am Mittwoch, den 14. Dezember um 09:38 Uhr:
> 
>> They stopped including rpc-svcgssd in the default build as of 1.3.2 and
>> recommended gssproxy[1] instead.
> 
> Yes, gssproxy is a working drop-in replacement for rpc.svcgssd in case of
> the nfs4-server use case.
> 
> Note, that they are mutually exclusive. Once gssproxy has been used on a
> machine a reboot is requeired to go back to rpc.svcgssd again.
> 
> As I already wrote in my bug-report I consider rpc.svcgssd broken. This said
> it would be a good idea to remove it from the nfs-package alltogether.
> Instead a "Recommends: gssproxy" can be added.
> 

I don't mind doing that after the gssproxy is in Debian

Should the package name be gss-proxy or gssproxy?  Upstream has used
both terms.

> I am currently running a custom quick-and dirty debian package of gssproxy
> compiled for debian stable and the original version of nfs-common (1.2.8-9). 
> I can also try running this with a backport of nfs-common 1.3.4 on my
> test-vm.
> 


Would you consider uploading it or proposing it in mentors.debian.net?
Please also send details on the gss-proxy ITP bug.

> For running an NFS-server /etc/gssproxy/gssproxy.conf looks like this here:
> --cut--
> [gssproxy]
> 
> [service/nfs-server]
>   mechs = krb5
>   socket = /run/gssproxy.sock
>   cred_store = keytab:/etc/krb5.keytab
>   trusted = yes
>   kernel_nfsd = yes
>   euid = 0
> --cut--   
> 
> The most simple test-setup for kerberized nfs4 might be the following:
> 3 virtual machines: 
> 
> 1. A Samba 4 ADDC
> 2. An nfs-server
> 3. An nfs-client
> 
> Machines 2 and 3 need to be bound to Samba 4 ADDC using nslcd or sssd for
> UID-mapping.
> 


Personally, I am very unlikely to have time to do that test before the
freeze in January.  If somebody else wants to take care of the nfs4
aspects of this package that would be great.  Are there any other places
where we might find potential testers?  Maybe I will write a brief blog
linking to this bug.

Regards,

Daniel

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Sven Geggus]

Daniel Pocock schrieb am Mittwoch, den 14. Dezember um 09:38 Uhr:

> They stopped including rpc-svcgssd in the default build as of 1.3.2 and
> recommended gssproxy[1] instead.

Yes, gssproxy is a working drop-in replacement for rpc.svcgssd in case of
the nfs4-server use case.

Note, that they are mutually exclusive. Once gssproxy has been used on a
machine a reboot is requeired to go back to rpc.svcgssd again.

As I already wrote in my bug-report I consider rpc.svcgssd broken. This said
it would be a good idea to remove it from the nfs-package alltogether.
Instead a "Recommends: gssproxy" can be added.

I am currently running a custom quick-and dirty debian package of gssproxy
compiled for debian stable and the original version of nfs-common (1.2.8-9). 
I can also try running this with a backport of nfs-common 1.3.4 on my
test-vm.

For running an NFS-server /etc/gssproxy/gssproxy.conf looks like this here:
--cut--
[gssproxy]

[service/nfs-server]
  mechs = krb5
  socket = /run/gssproxy.sock
  cred_store = keytab:/etc/krb5.keytab
  trusted = yes
  kernel_nfsd = yes
  euid = 0
--cut--   

The most simple test-setup for kerberized nfs4 might be the following:
3 virtual machines: 

1. A Samba 4 ADDC
2. An nfs-server
3. An nfs-client

Machines 2 and 3 need to be bound to Samba 4 ADDC using nslcd or sssd for
UID-mapping.

Regards

Sven

-- 
Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety (Benjamin Franklin)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Daniel Pocock]

On 14/12/16 08:24, Andreas Henriksson wrote:
> On Wed, Dec 14, 2016 at 08:11:52AM +0100, Daniel Pocock wrote:

>> I agree the loss of Debian packaging history is a concern, that is one
>> reason I didn't clobber the existing repository and I wrote that we can
>> blow this away if there isn't consensus about it.
> 
> Yeah, but ever more importantly now is to not get stuck on details I guess.
>


It will not be too hard to switch back and forth between the two
approaches, so lets leave the final decision on that for another couple
of weeks.

The bigger issues:

- should it live in the kernel section on alioth (where only members of
that team can commit) or collab-maint (where any DD can commit)?

- should it continue to list the kernel packaging team as the
maintainer, or is there potentially another team suitable for it?  Given
the server-side stuff is partly kernel code, there is a strong reason
for the kernel team to see all the bug reports

- does it actually work for more people?  I only did basic tests of the
new 1.3.4 package with NFS 3 and a single client in a jessie system  the
latest kernel from jessie-backports.  Somebody should probably test the
package on a system running stretch or sid and also try the NFSv4 stuff.

- does anybody have time to fully review major upstream changes?  These
are things I noticed:

Upstream now installs nfsdcltrack to /sbin - does the Debian kernel look
for it in that location too or does it want /usr/sbin/nfsdcltrack or was
that just a bug in the jessie package putting it in the wrong place?

They stopped including rpc-svcgssd in the default build as of 1.3.2 and
recommended gssproxy[1] instead.  I added the flag to enable svcgssd to
debian/rules so the package remains similar to the previous one, but I
am not using svcgssd so I haven't checked any more closely.  I notice
Robbie (added on CC) has an ITP[2] for gss-proxy, will it be in stretch?

They removed[3] gss_clnt_send_err and gss_destroy_creds - could anybody
be using those from scripts?  I simply dropped them from the .install file

Can anybody review the Ubuntu patches for the systemd unit files against
the upstream changes?  I tried to merge them and all the daemons I use
are running but maybe there is some subtle issue that I haven't noticed,
I don't work on systemd unit files every day.

Regards,

Daniel


1. https://fedorahosted.org/gss-proxy/
2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838282
3. https://patchwork.kernel.org/patch/2985231/

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Andreas Henriksson]

On Wed, Dec 14, 2016 at 08:11:52AM +0100, Daniel Pocock wrote:
> 
> 
> On 13/12/16 22:46, Andreas Henriksson wrote:
> > On Tue, Dec 13, 2016 at 08:55:34PM +0100, Daniel Pocock wrote:
> >> Hi Ben,
> >>
> >> Thanks for providing this feedback
> >>
> >> I've done the following:
> >> - forked the upstream repository
> >> - created a debian/sid branch
> >> - copied debian/* from jessie into that branch and committed
> >> - copied debian/* from sid into that branch and committed
> > [...]
> > 
> > Haven't checked the actual repo, but this sounds horrible to me.
> > 
> 
> It is not universally bad

I don't want to create additional burdens for you making progress here,
just thought I could suggest alternative approaches that I would personally
use instead.

> 
> The benefit is that it makes it easier for integrating with upstream
> work and quickly testing code that upstream hasn't tagged or released, e.g.
> 
> 
> git checkout master (upstream's master)
> git pull(get latest unreleased stuff)

Well, after following one of my previously suggested methods then you
could just rename the branches (and set up new tracking)
and you can still do it like you're describing.

> 
> git checkout -b debian/test-latest-2016-12-14 debian/sid
> git merge master
> vi debian/changelog
> git add debian/changelog && git commit -m 'Test build 2016-12-14'
> 
> dpkg-buildpackage -rfakeroot -i.* -b -us -uc
> 
> 
> When I am working in my own projects where I am upstream I find it very
> convenient to be able to rapidly build and test packages like that
> before tagging my upstream releases.  My goal there is to ensure every
> release tarball can work on Debian without patching.
> 
> I agree the loss of Debian packaging history is a concern, that is one
> reason I didn't clobber the existing repository and I wrote that we can
> blow this away if there isn't consensus about it.

Yeah, but ever more importantly now is to not get stuck on details I guess.

Regards,
Andreas Henriksson

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Andreas Henriksson]

Hello Raphaël Halimi,

Congrats on completely derailing a thread that for once was about
proper mainenance and solving a bigger problem into becoming
about your pet peeve. Please feel free to stop CCing me if you
don't actually want my feedback.

On Tue, Dec 13, 2016 at 11:01:19PM +0100, Raphaël Halimi wrote:
> Wontfix ? Really ? Are you that much intent on killing sysvinit ?

Unless by "killing sysvinit" you mean "use it as intended", then no.

> 
> Last time I checked, the Policy still required alternative init systems
> to be supported by package maintainers.

I wonder which policy you're reading then. Fwiw, I recently posted
patches to policy to make it sysvinit compatible, but maybe we
should go the other way around and cite the current very outdated
policy as a reason for sysvinit removal instead?

> Since it's so easy to override
> these settings with systemd (I'm not ironical here, I really don't know
> how it's done), what harm would this patch do if it was applied to
> satisfy sysvinit users ?

If you think it's about making it easy to do it in multiple separate
ways, then you don't understand the problem. You want exactly
*one* way to do it that's supported by all, so we can continue
keeping that one way working and avoid incompatible upgrades.
You know Debian cares alot about integration and easy upgrades, right?

> 
> They would have at last the possibility of modifying rpcnfsdopts through
> /etc/default/nfs-kernel-server, and thus reliably disable nfsv4, and
> systemd users could still do the same through whatever facility systemd
> provides and that I'm not aware of.

You already have this option. These files are conffiles. Please read
up on what that means (in policy for example).

Maybe also think a bit about why making incompatible changes to
conffiles and shipping new versions of them in a package is something
you want to avoid as a maintainer, and why a user don't want a
maintainer to do that either.

Regards,
Andreas Henriksson

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Daniel Pocock]

On 13/12/16 22:46, Andreas Henriksson wrote:
> On Tue, Dec 13, 2016 at 08:55:34PM +0100, Daniel Pocock wrote:
>> Hi Ben,
>>
>> Thanks for providing this feedback
>>
>> I've done the following:
>> - forked the upstream repository
>> - created a debian/sid branch
>> - copied debian/* from jessie into that branch and committed
>> - copied debian/* from sid into that branch and committed
> [...]
> 
> Haven't checked the actual repo, but this sounds horrible to me.
> 

It is not universally bad

The benefit is that it makes it easier for integrating with upstream
work and quickly testing code that upstream hasn't tagged or released, e.g.


git checkout master (upstream's master)
git pull(get latest unreleased stuff)

git checkout -b debian/test-latest-2016-12-14 debian/sid
git merge master
vi debian/changelog
git add debian/changelog && git commit -m 'Test build 2016-12-14'

dpkg-buildpackage -rfakeroot -i.* -b -us -uc


When I am working in my own projects where I am upstream I find it very
convenient to be able to rapidly build and test packages like that
before tagging my upstream releases.  My goal there is to ensure every
release tarball can work on Debian without patching.

I agree the loss of Debian packaging history is a concern, that is one
reason I didn't clobber the existing repository and I wrote that we can
blow this away if there isn't consensus about it.

Regards,

Daniel

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Raphaël Halimi]

Le 13/12/2016 à 22:09, Andreas Henriksson a écrit :
> I would suggest tagging these both as wontfix. Adding even more options
> to the broken concept of /etc/default just adds to the maintenance burden
> of having to carry this over via the nfs-utils_env.sh bridge.
> 
> Both /etc/default/nfs-kernel-server and the init script are conffiles.
> Edit them directly as you see fit to suite your installation if you're
> still using this old stuff. They will not be overwritten on upgrades.
> 
> On systemd there's a better concept of overriding settings so you don't
> need to (and should avoid to) deal with /etc/default anymore.
> 
> I suggest making the long-term goal to get rid of /etc/default.
> Automatically handling conversion of users /etc/default over to proper
> systemd style overrides would probably be a very fragile if not totally
> impossible thing to accomplish though, so just adding NEWS entries
> recommending users to manually convert their stuff over and removing
> the files is probably the way to go.

Wontfix ? Really ? Are you that much intent on killing sysvinit ?

Last time I checked, the Policy still required alternative init systems
to be supported by package maintainers. Since it's so easy to override
these settings with systemd (I'm not ironical here, I really don't know
how it's done), what harm would this patch do if it was applied to
satisfy sysvinit users ?

They would have at last the possibility of modifying rpcnfsdopts through
/etc/default/nfs-kernel-server, and thus reliably disable nfsv4, and
systemd users could still do the same through whatever facility systemd
provides and that I'm not aware of.

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Andreas Henriksson]

On Tue, Dec 13, 2016 at 08:55:34PM +0100, Daniel Pocock wrote:
> Hi Ben,
> 
> Thanks for providing this feedback
> 
> I've done the following:
> - forked the upstream repository
> - created a debian/sid branch
> - copied debian/* from jessie into that branch and committed
> - copied debian/* from sid into that branch and committed
[...]

Haven't checked the actual repo, but this sounds horrible to me.

Even just using dgit would likely give you a better history.

I'd instead suggest you do something like this to preserve some
most history:

- clone the existing kernel-team repo
- git reset --hard the master branch to the last tag/commit/whatever
  where the repo and the uploaded packages are in sync.
- do the above for other branches as well if needed.
- import NMUs and other uncommitted uploads.
- git cherry-pick the remaining commits from origin/master, etc.

This would create a repo that's not a fast-forward of the current one
but still preserves as much history etc as possible.

Possibly even better would be to create a fast-forward compatible
repo with a "complex" history. Eg. like this:

- clone the existing kernel-team repo
- checkout a debian-archive branch from the last tag/commit/whatever
  that was in sync with the archive.
- checkout a upstream-archive branch from tha last tag/commit/whatever
  from upstream that was in sync with the archive.
- import uncommitted archive uploads in debian-archive (and upstream-archive
  if needed).
- gbp buildpackage --git-debian-branch=debian-archive 
--git-upstream-branch=upstream-archive --git-tag-only
- merge debian-archive into master and upstream-archive into upstream
- (remove debian-archive and upstream-archive branches, you have tags
   if you ever need a handle to these again.)

HTH.

Regards,
Andreas Henriksson

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Andreas Henriksson]

On Tue, Dec 13, 2016 at 09:52:10PM +0100, Daniel Pocock wrote:
> 
> 
> On 13/12/16 21:40, Raphaël Halimi wrote:
> > Le 13/12/2016 à 21:36, Daniel Pocock a écrit :
> >> Do you think you could investigate a little bit more and add
> >> details to the bug, maybe have a look in Fedora's repositories to
> >> see if they have a way to do that or ask on debian-devel?
> > 
> > I'm not sure I'm the right person for this job, I don't know much
> > about systemd unit files (yet). Maybe someone more experienced with
> > writing them could do this faster, better, and safer.
> > 
> 
> Even if you are not sure, simply spending 10 - 15 minutes hunting for
> an example in another project and adding the links to the bug report
> can give another developer a head-start when they are ready to work on
> the bug.  We are a community project and every contribution, no matter
> how small, can be helpful.

I would suggest tagging these both as wontfix. Adding even more options
to the broken concept of /etc/default just adds to the maintenance burden
of having to carry this over via the nfs-utils_env.sh bridge.

Both /etc/default/nfs-kernel-server and the init script are conffiles.
Edit them directly as you see fit to suite your installation if you're
still using this old stuff. They will not be overwritten on upgrades.

On systemd there's a better concept of overriding settings so you don't
need to (and should avoid to) deal with /etc/default anymore.

I suggest making the long-term goal to get rid of /etc/default.
Automatically handling conversion of users /etc/default over to proper
systemd style overrides would probably be a very fragile if not totally
impossible thing to accomplish though, so just adding NEWS entries
recommending users to manually convert their stuff over and removing
the files is probably the way to go.

Regards,
Andreas Henriksson

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Daniel Pocock]

On 13/12/16 21:40, Raphaël Halimi wrote:
> Le 13/12/2016 à 21:36, Daniel Pocock a écrit :
>> Do you think you could investigate a little bit more and add
>> details to the bug, maybe have a look in Fedora's repositories to
>> see if they have a way to do that or ask on debian-devel?
> 
> I'm not sure I'm the right person for this job, I don't know much
> about systemd unit files (yet). Maybe someone more experienced with
> writing them could do this faster, better, and safer.
> 

Even if you are not sure, simply spending 10 - 15 minutes hunting for
an example in another project and adding the links to the bug report
can give another developer a head-start when they are ready to work on
the bug.  We are a community project and every contribution, no matter
how small, can be helpful.

Regards,

Daniel

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Raphaël Halimi]

Le 13/12/2016 à 21:36, Daniel Pocock a écrit :
> Do you think you could investigate a little bit more and add details
> to the bug, maybe have a look in Fedora's repositories to see if they
> have a way to do that or ask on debian-devel?

I'm not sure I'm the right person for this job, I don't know much about
systemd unit files (yet). Maybe someone more experienced with writing
them could do this faster, better, and safer.

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Daniel Pocock]

On 13/12/16 21:21, Raphaël Halimi wrote:
> Hi guys,
> 
> Sorry to intrude but, since you all seem eager to revive nfs
> packages (which I'm very happy about), could you please take a look
> at #539201 and include my patch ? It would allow to close both this
> bug and #738063, which are both quite old.
> 
> (disclaimer : I don't know yet how to do the same in a systemd unit
> file)
> 

Do you think you could investigate a little bit more and add details
to the bug, maybe have a look in Fedora's repositories to see if they
have a way to do that or ask on debian-devel?

Regards,

Daniel

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Raphaël Halimi]

Hi guys,

Sorry to intrude but, since you all seem eager to revive nfs packages
(which I'm very happy about), could you please take a look at #539201
and include my patch ? It would allow to close both this bug and
#738063, which are both quite old.

(disclaimer : I don't know yet how to do the same in a systemd unit file)

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Daniel Pocock]

On 12/12/16 21:05, Ben Hutchings wrote:
> On Mon, 2016-12-12 at 11:13 +0100, Salvatore Bonaccorso wrote:
>> Hi,
>>
>> On Mon, Dec 12, 2016 at 10:23:49AM +0100, Ferenc Wágner wrote:
> Daniel Pocock  writes:
>>>
 Could either of you comment on this bug?  I saw your names in the
 nfs-utils changelog.  I've seen various problems with NFS under jessie
 and I was hoping to help test if for stretch.
>>>
>>> Hi Daniel,
>>>
>>> I'm not involved in the maintenance of nfs-utils, just reported a
>>> trivial bug that Salvatore kindly fixed in a commit.
>>
>> Same here. Beeing subscribed to the kernel maintainers mailinglist I
>> noticed Ferenc report and didn't want that it get lost and commited to
>> the git repository. Only afterwards noticed some discrepancy between
>> the current version in git, and the one in the archive beeing -9.2. On
>> one side I saw that Ben imported up to -9 the history in git, but the
>> NMU's were never imported.
>>
>> I can very well guess that any help in the maintenance would be
>> welcome.
> 
> I was the one who brought nfs-utils into the kernel team, expecting
> that it would benefit from coordination with kernel maintainers, but
> aside from my contributions in 2009-2011 that hasn't really happened.
> None of the currently listed uploaders has uploaded in the last 2
> years, and the only changes made by regular kernel maintainers have
> been my update to debian/watch and Salvatore's recent addition of
> Ferenc's patch.
> 
> I think it may make more sense to hand over to a new team, rather than
> keeping it with the kernel team.  Daniel apparently wants to be on that
> team.  Who else?
> 
> I notice that the git repository doesn't reflect the package contents
> properly due to the current upstream version being incorrectly
> imported.  The tag names also don't match the current standard format. 
> Here's a repository with those two problems fixed and the recent NMUs
> added:
> 
> https://git.decadent.org.uk/gitweb/?p=nfs-utils.git;a=summary
> 
> (I haven't pushed these changes to Alioth since this is rewriting
> history.  Also, this doesn't include the oldest branches and tags which
> are entirely detached from the current history.)
> 

Hi Ben,

Thanks for providing this feedback

I've done the following:
- forked the upstream repository
- created a debian/sid branch
- copied debian/* from jessie into that branch and committed
- copied debian/* from sid into that branch and committed
- used "git format-patch" and "git am" to copy in changes from your repo
- merged upstream's 1.3.4 tag into debian/sid
- updated patches (many could be dropped)
- other small updates (home page, VCS fields)
- pushed my repo into a new location, collab-maint/nfs-utils

Please have a look at my repository structure and tell me if you feel it
is useful for this project.  If not, my changes could be extracted
easily enough with git format-patch and applied into your repository
with git am and then we could start the collab-maint/nfs-utils
repository over again.

Are you happy for this to live in collab-maint now?  Maybe that will
encourage more collaborators.  I've added a README.source inviting
contributions too.

Regards,

Daniel

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Ben Hutchings]

On Mon, 2016-12-12 at 11:13 +0100, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Mon, Dec 12, 2016 at 10:23:49AM +0100, Ferenc Wágner wrote:
> > > > Daniel Pocock  writes:
> > 
> > > Could either of you comment on this bug?  I saw your names in the
> > > nfs-utils changelog.  I've seen various problems with NFS under jessie
> > > and I was hoping to help test if for stretch.
> > 
> > Hi Daniel,
> > 
> > I'm not involved in the maintenance of nfs-utils, just reported a
> > trivial bug that Salvatore kindly fixed in a commit.
> 
> Same here. Beeing subscribed to the kernel maintainers mailinglist I
> noticed Ferenc report and didn't want that it get lost and commited to
> the git repository. Only afterwards noticed some discrepancy between
> the current version in git, and the one in the archive beeing -9.2. On
> one side I saw that Ben imported up to -9 the history in git, but the
> NMU's were never imported.
> 
> I can very well guess that any help in the maintenance would be
> welcome.

I was the one who brought nfs-utils into the kernel team, expecting
that it would benefit from coordination with kernel maintainers, but
aside from my contributions in 2009-2011 that hasn't really happened.
None of the currently listed uploaders has uploaded in the last 2
years, and the only changes made by regular kernel maintainers have
been my update to debian/watch and Salvatore's recent addition of
Ferenc's patch.

I think it may make more sense to hand over to a new team, rather than
keeping it with the kernel team.  Daniel apparently wants to be on that
team.  Who else?

I notice that the git repository doesn't reflect the package contents
properly due to the current upstream version being incorrectly
imported.  The tag names also don't match the current standard format. 
Here's a repository with those two problems fixed and the recent NMUs
added:

https://git.decadent.org.uk/gitweb/?p=nfs-utils.git;a=summary

(I haven't pushed these changes to Alioth since this is rewriting
history.  Also, this doesn't include the oldest branches and tags which
are entirely detached from the current history.)

Ben.

-- 
Ben Hutchings
If at first you don't succeed, you're doing about average.


signature.asc
Description: This is a digitally signed message part

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Ferenc Wágner]

Daniel Pocock  writes:

> On 12/12/16 10:23, Ferenc Wágner wrote:
>
>> However, I also encountered serious problems deploying NFS (both client
>> and server side) under jessie, and I would agree to team up and help do
>> better for stretch.
>
> Can you tell us if all the problems you saw are already in bug reports?

There are some reports, but they aren't easy to follow.

#830777 is already fixed by the added keyutils dependency.

#748074 is related, but also affects the server side.  It also discusses
an ordering cycle between the units.

The Pipefs-Directory setting in /etc/idmapd.conf (which isn't a
conffile) had to be changed manually after the wheezy -> squeeze
upgrade.

/etc/default/nfs-common says the NEED_ options are autodetected, but
they aren't anymore in squeeze.  (AFAIK upstream split up the service
files, which makes sense.)

The grace interval should be easily configurable in
/etc/default/nfs-common (#601335, but the grace time must also be set).

> Where they problems with nfs-utils or the kernel or something else?
>
> Users have had kernel crashes[1] with NFS on jessie kernels and combined
> with systemd issues, I felt it didn't give a good impression.

I've had one crash since the jessie upgrade, but I haven't got the
console ouput for that.

> I also posted on the linux-fsdevel and linux-nfs mailing lists to see if
> anybody else can give feedback about the optimal version of this package
> to include in Debian before the freeze.

I hope the NFS developers give some input.
-- 
Regards,
Feri

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Salvatore Bonaccorso]

Hi,

On Mon, Dec 12, 2016 at 10:23:49AM +0100, Ferenc Wágner wrote:
> Daniel Pocock  writes:
> 
> > Could either of you comment on this bug?  I saw your names in the
> > nfs-utils changelog.  I've seen various problems with NFS under jessie
> > and I was hoping to help test if for stretch.
> 
> Hi Daniel,
> 
> I'm not involved in the maintenance of nfs-utils, just reported a
> trivial bug that Salvatore kindly fixed in a commit.

Same here. Beeing subscribed to the kernel maintainers mailinglist I
noticed Ferenc report and didn't want that it get lost and commited to
the git repository. Only afterwards noticed some discrepancy between
the current version in git, and the one in the archive beeing -9.2. On
one side I saw that Ben imported up to -9 the history in git, but the
NMU's were never imported.

I can very well guess that any help in the maintenance would be
welcome.

Regards,
Salvatore

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Daniel Pocock]

On 12/12/16 10:23, Ferenc Wágner wrote:
> Daniel Pocock  writes:
> 
>> Could either of you comment on this bug?  I saw your names in the
>> nfs-utils changelog.  I've seen various problems with NFS under jessie
>> and I was hoping to help test if for stretch.
> 
> Hi Daniel,
> 
> I'm not involved in the maintenance of nfs-utils, just reported a
> trivial bug that Salvatore kindly fixed in a commit.
> 
> However, I also encountered serious problems deploying NFS (both client
> and server side) under jessie, and I would agree to team up and help do
> better for stretch.
> 

Hi Ferenc,

Thanks for the feedback

Can you tell us if all the problems you saw are already in bug reports?

Where they problems with nfs-utils or the kernel or something else?

Users have had kernel crashes[1] with NFS on jessie kernels and combined
with systemd issues, I felt it didn't give a good impression.

I also posted on the linux-fsdevel and linux-nfs mailing lists to see if
anybody else can give feedback about the optimal version of this package
to include in Debian before the freeze.

Regards,

Daniel

1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847549

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Ferenc Wágner]

Daniel Pocock  writes:

> Could either of you comment on this bug?  I saw your names in the
> nfs-utils changelog.  I've seen various problems with NFS under jessie
> and I was hoping to help test if for stretch.

Hi Daniel,

I'm not involved in the maintenance of nfs-utils, just reported a
trivial bug that Salvatore kindly fixed in a commit.

However, I also encountered serious problems deploying NFS (both client
and server side) under jessie, and I would agree to team up and help do
better for stretch.
-- 
Regards,
Feri

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Daniel Pocock]

Hi Salvatore, Ferenc,

Could either of you comment on this bug?  I saw your names in the
nfs-utils changelog.  I've seen various problems with NFS under jessie
and I was hoping to help test if for stretch.

https://bugs.debian.org/847681

Regards,

Daniel

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Andreas Henriksson]

On Sat, Dec 10, 2016 at 04:35:46PM +0100, Daniel Pocock wrote:
[...]
> I notice that Andreas made uploads to unstable in June and August 2016:
> 
> http://metadata.ftp-master.debian.org/changelogs/main/n/nfs-utils/unstable_changelog
> 
> while other developers have made unrelated changes in the repository on
> alioth:
> 
> https://anonscm.debian.org/cgit/kernel/nfs-utils.git/log/
> 
> without incorporating the changes uploaded by Andreas and without releasing.
[...]

Fyi, the Vcs-* repo was out of sync even before I got involved in this mess.

Regards,
Andreas Henriksson

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Daniel Pocock]

Package: nfs-utils
Version: 1:1.2.8-9.2
Severity: important
X-Debbugs-CC: andr...@fatal.se

I notice that Andreas made uploads to unstable in June and August 2016:

http://metadata.ftp-master.debian.org/changelogs/main/n/nfs-utils/unstable_changelog

while other developers have made unrelated changes in the repository on
alioth:

https://anonscm.debian.org/cgit/kernel/nfs-utils.git/log/

without incorporating the changes uploaded by Andreas and without releasing.

There are a few small things to fix too:

- the package refers to upstream URLs http://nfs.sourceforge.net/ and
https://sourceforge.net/projects/nfs/

but now upstream is using:

Home page: http://nfs.sourceforge.net/
VCS: http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=summary

The upstream latest version is 1.3.4, maybe it could be packaged for
stretch?  Somebody would need to review each of the patches against
1.2.8 and verify if they have been accepted upstream.

Regards,

Daniel