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

Groups > linux.debian.kernel > #56085 > unrolled thread

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

Back to article view | Back to linux.debian.kernel

Contents

  Bug#847681: packaging repository and sid diverging? Various fixes needed. Daniel Pocock <daniel@pocock.pro> - 2016-12-10 16:40 +0100
    Bug#847681: packaging repository and sid diverging? Various fixes needed. Andreas Henriksson <andreas@fatal.se> - 2016-12-10 17:00 +0100
      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. Nye Liu <nyet@nyet.org> - 2017-02-03 10:50 +0100
                                  Bug#847681: packaging repository and sid diverging? Various fixes needed. Nye Liu <nyet@nyet.org> - 2017-02-03 11:00 +0100
                                    Bug#847681: packaging repository and sid diverging? Various fixes needed. Nye Liu <nyet@nyet.org> - 2017-02-03 11:10 +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 →

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

Package: nfs-utils
Version: 1:1.2.8-9.2
Severity: important
X-Debbugs-CC: andreas@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

[toc] | [next] | [standalone]

#56086

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

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

#56106

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] | [prev] | [next] | [standalone]

#56109

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]

#56110

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]

#56113

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]

#56112

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]

#56118

[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]

#56129

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]

#56131

[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]

#56132

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]

#56133

[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]

#56134

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]

#56136

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]

#56141

[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]

#56148

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]

#56255

[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]

#56886

On Sat, 17 Dec 2016 04:54:21 +0100 =?UTF-8?Q?Rapha=c3=abl_Halimi?=
<raphael.halimi@gmail.com> 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.

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

#56887

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"

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

#56888

On Fri, 3 Feb 2017 01:55:10 -0800 Nye Liu <nyet@nyet.org> 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.

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.kernel

csiph-web