Bug#998646: RFP: rtpmidid -- RTP MIDI (AppleMIDI) daemon for Linux
Package: wnpp Severity: wishlist Source code at: https://github.com/davidmoreno/rtpmidid License is LGPL 2.1 (library) and GPL3+. Has preliminary deb packaging using `dpkb-buildpackage`. If there is something that I could do to help to package this program, please contact me (dmor...@coralbits.com), or add a bug report at github. Some description: rtpmidid allows you to share ALSA sequencer devices on the network using RTP MIDI, and import other network shared RTP MIDI devices. rtpmidid is an user daemon, and when a RTP MIDI device is announced using mDNS (also known as Zeroconf, Avahi, and multicast DNS) it exposes this ALSA sequencer port.
Bug#744119: help with and sponsoring onion upload
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 dmor...@coralbits.com: 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 dmor...@coralbits.com: 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 z...@debian.org: On 05/01/2014 06:13 PM, David Moreno Montero wrote: 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). Yes, that's fine, as long as in Debian, it does the right thing. 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 Great. Thomas -- David Moreno Montero dmor...@coralbits.com +34 658 18 77 17 http://www.coralbits.com/ http://www.coralbits.com -- David Moreno Montero dmor...@coralbits.com +34 658 18 77 17 http://www.coralbits.com/ http://www.coralbits.com -- David Moreno Montero dmor...@coralbits.com +34 658 18 77 17 http://www.coralbits.com/ http://www.coralbits.com
Bug#744119: help with and sponsoring onion upload
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 dmor...@coralbits.com: 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 z...@debian.org: On 05/01/2014 06:13 PM, David Moreno Montero wrote: 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). Yes, that's fine, as long as in Debian, it does the right thing. 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 Great. Thomas -- David Moreno Montero dmor...@coralbits.com +34 658 18 77 17 http://www.coralbits.com/ http://www.coralbits.com -- David Moreno Montero dmor...@coralbits.com +34 658 18 77 17 http://www.coralbits.com/ http://www.coralbits.com
Bug#744119: help with and sponsoring onion upload
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 z...@debian.org: On 04/25/2014 10:43 PM, David Moreno Montero wrote: 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. 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. 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. 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) -- David Moreno Montero dmor...@coralbits.com +34 658 18 77 17 http://www.coralbits.com/ http://www.coralbits.com
Bug#744119: help with and sponsoring onion upload
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 z...@debian.org: On 05/01/2014 06:13 PM, David Moreno Montero wrote: 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). Yes, that's fine, as long as in Debian, it does the right thing. 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 Great. Thomas -- David Moreno Montero dmor...@coralbits.com +34 658 18 77 17 http://www.coralbits.com/ http://www.coralbits.com
Bug#744119: help with and sponsoring onion upload
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 dmor...@coralbits.com: 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) g...@debian.org: On Thu, Apr 24, 2014 at 5:40 PM, David Moreno Montero dmor...@coralbits.com wrote: If you agree, you may branch the onion source at github, and pull request me the changes. OK, will do. 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. 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. 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. OK, waiting for that. 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? 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 -- David Moreno Montero dmor...@coralbits.com +34 658 18 77 17 +44 74 23 21 01 57 http://www.coralbits.com/ http://www.coralbits.com -- David Moreno Montero dmor...@coralbits.com +34 658 18 77 17 +44 74 23 21 01 57 http://www.coralbits.com/ http://www.coralbits.com
Bug#744119: help with and sponsoring onion upload
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) g...@debian.org: 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 -- David Moreno Montero dmor...@coralbits.com +34 658 18 77 17 +44 74 23 21 01 57 http://www.coralbits.com/ http://www.coralbits.com
Bug#744119: help with and sponsoring onion upload
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) g...@debian.org: On Thu, Apr 24, 2014 at 5:40 PM, David Moreno Montero dmor...@coralbits.com wrote: If you agree, you may branch the onion source at github, and pull request me the changes. OK, will do. 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. 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. 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. OK, waiting for that. 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? 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 -- David Moreno Montero dmor...@coralbits.com +34 658 18 77 17 +44 74 23 21 01 57 http://www.coralbits.com/ http://www.coralbits.com
Bug#744119: RFP: libonion -- lightweight and easy to use HTTP server library
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 z...@debian.org:
On 04/11/2014 03:34 PM, Andrei POPESCU wrote:
Control: reassign -1 wnpp
Control: retitle -1 RFP: libonion -- lightweight and easy to use HTTP
server library
On Jo, 10 apr 14, 14:07:07, David Moreno Montero wrote:
Package: libonion, libonion-dev, libonion-tools, libonion-examples
Severity: wishlist
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.
--David Moreno Montero
Hi David,
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: #XX)
with XX 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)
--
David Moreno Montero
dmor...@coralbits.com
+34 658 18 77 17
+44 74 23 21 01 57
http://www.coralbits.com/
http://www.coralbits.com
