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 2 of 2 — ← Prev page 1 [2]

#56138

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]

#56147

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]

#56149

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]

#56150

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]

#56154

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]

#56158

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

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

#56162

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

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

#56164

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

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

#56194

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

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

#56195

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

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

#56181

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

Sven Geggus <lists@fuchsschwanzdomain.de> 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

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

#56180

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

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.

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

#56172

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

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.

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

#56198

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

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

#56203

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web