Bug#786810: ITA: xl2tpd -- layer 2 tunneling protocol implementation

[Roberto C . Sánchez]

On Fri, May 13, 2016 at 08:42:56PM +0200, Vincent Zweije wrote:
> 
> It looks like things have got easier for me:
> * Upstream has incorporated the changes you had in quilt patches, removing the
>   need for quilt.
> * Upstream has removed the RFC text, removing the need for repacking.
> * Upstream has modified its debian directory to *almost* work, except that the
>   changelog file is bogus.
> 
> That last point doesn't matter really, as upstream's debian directory
> is discarded by dpkg-source -x anyway. Still, their changes to their
> debian directory can be taken over.
> 
The main thing with the debian/ directory is that git-buildpackage
expects there to be a "clean" upstream branch, usually called upstream
and with no Debian-specific changes in it, and another Debian branch,
usually called master and containing only Debian-specific packaging
changes.  I don't believe that upstream's repository enforces this
distinction.  That, along with the need to repack the source to remove
the non-free RFC text, pushed me toward simply importing the upstream
release tarballs (after they had been repacked) into my own repository
and working with the code that way.

> Am I correct in concluding that you were importing upstream releases
> whenever they came out, and not using git to merge their sources?
> 
That is correct.  I was using uscan to download the release tarball
(which got repacked by uscan) and then git-import-orig import it into my
repository.

> I'm considering stopping repacking upstream sources. Is there a concensus
> in Debian on whether it is better not to repack and be as close to
> upstream as possible, or to repack to get the debian directory out of
> there and save some space? Or is it just left up to the maintainer?
> 
I thin kthe consensus is to repack only when necessary.  If an upstream
tarball gets repacked, then it is no longer possible for a user to
compare the hash of the .orig.tar.gz to the hash of the corresponding
release tarball from upstream.  It is desirable to have the .orig.tar.gz
and upstream's release tarball be identical whenever possible.

Eliminating a problematic debian/ directory is certainly a valid reason
to repack.

> Do you have a close contact with upstream, or should I go through the
> regular channels? This in connection with forwarding the RC bug upstream.
> 
The only person from upstream with whom I had regular contact has moved
on a couple of years ago.  I would recommend just approaching them
through whatever normal public channels they have available.

Regards,

-Roberto

-- 
Roberto C. Sánchez


signature.asc
Description: Digital signature

Bug#786810: ITA: xl2tpd -- layer 2 tunneling protocol implementation

[Vincent Zweije]

On Wed, May 11, 2016 at 10:50:06PM -0400, Roberto C. Sánchez wrote:

||  http://anonscm.debian.org/cgit/users/roberto/xl2tpd.git/

I've cloned it, thanks.

||  As far as the upstream repository goes, upstream previously tried to
||  always merge my Debian packaging into their repository.  Of course, they
||  did it on the master branch (probably owing to the fact that they were
||  probably still on Subversion when they began this practice).  In any
||  event, it caused problems every time I tried to make a new upstream
||  release.  If you look in the debian/ directory if repo I just published,
||  you will see a repack.sh script.  That script removes upstream's debian/
||  directory and a non-free RFC text that they ship in their tarball.

It looks like things have got easier for me:
* Upstream has incorporated the changes you had in quilt patches, removing the
  need for quilt.
* Upstream has removed the RFC text, removing the need for repacking.
* Upstream has modified its debian directory to *almost* work, except that the
  changelog file is bogus.

That last point doesn't matter really, as upstream's debian directory
is discarded by dpkg-source -x anyway. Still, their changes to their
debian directory can be taken over.

Am I correct in concluding that you were importing upstream releases
whenever they came out, and not using git to merge their sources?

I'm considering stopping repacking upstream sources. Is there a concensus
in Debian on whether it is better not to repack and be as close to
upstream as possible, or to repack to get the debian directory out of
there and save some space? Or is it just left up to the maintainer?

Do you have a close contact with upstream, or should I go through the
regular channels? This in connection with forwarding the RC bug upstream.

Vincent.
-- 
Vincent Zweije    | "If you're flamed in a group you
  | don't read, does anybody get burnt?"
[Xhost should be taken out and shot] |-- Paul Tomblin on a.s.r.


signature.asc
Description: PGP signature

Bug#786810: ITA: xl2tpd -- layer 2 tunneling protocol implementation

[Roberto C . Sánchez]

Hi Vincent.

On Wed, May 11, 2016 at 09:43:33PM +0200, Vincent Zweije wrote:
> 
> In the mean time, I've cloned upstream git from
> https://github.com/xelerance/xl2tpd.git and checked it out. It seems
> to build fine. I still have to figure out what current bugs are fixed
> upstream, I'll get onto that.
> 
> There are some commits by you but I guess that is not the history that
> you're talking about. I'd like to take a look at your repo. If you can
> put it up somewhere I'll clone it. Do you mind if I make it public?
> 
I'm sorry I missed your previous mail.  I am apparently not subscribed
to this bug.  I have pushed my local xl2tpd repository here:

http://anonscm.debian.org/cgit/users/roberto/xl2tpd.git/

Of course, you are welcome to make it public :-)

As far as the upstream repository goes, upstream previously tried to
always merge my Debian packaging into their repository.  Of course, they
did it on the master branch (probably owing to the fact that they were
probably still on Subversion when they began this practice).  In any
event, it caused problems every time I tried to make a new upstream
release.  If you look in the debian/ directory if repo I just published,
you will see a repack.sh script.  That script removes upstream's debian/
directory and a non-free RFC text that they ship in their tarball.

Let me know if you have any other questions or if you require any
additional information.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Bug#786810: ITA: xl2tpd -- layer 2 tunneling protocol implementation

[Vincent Zweije]

Control: retitle -1 ITA: xl2tpd -- layer 2 tunneling protocol implementation

[taking the liberty of replying to you directly as well]

On Sun, May 08, 2016 at 02:50:45PM +0200, Vincent Zweije wrote:

||  Ah, getting up to speed with current debian building practices. I have
||  some reading to do. :-/

Well. Nothing very new in the fine documention. I can work with that.

||  ||  Additionally, I have the complete package history in Git back to version
||  ||  1.1.11.  If you like, I can clone my local repository onto
||  ||  git.debian.org so that you can clone it from there and maintain the
||  ||  complete history.
||  ||
||  ||  Let me know if you would like for me to do this.  Also, if you have any
||  ||  questions about the package please don't hesitate to ask.
||
||  Good, I prefer to main complete history.

In the mean time, I've cloned upstream git from
https://github.com/xelerance/xl2tpd.git and checked it out. It seems
to build fine. I still have to figure out what current bugs are fixed
upstream, I'll get onto that.

There are some commits by you but I guess that is not the history that
you're talking about. I'd like to take a look at your repo. If you can
put it up somewhere I'll clone it. Do you mind if I make it public?

Vincent.
-- 
Vincent Zweije    | "If you're flamed in a group you
  | don't read, does anybody get burnt?"
[Xhost should be taken out and shot] |-- Paul Tomblin on a.s.r.


signature.asc
Description: PGP signature