Bug#805543: ITP: ruby-simple-form -- library to simplify the creation of forms in Rails applications
Package: wnpp Severity: wishlist Owner: Antonio Terceiro * Package name: ruby-simple-form Version : 3.2.0 Upstream Author : Plataformatec * URL : https://github.com/plataformatec/simple_form * License : Expat Programming Lang: Ruby Description : library to simplify the creation of forms in Rails applications Simple Form provides a stack of components that can be invoked to create complete HTML inputs on Rails application , which by default contains label, hints, errors and the input itself. Simple Form reduces duplication and helps having a consistent form usage across the application. -- Antonio Terceiro signature.asc Description: PGP signature
Work-needing packages report for Nov 20, 2015
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 674 (new: 4) Total number of packages offered up for adoption: 176 (new: 1) Total number of packages requested help for: 50 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: catdoc (#805507), orphaned yesterday Description: MS-Word to TeX or plain text converter Reverse Depends: libkf5filemetadata-bin Installations reported by Popcon: 5589 nexus (#805446), orphaned yesterday Description: NeXus scientific data file format Reverse Depends: libnexus0-dev libnexus0-java nexus-tools python-nxs python-sardana Installations reported by Popcon: 49 syslinux (#805268), orphaned 3 days ago Description: collection of bootloaders (DOS FAT and NTFS bootloader) Reverse Depends: bootcd cobbler cobbler-common drbl fai-nfsroot grml2usb grub-imageboot koan libguestfs0 ltsp-client-core (5 more omitted) Installations reported by Popcon: 14932 wizznic (#805267), orphaned 3 days ago Description: Implementation of the arcade classic Puzznic Reverse Depends: wizznic Installations reported by Popcon: 43 670 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: libnss-gw-name (#805266), offered 3 days ago Description: nss module that names the current gatewayâs IP address Reverse Depends: freedombox-setup Installations reported by Popcon: 29 175 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apt-xapian-index (#567955), requested 2117 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: goplay muon muon-discover packagesearch Installations reported by Popcon: 48866 athcool (#278442), requested 4041 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 29 awstats (#755797), requested 484 days ago Description: powerful and featureful web server log analyzer Installations reported by Popcon: 4217 balsa (#642906), requested 1516 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 699 cardstories (#624100), requested 1669 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 8 cups (#532097), requested 2357 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups boomaga chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client (64 more omitted) Installations reported by Popcon: 162897 cyrus-sasl2 (#799864), requested 57 days ago Description: authentication abstraction library Reverse Depends: 389-admin 389-ds-base 389-ds-base-libs 389-dsgw adcli autofs-ldap cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier claws-mail-address-keeper (123 more omitted) Installations reported by Popcon: 187428 debtags (#567954), requested 2117 days ago Description: Enables support for package tags Reverse Depends: goplay packagesearch Installations reported by Popcon: 2121 developers-reference (#759995), requested 446 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 18081 devscripts (#800413), requested 51 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero bzr-builddeb customdeb debci debian-builder debmake debpear (26 more omitted) Installations reported by Popcon: 12870 ejabberd (#767874), requested 381 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib ejabberd-mod-cron ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mod-logxml ejabberd-mod-mam-mnesia ejabberd-mod-message-log ejabberd-mod-muc-log-http ejabberd-mod-post-log ejabberd-mod-rest (4 more omitted) Installations reported by Popcon: 777 fbcat (#565156), requested 2136 days ago Description: framebuffer grabber Installations reported by Popcon: 164
Re: certificate creation in postinst, potentially using letsencrypt script
On 08/05/2015 07:11 AM, Thorsten Glaser wrote: Bas Wijnen debian.org> writes: Certificates are placed in /etc/ssl/certs/. No, in /etc/ssl. /etc/ssl/certs/ is for Root CA certificates *only*. (sorry for responding to a very old message) Really? I've often put the local machine's cert(s) in there. The private key goes in private, and the certificate in certs. That's also how, for example, the autogenerated snakeoil cert works. That's where make-ssl-cert puts it. If this isn't how its supposed to be used, that's surprising, and especially if its actually a security issue, ought to be documented in at least one of: - a README in /etc/ssl/ or /etc/ssl/certs - man update-ca-certificates - /usr/share/doc/ca-certificates/README.Debian - /usr/share/doc/openssl/README.Debian - bug #26406 (just kidding) all of which I checked, and they either don't exist (that first one) or don't say to only put CA certs in /etc/ssl/certs. And as noted above, ssl-cert puts the default snakeoil certs there—so that's the path you see in, e.g., shipped config files. Which naturally suggests to the admin that's where they belong.
Re: certificate creation in postinst, potentially using letsencrypt script
Quoting Anthony DeRobertis (2015-11-20 03:06:20) > On 08/05/2015 07:11 AM, Thorsten Glaser wrote: >> Bas Wijnen debian.org> writes: >> >>> Certificates are placed in /etc/ssl/certs/. >> No, in /etc/ssl. /etc/ssl/certs/ is for Root CA certificates *only*. > > (sorry for responding to a very old message) Thanks for doing so. > Really? I've often put the local machine's cert(s) in there. The private > key goes in private, and the certificate in certs. > > That's also how, for example, the autogenerated snakeoil cert works. > That's where make-ssl-cert puts it. > > If this isn't how its supposed to be used, that's surprising, and > especially if its actually a security issue, ought to be documented in > at least one of: > > - a README in /etc/ssl/ or /etc/ssl/certs > - man update-ca-certificates > - /usr/share/doc/ca-certificates/README.Debian > - /usr/share/doc/openssl/README.Debian > - bug #26406 (just kidding) > > all of which I checked, and they either don't exist (that first one) or > don't say to only put CA certs in /etc/ssl/certs. > > And as noted above, ssl-cert puts the default snakeoil certs there—so > that's the path you see in, e.g., shipped config files. Which naturally > suggests to the admin that's where they belong. > Really: Thanks: You describe *exactly* my line of thought, which lead me to my current location of local CAcert.org-issued certificates. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#805603: ITP: lua-nginx-string -- String utilities and common hash functions for the nginx embedded Lua language
Package: wnpp Severity: wishlist Owner: "ChangZhuo Chen (陳昌倬)" * Package name: lua-nginx-string Version : 0.09 Upstream Author : Yichun "agentzh" Zhang (章亦春) * URL : https://github.com/openresty/lua-resty-string * License : BSD-2-clause Programming Lang: lua Description : String utilities and common hash functions for the nginx embedded Lua language -- ChangZhuo Chen (陳昌倬) Debian Developer Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D signature.asc Description: PGP signature
Bug#805606: ITP: lua-nginx-dns -- DNS resolver for the nginx embedded Lua language
Package: wnpp Severity: wishlist Owner: "ChangZhuo Chen (陳昌倬)" * Package name: lua-nginx-dns Version : 0.14 Upstream Author : Yichun "agentzh" Zhang (章亦春) * URL : https://github.com/openresty/lua-resty-dns * License : BSD-2-clause Programming Lang: lua Description : DNS resolver for the nginx embedded Lua language -- ChangZhuo Chen (陳昌倬) Debian Developer Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D signature.asc Description: PGP signature
Bug#805607: ITP: piler -- genomic repeat analysis
Package: wnpp Severity: wishlist Owner: Debian Med Packaging Team * Package name: piler Version : 0~20140707 Upstream Author : Robert Edgar * URL : http://www.drive5.com/piler/ * License : Public Domain Programming Lang: C, C++ Description : genomic repeat analysis PILER (Parsimonious Inference of a Library of Elementary Repeats) searches a genome sequence for repetitive elements. It implements search algorithms that identify characteristic patterns of local alignments induced by certain classes of repeats. This package will be maintained by the Debian Med team.
Re: PCRE package naming
On 10/22/2015 10:47 AM, Matthew Vernon wrote: The natural thing to call the PCRE2 packages is pcre2, but that's going to lead to confusion - ISTM that something that makes it clear that PCRE2 is newer than PCRE is desirable. And, obviously, PCRE & PCRE2 need to be co-installable. There are already libpcre16-3 and libpcre32-3 packages. That doesn't seem to have lead to confusion. Quite possibly because libpcre* is normally installed by apt automatically as a dependency, so the vast majority of users don't need to think about the package name. Seems like the developers who are going to install -dev package could be helped by something in the short & long description. E.g., something as simple as putting "Old" and "New" in front of the short description, and then explaining in the long description. And the pcregrep package doesn't have a 3 in it currently, so it's not a problem.
