Bug#774928: ITP: libcoap -- library for the CoAP protocol written in C

[Carsten Schoenert]

Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: libcoap
  Version : 4.1.1
  Upstream Author : Olaf Bergmann 
* URL : http://sourceforge.net/projects/libcoap/
* License : GPL2+ and BSD
  Programming Lang: C
  Description : C Library Implementation of CoAP

The libcoap is basically a C implementation of the IETF CoAP
(Constrained Application Protocol). The CoAP protocol is major
standardized by the IETF in the RFC 7252 and is a application layer
protocol for low power devices for the Internet of Things (IoT) and 
Machine to Machine (M2M) communication.

CoAP is mostly used in 6loWPAN environments. The libcoap library
provides functions to talk to such devices and makes it possible to
interact with low power IPv6 based devices.

There are some other frameworks written in Java, Python or JavaScript
that implement CoAP bindings. As far as I know there is nothing yet
packaged for the use of the CoAP protocol. That's the main reason why
I want to package and maintain the libcoap package.

Currently the upstream source is lacking some minor tweaks like
versioning of the library and also symbol versioning. The build
environment is improvable. I'm in contact with Olaf Bergmann to improve
the situation here. He is willing to take some external hints and work
so after tuning the build process it will be easier to package the 
libcoap.

I don't need a sponsor, happily Guido Guenther is willing to upload the 
package after checking my work.

http://coap.technology/
http://www.ietf.org/rfc/rfc7252.txt
http://6lowapp.net/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUr5JGAAoJEIMBYBQlHR2wlWQQAJVL/LoGm2vUQp4V79mMpiLP
o3Dj3/cv73iAn4FWPDOoXdK7ic7OdA3u36nllYdYhMQGak2pNFtxe+foBGDxmISt
3I7cpolX8qmej+zOLb64aZ0XGRwjolXM5ZppID8aXpRHPWm0JPNEovyOqY83T33C
6qRJ3c96TuDN3Xn+k0oYW9uVRI5WwvtQfyUUk6A27gnPUnxaiq2jBJkYOWaS5mvu
AlRExGj/koouB0k+C2VHfq6HYQd3JoS/suxYjWJC/PIRaO7HRiR87iHFxwsI39xl
VsozSUzHw3WE+FcxC8aPmnrfFSMA65UgYtkjmgdv9JokT4r9hL3xB/n28ZS0XeZK
7Plr7yRYg1SzmYnjb2U4lCVkDwfCo32MQ+e5DdDE2dbDl3XOwnZ9RIXU812CzUoV
nz+zdIvGhnwPSa+lahTXDGDENYGuPkhA46qqd3q7kVlRvEgECOo0XYe/0cjsrAnl
C8ZX11RyAc2cvB+1pOFUb7ZOfmWzJI8L4m9UBkPjFL5kmSDoY1K/tJtOv7uycb9I
xhUv8IsIaJusQSVlNyQeXFQ2Daq7JzilKC9L2Q3A2qRlQXtTAgtaLp5Rqrnoe9iQ
XiQDa2iPpDUOR0j38oaT8wVpbzpgACPpPUIu2oDek3ugGRTWTfpaa5ZoweZ5qZPA
tlH+sxDm9fNoyU3+o2Fp
=cGu7
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150109083310.18537.12719.report...@x201s.cruise.homelinux.net

length of a package extended description

[Vincent Lefevre]

Some texlive-* packages (and perhaps others) have a huge extended
description, e.g. more than 1900 lines for texlive-latex-extra!

Shouldn't the length be limited by the Debian policy?

Otherwise shouldn't utilities (such as "dpkg -s") provide a
configurable way to limit the output of the "Description:" field?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150109135625.ga23...@xvii.vinc17.org

Re: length of a package extended description

[Marco d'Itri]

On Jan 09, Vincent Lefevre  wrote:

> Shouldn't the length be limited by the Debian policy?
Shouldn't the length be limited by common sense?
In this case I think that listing the packages without the description 
of each one would be enough...

-- 
ciao,
Marco


pgpbuMAQ6Ch9n.pgp
Description: PGP signature

Re: length of a package extended description

[Ian Jackson]

Marco d'Itri writes ("Re: length of a package extended description"):
> On Jan 09, Vincent Lefevre  wrote:
> > Shouldn't the length be limited by the Debian policy?
>
> Shouldn't the length be limited by common sense?

Yes.

> In this case I think that listing the packages without the description 
> of each one would be enough...

Vincent, perhaps you would care to file a bug with a patch which
reduces the description to a plausible size ?

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21679.64428.31496.80...@chiark.greenend.org.uk

Re: length of a package extended description

[Adam Majer]

On Fri, Jan 09, 2015 at 02:56:25PM +0100, Vincent Lefevre wrote:
> Some texlive-* packages (and perhaps others) have a huge extended
> description, e.g. more than 1900 lines for texlive-latex-extra!
> 
> Shouldn't the length be limited by the Debian policy?
> 
> Otherwise shouldn't utilities (such as "dpkg -s") provide a
> configurable way to limit the output of the "Description:" field?

In this specific case, the length is not a bad thing. It allows for
efficient keyword search, for example. You can limit what is shown by
using dpkg-query instead. For example, you can exclude description
completely.

My pet peeve with long descriptions has to do with copy/pasting large
blocks for *every* *single* *binary*, then adding a one line "This
package has debug symbols" or similar. Then a keyword search hits
every single binary...

- Adam

-- 
Adam Majer
ad...@zombino.com


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150109155139.ga21...@mira.lan.galacticasoftware.com

Re: length of a package extended description

[Vincent Lefevre]

On 2015-01-09 16:02:52 +, Ian Jackson wrote:
> Vincent, perhaps you would care to file a bug with a patch which
> reduces the description to a plausible size ?

I reported

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774942

but the maintainer disagrees.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150109164045.ga30...@xvii.vinc17.org

Re: length of a package extended description

[Adam Borowski]

On Fri, Jan 09, 2015 at 02:56:25PM +0100, Vincent Lefevre wrote:
> Some texlive-* packages (and perhaps others) have a huge extended
> description, e.g. more than 1900 lines for texlive-latex-extra!
>
> Shouldn't the length be limited by the Debian policy?

Some data: count of packages with descs of a given length:
  1-  4 13772
  5-  9 21324
 10- 14 6531
 15- 19 2433
 20- 24 872
 25- 29 288
 30- 39 175
 40- 49 42
 50- 59 19
 60- 69 13
 70- 79 5
 80- 89 7
 90- 89 3
100 1
110-119 7
120-150 3
151-199 4
203 1
257 1
277 1
325 1
350 1
437 1
19351

Top perpetrators:
 107 texlive-latex-recommended
 110 collectd-core
 111 texlive-math-extra
 112 dtv-scan-tables
 114 tcllib
 118 texlive-lang-english
 119 texlive-extra-utils
 119 texlive-lang-european
 125 devscripts
 137 texlive-science
 152 fastaq
 161 gimp-plugin-registry
 187 nagios-plugins-contrib
 193 texlive-pstricks
 203 texlive-bibtex-extra
 257 texlive-pictures
 277 texlive-publishers
 325 ttf-aenigma
 350 irssi-scripts
 437 texlive-fonts-extra
1935 texlive-latex-extra

All of the above counts are for unstable/main.  Contrib has nothing above
100 lines, non-free has:

207 w3-recs
251 firmware-linux-nonfree

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150109164110.ga7...@angband.pl

Re: length of a package extended description

[Ian Jackson]

Adam Borowski writes ("Re: length of a package extended description"):
> Some data: count of packages with descs of a given length:
...

Here's Adam's data with cumulative package count, and cumulative
percentage:

>   1-  4 13772 13772  30%
>   5-  9 21324 35096  77%
>  10- 14 6531  41627  91%
>  15- 19 2433  44060  96%
>  20- 24 872   44932  98%
>  25- 29 288   45220  99%
>  30- 39 175   45395  99%
>  40- 49 4245437  99%
>  50- 59 1945456  99%
>  60- 69 1345469  99%
>  70- 79 5 45474  99%
>  80- 89 7 45481  99%
>  90- 89 3 45484  99%
> 100 1 45485  99%
> 110-119 7 45492  99%
> 120-150 3 45495  99%
> 151-199 4 45499  99%
> 203 1 45500  99%
> 257 1 45501  99%
> 277 1 45502  99%
> 325 1 45503  99%
> 350 1 45504  99%
> 437 1 45505  99%
> 19351 45506  100%

Of course as maintainers we all have a natural tendency to think our
own package is more important and interesting than other packages.
That kind of comes with the territory.  That means that the average
description will tend to be longer than any agreed target average
description length.

But, worse, it appears that some maintainers aren't able to exercise
their discretion on this question in a manner which most of the rest
of us would consider reasonable.

IMO a proportionate response would be a target, and a hard limit, in
policy.

I would say:

  The extended Description should ideally fit within 14 lines.
  It must not be longer than 24 lines.

The target of 14 lines would be missed only by 8.5% of packages and
the limit of 24 lines breached only by 1.26% of packages.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21680.2628.183409.841...@chiark.greenend.org.uk

Re: length of a package extended description

[Norbert Preining]

Hi everyone,

(I am not subscribed to Cc, due to obvious reasons, so please Cc
me any further *relevant* remarks - I don't care for the rants)

concerning Vincent's email: he mentioned that:
> but the maintainer disagrees.
but he did not mention that:
* half of the package descriptions are empty lines, to make each
  contained CTAN package a single paragraph
* this change was made on request of the translators
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493778

It is an extremely useful feature to search for CTAN package names
as well as keywords in the short description of CTAN packages.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150109200356.gh11...@auth.logic.tuwien.ac.at

Re: length of a package extended description

[Riley Baird]

> Otherwise shouldn't utilities (such as "dpkg -s") provide a
> configurable way to limit the output of the "Description:" field?

You can pipe the output to "head" or "tail" to sort of achieve what you
want to.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54b0349c.3060...@bitmessage.ch

Re: length of a package extended description

[Vincent Lefevre]

On 2015-01-10 07:05:48 +1100, Riley Baird wrote:
> > Otherwise shouldn't utilities (such as "dpkg -s") provide a
> > configurable way to limit the output of the "Description:" field?
> 
> You can pipe the output to "head" or "tail" to sort of achieve what you
> want to.

Obviously not. It may be possible with something like sed or perl,
but this may not be future-proof, and breakage due to changes in
the dpkg output may remain unnoticed. And doing that automatically
would need to write a dpkg wrapper, which could break dpkg in other
contexts.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150109215948.ga8...@xvii.vinc17.org

Re: length of a package extended description

[Vincent Lefevre]

On 2015-01-10 05:03:56 +0900, Norbert Preining wrote:
> Hi everyone,
> 
> (I am not subscribed to Cc, due to obvious reasons, so please Cc
> me any further *relevant* remarks - I don't care for the rants)
> 
> concerning Vincent's email: he mentioned that:
> > but the maintainer disagrees.
> but he did not mention that:
> * half of the package descriptions are empty lines, to make each
>   contained CTAN package a single paragraph

The blank lines are not the only problem. Removing them would be a
big step forward, but the description would actually still be much
too long (more than 900 lines).

> * this change was made on request of the translators
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493778

This bug report says: "too long package description". This is the
main problem.

The issue with the translations is just a consequence, but also
just because the translators don't use a properly designed tool.
The correct solution would be to fix the tool (e.g. to support
lists), not to introduce lots of blank lines useless for the end
user.

> It is an extremely useful feature to search for CTAN package names
> as well as keywords in the short description of CTAN packages.

Instead, some texlive package should provide a tool to search for
CTAN packages. Thus would be more useful: from some keywords, the
user would get the exact CTAN package name(s), instead of just
the Debian package "texlive-latex-extra", which doesn't give much
information. Moreover this would avoid false positives in one way
or the other: getting too many results is just bad as getting
nothing. A text file may be sufficient, since such a file is
searchable.

Similarly, for the same reason to be able to search via apt-cache,
the extended description of every Debian package could include each
executable they provide with an associated short description. But
this would be insane.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150109222346.gb8...@xvii.vinc17.org

Re: length of a package extended description

[Don Armstrong]

On Fri, 09 Jan 2015, Vincent Lefevre wrote:
> The blank lines are not the only problem. Removing them would be a big
> step forward, but the description would actually still be much too
> long (more than 900 lines).

Lines aren't really the issue here; the primary one is space in the
Packages file[1], and the secondary one is utility for users.

Every extra line is only an extra byte, after all.

It would probably be ideal if there was a better way of indicating which
latex modules were in each texlive package than currently, but until a
better method is found, this is probably the best of bad options.


1: By that I mean if we're going to make an arbitrary line in the sand
in policy, it should be based on bytes, not lines.
--
Don Armstrong  http://www.donarmstrong.com

Three little words. (In order of importance.)
 █ 
   █  ▌  ▞▀▖▌ ▌▛▀▘
   █  ▌  ▌ ▌▝▞ ▛▀  you 
   █  ▀▀▘▝▀  ▘ ▀▀▘
 █  -- hugh macleod "Three Words"


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150109225613.ga10...@rzlab.ucr.edu

Re: length of a package extended description

[Riley Baird]

On 10/01/15 08:59, Vincent Lefevre wrote:
> On 2015-01-10 07:05:48 +1100, Riley Baird wrote:
>>> Otherwise shouldn't utilities (such as "dpkg -s") provide a
>>> configurable way to limit the output of the "Description:" field?
>>
>> You can pipe the output to "head" or "tail" to sort of achieve what you
>> want to.
> 
> Obviously not. It may be possible with something like sed or perl,
> but this may not be future-proof, and breakage due to changes in
> the dpkg output may remain unnoticed. And doing that automatically
> would need to write a dpkg wrapper, which could break dpkg in other
> contexts.

True. I honestly think that this is such an insignificant problem that
updating the sed or perl script every so often wouldn't be that much of
a problem.

If it interests you, you could always right a patch for dpkg; it doesn't
seem that it would be that hard to do so, and I don't see any reason why
the patch would be refused.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54b06962.8000...@bitmessage.ch

Bug#775016: ITP: hovercraft -- impress.js presentations by reStructuredText

[Daniel Stender]

Package: wnpp
Severity: wishlist
Owner: Daniel Stender 

* Package name: hovercraft
  Version : 2.0b1
  Upstream Author : Lennart Regebro 
* URL : https://github.com/regebro/hovercraft
* License : Expat
  Programming Lang: Python
  Description : impress.js presentations by reStructuredText

Hovercraft is a frontend to create impress.js based presentations
easily through reST source. For details see the docs [1] and, if available,
the article on it in UK Linux User & Developer 146 [2].

Greetings,
Daniel Stender

[1] https://hovercraft.readthedocs.org/en/latest/

[2] N. Tiwari: Designing exciting presentations easily with Hovercraft.
In: Linux User & Developer 146, pp. 44-47


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150110025453.6960.63253.report...@varuna.fritz.box

Re: length of a package extended description

[Russ Allbery]

Don Armstrong  writes:

> It would probably be ideal if there was a better way of indicating which
> latex modules were in each texlive package than currently, but until a
> better method is found, this is probably the best of bad options.

+1.  I cannot overstate how useful it is to have this sort of thing appear
in a field searchable by apt-cache.

We have enough packages with this issue that maybe it would be worth
designing some other way to allow this, but until then, please keep the
lists in packages like this or firmware-linux-nonfree so that apt-cache
search can find the right package.  And having at least *some* description
for humans to view with a pager and forward search is really nice.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/878uhbux9y@hope.eyrie.org

Re: length of a package extended description

[Matthias Klumpp]

2015-01-10 4:31 GMT+01:00 Russ Allbery :
> Don Armstrong  writes:
>
>> It would probably be ideal if there was a better way of indicating which
>> latex modules were in each texlive package than currently, but until a
>> better method is found, this is probably the best of bad options.
>
> +1.  I cannot overstate how useful it is to have this sort of thing appear
> in a field searchable by apt-cache.
>
> We have enough packages with this issue that maybe it would be worth
> designing some other way to allow this, but until then, please keep the
> lists in packages like this or firmware-linux-nonfree so that apt-cache
> search can find the right package.  And having at least *some* description
> for humans to view with a pager and forward search is really nice.

A possible solution designed for this kind of issue could be DEP-11[1].
Unfortunately, not even the AppStream part of this thing is ready yet,
but I am certain that we will have it for Stretch.
(and can then extend it for useful usecases)

[1]: https://wiki.debian.org/DEP-11

-- 
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKNHny8iX8WzgLW=2_xppovrvke3stjq477bdjvanpj-yjt...@mail.gmail.com

Re: length of a package extended description

[Christian PERRIER]

Quoting Vincent Lefevre (vinc...@vinc17.net):

> The issue with the translations is just a consequence, but also
> just because the translators don't use a properly designed tool.


I very much like such answers. Really.

Short followup: patches welcomed. Please note that this is against a
basecode that is very loosely maintained but is still working fairly
well for gazillions of other packages.

Please also note that identifying "lists" in package descriptions
might be a very interesting thing to do, given the various way you
(maintainers) all have to make lists, given the loose rules for
writing package descriptions (just think about bullets not being
standardized and neither are wordwrapping rules).

So, even shorter followup: what you suggest is impossible.and will
even break hundreds (thousands?) of existing translations. 

So, no, "fixing" the "translators tools" is not an option. Whether or
not texlive-* packages are "too long" is a debate I already had with
Norbert in the bug report he mentioned. He gave a rationale which
doesn't entirely satisfies mebut makes sense and I decided that we
both have better things to do than argue over this...:-)




signature.asc
Description: Digital signature