#744119 RFP: libonion -- lightweight and easy to use HTTP server library

Package:
wnpp
Source:
wnpp
Submitter:
David Moreno Montero
Date:
2014-09-24 09:21:04 UTC
Severity:
wishlist
#744119#5
Date:
2014-04-10 12:07:07 UTC
From:
To:
I'm the developer of libonion, a C HTTP server library with bindings for
C++. I would love to see it packaged for Debian. It has a working debian
directory that packages all needed files.

https://github.com/davidmoreno/onion

License is both GPLv2+ and Apache2 for the main library. AGPLv3 for the
examples and tools.

#744119#8
Date:
2014-04-11 07:34:06 UTC
From:
To:
Control: reassign -1 wnpp
Control: retitle -1 RFP: libonion -- lightweight and easy to use HTTP server library

#744119#17
Date:
2014-04-12 01:50:26 UTC
From:
To:
It is a bad practice to ship a debian folder upstream. I would advice
you to at least rename it as something like "debian-upstream", so that
it doesn't conflict with the debian folder that will be worked on by the
maintainer of the package.

Now, a few remarks about your packaging.

1/ If you want to have your package in Debian, please clean the
debian/changelog, and write a single entry:

  * Intial release (Closes: #XXXXXX)

with XXXXXX the number of the ITP (Intention To Package) bug number (you
can open such a bug using "reportbug -b wnpp").

2/ There's no need to use debian/compat level 7 anymore. Increase this
to 9, as well as debhelper build-depends.

3/ Standards-Version: is now 3.9.5, fix that.

4/ Please rewrite your debian/copyright file in DEP5 format:
http://dep.debian.net/deps/dep5/

5/ The debian/libonion-dev.dirs is useless, remove it. Same for
debian/libonion.dirs

6/ The files usr/bin/interactive, usr/bin/fileserver, usr/bin/crl have a
way too much generic names, and may conflicts with other packages.
Please rename them (and possibly other files too).

7/ Switch to 3.0 (quilt) format for your debian source. To do so:

mkdir debian/source
echo "3.0 (quilt)" >debian/source/format

8/ Remove the comments in debian/rules, these are useless.

9/ Remove debian/README, there's nothing interesting there. Same with
README.source. There's a Homepage: field for this.

10/ Vcs-Git: and Vcs-Browser: are fields for the *packaging* urls, not
for your upstream source code.

11/ libonion-dev should depend on libonion (= ${binary:Version}

12/ libonion should be rename with as the soname. For example: libonion2

13/ libonion should use ${shlibs:Depends}, therefore there's no reason
that you even manually write the dependencies.

If you correct the above, I may sponsor your package upload in Debian.

Cheers,

Thomas Goirand (zigo)

#744119#22
Date:
2014-04-23 15:28:12 UTC
From:
To:
Hi,

I just commited the changes to the debian branch (
https://github.com/davidmoreno/onion/tree/debian).

About not using the debian directory, just now is to ease the compilation
by third parties. I would really love to keep the debian packaging there at
least by the moment, to help on current debian installations to easy create
the packages.

If you see any other necesary change, please contact me.

Regards,
David.






2014-04-12 3:50 GMT+02:00 Thomas Goirand <zigo@debian.org>:

#744119#27
Date:
2014-04-24 00:33:44 UTC
From:
To:
I am 100% sure of it. Just move that folder to another branch and
provide a debian/gbp.conf to use it, or rename it.

I will not have the time to review the changes right now, but you can
ping me in about a week of time, and I can review your package again.

Thomas

#744119#32
Date:
2014-04-24 14:13:17 UTC
From:
To:
Hi David, Thomas,

Wanted to package onion myself and while David may or may not would
like me as a co-maintainer, I'm here to help him get onion properly
packaged and uploaded.
I don't have problems with upstream have debian/ in its tree. Source
format 3.0 (quilt) is here to replace with the official Debian one.

But there are important upstream bugs.
First, the source needs to be repackaged to be DFSG, as
examples/oterm/static/jquery-1.4.3.min.js is minified and needs to be
removed.
Then libraries are not versioned. Only *.so's are produced. :( Please
read point 3.1.1 [1] to understand why this is important.

Other problems are there. For example no manpages for the binaries.
The current standards-version is 3.9.5 . Also, debian/copyright is
just a template. Attached a mostly finished one, which still doesn't
cover the examples, tests or tools (those are AGPLv3+) nor
src/onion/sd-daemon.[ch] (MIT).

Regards,
Laszlo/GCS
[1] http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

#744119#37
Date:
2014-04-24 15:40:18 UTC
From:
To:
Great! you are more than welcome! I'm strugling with some parts of it.

If you agree, you may branch the onion source at github, and pull request
me the changes.

About jquery, is it ok to include it non-minified? Also could be used
straight from the jquery CDN, but somehow I feel users would feel more
secure if its using only local resources.

About library versioning, I just added it, but I got a bug report that its
not following proper libtool standards. I'm still fixing that, but the
current solution should be on the debian branch.

About manpages, I can try to prepare them ASAP, but some tips are welcome
about how to create great manpages: which programs/commands? is groff the
recomended way?

About license, add myself to debian/*, if you use part of whatever is there
right now.

Thank you very much!


2014-04-24 16:13 GMT+02:00 László Böszörményi (GCS) <gcs@debian.org>:

#744119#42
Date:
2014-04-24 16:19:59 UTC
From:
To:
 OK, will do.
 Better if not. 1) Not all users will have internet access for CDN. 2)
jQuery may have performance / security issues anytime. Just depend on
the needed version, as it's already packaged and taken care of.
 OK, waiting for that.
 For a start you may use 'apt-get install help2man; man help2man'.

One more problem btw. LICENSE.txt states: "Contents of the src folder
(the Library) is licensed under both GPLv2+ and Apache 2." while
README.rst states: "The library is under the LGPL license, [...]"
(which one?), then see a file, for example src/onion/block.c which has
only Apache 2.0 license header. Which one is correct? Then you link
together everything with src/onion/sd-daemon.[ch] which is licensed
under MIT. I'm not a license expert and don't know what the result
will be. Does linking MIT with (L)GPL code allowed? Where's / how MIT
license vanished from the resulting library?

Laszlo/GCS

#744119#47
Date:
2014-04-24 16:44:16 UTC
From:
To:
You are right about sd-daemon.[ch] file, I forgot about it. I think I can
remove it as its included in libsystemd-daemon-dev. I add the bug to the
onion issue tracker to do it asap.

The proper license for src (except that files) is both GPLv2 and Apache2. I
just changed the README.rst.


2014-04-24 18:19 GMT+02:00 László Böszörményi (GCS) <gcs@debian.org>:

#744119#52
Date:
2014-04-25 14:43:46 UTC
From:
To:
Just a quick note to inform that I just removed the sd-daemon.[ch] files
and I depend on system provided ones (at libsystemd-daemon-dev).

Also fixed jquery, I added the uncompressed one.

Currently its not in control / depends, as I want to make my head if it
should be enforced or not, but as systemd is on Debian's future, I guess it
fits.

Regads,


2014-04-24 18:44 GMT+02:00 David Moreno Montero <dmoreno@coralbits.com>:

#744119#57
Date:
2014-05-01 08:00:23 UTC
From:
To:
Shipping non-minified javascript in your source is a requirement of
Debian for all source packages, so what you did is a good thing.
However, we also require that you use all libraries that are packaged in
the system. So you must use the jquery which is in Debian. And yes, you
must comply with both rules, which means even if you don't use the
jquery which you ship in your source code, it must *not* be minified.
Just wanted to make this clear.

You shouldn't force your users to use systemd if you can avoid it. We
have chosen systemd as default, but our users may not like it and prefer
another init system. Please respect the user choices if possible.

Cheers,

Thomas Goirand (zigo)

#744119#62
Date:
2014-05-01 10:13:44 UTC
From:
To:
I will check how to do the jquery but it might be dificult as onion should
be compilable on non debian as well. Is is ok if at compilation time it is
decided to use the onion provided one, or the system one? If the system one
is used then its is not compiled in (jquery is converted to a C file to be
used as static data).

About systemd, onion will never force the user to use it. The support is
just to compile the functionallity to be able to cooperate better with
systemd, if the developer decides so. It is always optional to use systemd,
but the library must be prepared. Even if the developer of whatever uses
onion decides to support systemd, it still can be used without it.
http://0pointer.de/blog/projects/socket-activation.html


2014-05-01 10:00 GMT+02:00 Thomas Goirand <zigo@debian.org>:

#744119#67
Date:
2014-05-01 18:01:36 UTC
From:
To:
Yes, that's fine, as long as in Debian, it does the right thing.

Great.

Thomas

#744119#72
Date:
2014-05-01 23:11:11 UTC
From:
To:
Hi,

I just pushed to the debian branch the change to try to use the system wide
jquery.

jQuery is used at runtime, but it also need to check jQuery file exists at
compile time, so both dependencies are added to control file.

Regards,


2014-05-01 20:01 GMT+02:00 Thomas Goirand <zigo@debian.org>:

#744119#77
Date:
2014-05-13 19:46:24 UTC
From:
To:
Hi Thomas and Laszlo,

its been some time with no news about next step to help getting onion into
Debian, Is there something I can do to help?

Regards,
David


2014-05-02 1:11 GMT+02:00 David Moreno Montero <dmoreno@coralbits.com>:

#744119#82
Date:
2014-09-24 09:18:48 UTC
From:
To:
Hi,

sorry to bother again, but it seems this RFP has become stalled.

Is there anything I can do to resume the process to try to be incuded in
debian?

I would love to be included in Debian Jessie, and time is running out.

Regards,
David

2014-05-13 21:46 GMT+02:00 David Moreno Montero <dmoreno@coralbits.com>: