[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#535905: Fwd: ITP: shellinabox for Debian


Just for the record, I would like to forward all the private
converstation I had with upstream developer for `shellinabox'

Forwarded conversation
Subject: ITP: shellinabox for Debian

From: Hector Oron <hector.oron@gmail.com>
Date: 2010/8/22
To: markus@shellinabox.com
Cc: zodiac@gmail.com

Hello Markus,

 I would like to help you out to get `shellinabox' software in
Debian. Please, ping me if you are interested. You and zodiac are the
same individual person?

Best regards,
 Héctor Orón

From: Markus Gutschke <markus@gutschke.com>
Date: 2010/8/23
To: Hector Oron <hector.oron@gmail.com>
Cc: markus@shellinabox.com

I would certainly appreciate help with getting ShellInABox into
Debian. Somebody else contacted me a good while ago, I did some work
that they asked for (that's what you see in distributions/debian/),
but then they never replied back to me.
I guess, they must have gotten too busy with other things. I can
relate to that. That's why ShellInABox currently has a somewhat
embarrasing number of open bugs. Fortunately, most of them are minor.
So, when I have more time, I should be able to cut down that number
quite quickly.
I am very motivated to get it into the distribution though, so I'll
prioritize anything you might ask for.

From: Hector Oron <hector.oron@gmail.com>
Date: 2010/8/24
To: Markus Gutschke <markus@gutschke.com>

Hello Markus,

2010/8/23 Markus Gutschke <markus@gutschke.com>:
Do you remember who was it?
First of all, do you want me to be maintainer (then I do the work) or
do you want me to sponsor the package for you (then I'll be your
mentor -- http://mentors.debian.net/cgi-bin/welcome).


From: Markus Gutschke <markus@gutschke.com>
Date: 2010/8/24
To: Hector Oron <hector.oron@gmail.com>

I believe, there have been a total of at least three people who
contacted me about packaging ShellInABox, but after a single e-mail, I
never heard back from them...
But at least one Debian developer, Martin Meredith, did in fact
exchange several e-mails with me. I think, that was around Christmas
last year. He had several requests for changes I should make. This
resulted in me updating the "commit" script so that it generates files
in "distribution/debian" whenever a new official release is made.
After a couple of days of working with him, he seemed to have dropped
off. No big deal. Maybe, he just didn't want to take on this project
after all. And at least he helped me get a little closer to getting
the code into a shape that will eventually be acceptable.
I don't think I want to become an official Debian developer. I very
much respect the process and the general high-quality of Debian
developers. But I don't think I am personally all that interested in
doing this. So, I would prefer if you were the official maintainer.
Having said that, I want to make your life as easy as possible. If
there is something I can do as the upstream author, that helps you
avoid unnecessary work, I will try my best to accommodate you. That's
really what I was shooting for with the files at
Ideally, they should be about as close to what you need as I can
possibly come.
If I did my job correctly, the amount of patches that you need to
carry should be minimal.
As a side note, I generally try to maintain sole authorship of the
core product, as it makes things easier should there ever be a need to
relicense the code (fortunately, so far, everybody has been happy with
my choice of GPLv2). But I don't mind if I'll end up with
distribution-specific files that have a separate copyright holder.
That is unlikely to preclude me from relicensing the core part of the
Should I in fact ever decide to change the license, then it is most
likely just going to be a dual-license. So, GPLv2 is never going to go
away if I have anything to say about it.

From: Markus Gutschke <markus@gutschke.com>
Date: 2010/8/24
To: Hector Oron <zumbi@debian.org>

On Tue, Aug 24, 2010 at 10:18 AM, Hector Oron <zumbi@debian.org> wrote:
> You do not need to be Debian developer to maintain a package, you just need a Debian developer that sponsors
> the package.

I didn't realize that this was an option. In that case, I really don't
feel particularly strongly either way. I have already done a good
amount of the work that is needed for packaging. So I don't mind
continuing to do that. But I also don't feel strongly that I need to
maintain ownership of that part of the project. So, if you prefer, you
can take over. Whatever seems easier.
> As upstream, it is recommended you to release a tarball, then distributors take the tarball and package it.
> It is very nice on your side to be willing to provide a debian directory, but it is likely to get bit-rot after
> sometime, it is prefered to keep packaging separated from upstream work. That is (again) why I asked you if you
> wanted to be involved in the packaging decissions.

As I am running a Debian-derived distribution myself (Ubuntu), and as
I am maintaining a few machines that run older Debian releases, I am
very likely to always have a "debian" directory. It is just easier for
me and my users, if they can call "dpkg-buildpackage" whenever they
want to build from sources.
Having said that, packages that are built this way, are likely to be a
little different from packages that are built for an official Debian
release. Differences are likely to be minor, but probably always exist
to some degree, due to different policy decisions.
In order to avoid bitrot or unneeded divergence between my upstream
source tree and the official packages, I am using the "commit" script
whenever I check code into subversion.
If you read through the script, you will see that whenever I update
the version number for ShellInABox, the "commit" script will check-in
updated archive files that are intended for use by the distribution.
It also makes any minor adjustments that are needed. At this point,
that involves making sure the package is not-native, and making sure
the correct compatibility level is used.
This approach should minimize the risk of bitrot. I am perfectly happy
to either edit my "debian" directory or my "commit" script to make any
other changes that might be needed. If that means I should be the
official Debian maintainer for ShellInABox, that is fine with me.
And if you think this approach is all wrong, then please educate me. I
want to play along with Debian's policies, but I might not necessarily
be aware of all of them.
> I have not yet closely look to the code, but i saw your code links to openssl, so that is not allowed in Debian,
> maybe you need to include an exception:
>  http://en.wikipedia.org/wiki/GPL_linking_exception
>  http://people.gnome.org/~markmc/openssl-and-the-gpl.html
>  http://lintian.debian.org/tags/possible-gpl-code-linked-with-openssl.html

I include the required exception in the COPYING file. Please let me
know, if you think this is insufficient. When building a Debian
package, I also generate the lintian overrides that state that I have
checked the license for compatibility.
Furthermore, I always make sure that the source code can be built
without OpenSSL, if the user prefers that. This really only makes
sense if used in combination with a reverse proxy. But for some users
that's OK.

> or you could link against gnutls as `curl' does:
>  http://packages.qa.debian.org/c/curl.html

Unfortunately, I require some OpenSSL features that have never been
ported to GNUTLS. I have an idea how I might be able to avoid use of
these features. But it involves a major rewrite of parts of the code.
So, this is relatively low priority.
> Now running lintian...
> W: shellinabox source: debhelper-but-no-misc-depends shellinabox

Thanks. That must be new recently. I am going to update the project to
include the dependency.

> W: shellinabox source: dh-clean-k-is-deprecated

That's one of the minor differences that I referred to. I am trying to
keep the subversion sources in a state that they can be built even on
older distributions. But obviously, for inclusion in the distribution,
this backwards compatibility isn't needed.
The "commit" script fixes the differences. And if you look in
"distributions/debian/" you will find archives that pass this
particular lintian check.
If you have a better suggestion for making sure that the sources build
on old distributions and that they still pass modern lintian checks,
then I would definitely be interested in knowing about it.

> W: shellinabox source: maintainer-script-lacks-debhelper-token debian/shellinabox.postinst
> W: shellinabox source: maintainer-script-lacks-debhelper-token debian/shellinabox.postrm

Hmm, I don't see these errors. Is this something new in Debian that
hasn't been picked up by Ubuntu yet? I should probably figure out how
to set up a Debian chroot environment.

> W: shellinabox source: package-lacks-versioned-build-depends-on-debhelper 7

I think, that is probably fixed in the file that is generated by the
"commit" script. But I need to double-check when I have the Debian
> W: shellinabox source: debian-rules-ignores-make-clean-error line 58

Haven't seen this one before. That must be something new in lintian.

> W: shellinabox source: ancient-standards-version 3.6.1 (current is 3.9.1)

The "commit" script should probably update this field. As I said, I
want to be able to build on old distributions, but also support all
new requirements.

> E: shellinabox: possible-gpl-code-linked-with-openssl

You should not get this error when building from the files generated
by the "commit" script. Let me think if there is some way I can fix
this for the case when you are building from the subversion

> Finished running lintian.

I just saw that there now is a newer source format. That actually
might make things easier. I'll have to read up on it.
Also, can you advise on whether it is still recommended that I avoid
building native packages?

From: Markus Gutschke <markus@gutschke.com>
Date: 2010/8/24
To: Hector Oron <zumbi@debian.org>

I fixed two minor issues and I now no longer getting any lintian
errors or warnings when running "lintian -v -I
N: Setting up lab in /tmp/TzkP1RRVln ...
N: Processing 1 packages...
N: ----
N: Processing source package shellinabox (version 2.10-1) ...
N: Removing /tmp/TzkP1RRVln ...
I tested this on a Debian/Sid chroot running in x86-64 mode. Let me
know, if I am doing something wrong and I should run other tests as
I probably should try to understand how the new source format works
and switch over to that. Let me know, if I should still try to keep my
code non-native, or if it is preferred to create a native package. I
had the impression that the consensus started to change a little bit.
And I'd like to do whatever is considered most appropriate.

From: Hector Oron <hector.oron@gmail.com>
Date: 2010/8/25
To: Markus Gutschke <markus@gutschke.com>


Do you mind if i forward previous conversation to the original bug
report and continue there?

From: Markus Gutschke (顧孟勤) <markus@gutschke.com>
Date: 2010/8/25
To: Hector Oron <hector.oron@gmail.com>

By all means. Yes, please do whatever makes most sense and follows
Debian's common policies. As I said, I am somewhat unaware of the more
subtle details of this process.

From: Hector Oron <hector.oron@gmail.com>
Date: 2010/9/15
To: "Markus Gutschke (顧孟勤)" <markus@gutschke.com>

Hello Markus,

2010/8/25 Markus Gutschke (顧孟勤) <markus@gutschke.com>:
Apologies I have been busy with bunch of all other stuff, but I have
not forgot you yet.

If you are going to keep the debian directory in the sources and you
are willing to maintain this software in Debian, I would not mind to
sponsor the package (I just check it and upload to archive) once it is
in good shape.

A debian-upstream@lists.debian.org is in the way, so it might help you
out clarify some concepts, there is also
debian-mentors@lists.debian.org which should be the way you should

Please review http://mentors.debian.net and http://wiki.debian.org/UpstreamGuide

Best regards,
 Héctor Orón

Reply to: