Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #790177 > unrolled thread

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

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#847681: packaging repository and sid diverging? Various fixes needed. Daniel Pocock <daniel@pocock.pro> - 2016-12-12 08:00 +0100
    Bug#847681: packaging repository and sid diverging? Various fixes needed. wferi@niif.hu (Ferenc Wágner) - 2016-12-12 10:30 +0100
      Bug#847681: packaging repository and sid diverging? Various fixes needed. Daniel Pocock <daniel@pocock.pro> - 2016-12-12 10:40 +0100
        Bug#847681: packaging repository and sid diverging? Various fixes needed. wferi@niif.hu (Ferenc Wágner) - 2016-12-12 11:40 +0100
      Bug#847681: packaging repository and sid diverging? Various fixes needed. Salvatore Bonaccorso <carnil@debian.org> - 2016-12-12 11:20 +0100
        Bug#847681: packaging repository and sid diverging? Various fixes needed. Ben Hutchings <ben@decadent.org.uk> - 2016-12-12 21:10 +0100
          Bug#847681: packaging repository and sid diverging? Various fixes needed. Daniel Pocock <daniel@pocock.pro> - 2016-12-13 21:10 +0100
            Bug#847681: packaging repository and sid diverging? Various fixes needed. Raphaël Halimi <raphael.halimi@gmail.com> - 2016-12-13 21:30 +0100
              Bug#847681: packaging repository and sid diverging? Various fixes needed. Daniel Pocock <daniel@pocock.pro> - 2016-12-13 21:40 +0100
                Bug#847681: packaging repository and sid diverging? Various fixes needed. Raphaël Halimi <raphael.halimi@gmail.com> - 2016-12-13 21:50 +0100
                  Bug#847681: packaging repository and sid diverging? Various fixes needed. Daniel Pocock <daniel@pocock.pro> - 2016-12-13 22:00 +0100
                    Bug#847681: packaging repository and sid diverging? Various fixes needed. Andreas Henriksson <andreas@fatal.se> - 2016-12-13 22:20 +0100
                      Bug#847681: packaging repository and sid diverging? Various fixes needed. Raphaël Halimi <raphael.halimi@gmail.com> - 2016-12-13 23:10 +0100
                        Bug#847681: packaging repository and sid diverging? Various fixes needed. Andreas Henriksson <andreas@fatal.se> - 2016-12-14 08:30 +0100
                          Bug#847681: packaging repository and sid diverging? Various fixes needed. Raphaël Halimi <raphael.halimi@gmail.com> - 2016-12-17 05:00 +0100
            Bug#847681: packaging repository and sid diverging? Various fixes needed. Andreas Henriksson <andreas@fatal.se> - 2016-12-13 22:50 +0100
              Bug#847681: packaging repository and sid diverging? Various fixes needed. Daniel Pocock <daniel@pocock.pro> - 2016-12-14 08:20 +0100
                Bug#847681: packaging repository and sid diverging? Various fixes needed. Andreas Henriksson <andreas@fatal.se> - 2016-12-14 08:40 +0100
                  Bug#847681: packaging repository and sid diverging? Various fixes needed. Daniel Pocock <daniel@pocock.pro> - 2016-12-14 09:50 +0100
                    Bug#847681: packaging repository and sid diverging? Various fixes needed. Sven Geggus <lists@fuchsschwanzdomain.de> - 2016-12-14 10:40 +0100
                      Bug#847681: packaging repository and sid diverging? Various fixes needed. Daniel Pocock <daniel@pocock.pro> - 2016-12-14 11:10 +0100
                        Bug#847681: packaging repository and sid diverging? Various fixes needed. Sven Geggus <lists@fuchsschwanzdomain.de> - 2016-12-14 12:20 +0100
                          Bug#847681: packaging repository and sid diverging? Various fixes needed. Daniel Pocock <daniel@pocock.pro> - 2016-12-14 13:40 +0100
                            Bug#847681: packaging repository and sid diverging? Various fixes needed. Sven Geggus <lists@fuchsschwanzdomain.de> - 2016-12-15 10:00 +0100
                              Bug#847681: packaging repository and sid diverging? Various fixes needed. Daniel Pocock <daniel@pocock.pro> - 2016-12-15 10:00 +0100
                          Bug#847681: packaging repository and sid diverging? Various fixes needed. Robbie Harwood <rharwood@club.cc.cmu.edu> - 2016-12-15 03:00 +0100
                    Bug#847681: packaging repository and sid diverging? Various fixes needed. Ben Hutchings <ben@decadent.org.uk> - 2016-12-15 01:40 +0100
            Bug#847681: packaging repository and sid diverging? Various fixes needed. Ben Hutchings <ben@decadent.org.uk> - 2016-12-14 23:50 +0100
              Bug#847681: packaging repository and sid diverging? Various fixes needed. Daniel Pocock <daniel@pocock.pro> - 2016-12-15 11:50 +0100
                Bug#847681: packaging repository and sid diverging? Various fixes needed. Daniel Pocock <daniel@pocock.pro> - 2016-12-15 14:40 +0100

Page 1 of 2  [1] 2  Next page →

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

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

[toc] | [next] | [standalone]

#790216

Daniel Pocock <daniel@pocock.pro> 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

[toc] | [prev] | [next] | [standalone]

#790219

On 12/12/16 10:23, Ferenc Wágner wrote:
> Daniel Pocock <daniel@pocock.pro> 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

[toc] | [prev] | [next] | [standalone]

#790292

Daniel Pocock <daniel@pocock.pro> 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

[toc] | [prev] | [next] | [standalone]

#790258

Hi,

On Mon, Dec 12, 2016 at 10:23:49AM +0100, Ferenc Wágner wrote:
> Daniel Pocock <daniel@pocock.pro> 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

[toc] | [prev] | [next] | [standalone]

#790459

[Multipart message — attachments visible in raw view] — view raw

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 <daniel@pocock.pro> 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.

[toc] | [prev] | [next] | [standalone]

#790712

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 <daniel@pocock.pro> 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

[toc] | [prev] | [next] | [standalone]

#790716

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#790719

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

[toc] | [prev] | [next] | [standalone]

#790727

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#790730

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

[toc] | [prev] | [next] | [standalone]

#790736

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

[toc] | [prev] | [next] | [standalone]

#790748

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#790814

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

[toc] | [prev] | [next] | [standalone]

#791658

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#790742

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

[toc] | [prev] | [next] | [standalone]

#790810

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

[toc] | [prev] | [next] | [standalone]

#790818

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

[toc] | [prev] | [next] | [standalone]

#790840

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/

[toc] | [prev] | [next] | [standalone]

#790856

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.bugs.dist

csiph-web