Bug#1081966: ITP: uwsgi-plugin-lua -- Lua WSAPI plugin for uWSGI (Lua 5.1)
Package: wnpp X-Debbugs-Cc: debian-devel@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-lua Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : Lua WSAPI plugin for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the Lua plugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-lua Alex
Bug#1081281: ITP: uwsgi-plugin-psgi -- Perl PSGI and Coro::AnyEvent plugins for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-devel@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-psgi Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : Perl PSGI and Coro::AnyEvent plugins for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the psgi plugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-psgi Alex
Bug#1081280: ITP: uwsgi-plugin-rados -- Ceph/RADOS storage plugin for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-devel@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-rados Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : Ceph/RADOS storage plugin for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the rados plugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-rados Alex
Bug#1081279: ITP: uwsgi-plugin-glusterfs -- GlusterFS storage plugin for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-devel@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-glusterfs Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : GlusterFS storage plugin for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the glusterfsplugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-glusterfs Alex
Bug#1081278: ITP: uwsgi-plugin-gccgo -- Go plugin for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-devel@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-gccgo Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : Go plugins for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the Go plugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-gccgo Alex
Bug#1079857: ITP: uwsgi-plugin-ruby -- Ruby plugins for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-devel@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-ruby Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : ruby plugins for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the ruby java plugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-ruby Alex
Bug#1078547: ITP: uwsgi-plugin-java -- java plugins for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-devel@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-java Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : java plugins for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the java plugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-java Alex
Bug#1078544: ITP: uwsgi-apache2-mod -- apache2 modules for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-devel@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-apache2-mod Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : apache2 modules for uWSGI uWSGI source packages build many plugins and even apache2 modules. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins and apache2 modules. This new source package proposes to build the apache2 modules packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-apache2-mod Alex
Bug#1078541: ITP: uwsgi-plugin-python -- python plugins for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-devel@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-apache2-mod Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : apache2 modules for uWSGI uWSGI source packages build many plugins and even apache2 modules. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins and apache2 modules. This new source package proposes to build the apache2 modules packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-apache2-mod Alex
Bug#1078541: ITP: uwsgi-plugin-python -- python plugins for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-devel@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-python Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : python plugins for uWSGI uWSGI source packages build many plugins. Somes plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the python packages from a separate source package, as this has been done for php, mongo and luajit. Initial packaging is here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-python Alex
Vendoring an unmaintained library?
Hi, Unvendoring libraries that are already in Debian seems like the pragmatic approach to lower code duplication and be closer to better packaging pratices. #1073005 asks for the vendoring back of an unvendored library, arguing that this particular library is unmaintained upstream, implying that the vendored fork is better maintained. My view on this is that if the vendored fork is better maintained, the vendored fork should become the upstream of the Debian package. I've read through https://bugs.debian.org/907051 (policy bug: Say much more about vendoring of libraries) and do feel I understand the rules and the philosophy behind those rules. On the other side I do not want to make it harder for downstream distributions packagers to do their work for no good reason. Seeking additional advice here. Thanks, Alex
Bug#1060071: ITP: libjs-jush -- JavaScript Syntax Highlighter
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: libjs-jush Version : 2.0.2+git20210206+1 Upstream Contact: Jakub Vrana * URL : https://jush.sourceforge.io/ * License : Apache-2.0 Programming Lang: JavaScript Description : JavaScript Syntax Highlighter JavaScript Syntax Highlighter can be used for client-side syntax highlighting of following languages: HTML, CSS, JavaScript, PHP, SQL, HTTP and SMTP protocol, php.ini and Apache config. This is required to build the database web interface adminerevo (ITP #1055329). This has been embedded in src:adminer for years. Part of it is available in src:jquery-goodies .
Bug#1056067: ITP: node-sass-loader -- css loader module for webpack
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: node-sass-loader Version : 13.3.2 Upstream Contact: J. Tangelder * URL : https://github.com/webpack-contrib/sass-loader * License : MIT Programming Lang: Javascript Description : css loader module for webpack Webpack takes code targeted at node.js and makes it run in the browser. Node.js comes with API of its own that is not available in the browsers. Webpack exposes this code to programs that are unaware they are running in a browser. Sass is a CSS preprocessor to include features that don’t exist in CSS yet like nesting, mixins, inheritance, and other nifty goodies that help write robust, maintainable CSS. This package is enables webpack to include and compile Sass files into a web application bundle. Node.js is an event-based server-side JavaScript engine. This is required to build some webapps. I'll be seeking a sponsor for this. Thanks, Alex
Bug#1055329: ITP: adminerevo -- Web-based database administration tool
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: adminerevo Version : 4.8.3 Upstream Contact: Lionel Laffineur * URL : https://docs.adminerevo.org/ * License : Apache-2.0 Programming Lang: PHP Description : Web-based database administration tool Adminerevo (forked from adminer) is a full-featured database management tool written in PHP. Conversely to phpMyAdmin, it is a light weight application with these priorities in order: security, user experience, performance, feature set and size. adminerevo is a community maintained version of adminer. Ultimately, src:adminer will be removed from the archive. adminerevo would then provide a transitional dummy pakage. This will be maintained on salsa in the Debian group. I already maintain src:adminer as a DM and will need a sponsor for this new package. Thanks, Alex
Re: Bug#967966: ITP: collectd-graph-panel -- web-based graphing app for collectd statistics
Hi, > Package: wnpp > Severity: wishlist > Owner: Joseph Nahmias > > * Package name: collectd-graph-panel > Version : 1 > Upstream Author : Pim van den Berg > * URL : http://pommi.nethuis.nl/category/cgp/ > * License : GPL3 > Programming Lang: PHP > Description : web-based graphing app for collectd statistics > > Collectd Graph Panel (CGP) is a graphical web-based front-end for > visualizing RRD collected by collectd, written in the PHP language. The author seems[1] to have migrated to grafana now, so maybe this won't be maintained upstream. [1] https://cloud-infra.engineer/collectd-influxdb-grafana-with-downsampling/ Alex
Re: Loading big dashboard page
Hi, > For almost a month now, I have been unable to load my dashboard page > https://udd.debian.org/dmd/?d...@jones.dk - probably because I am involved > in too many packages (which makes it _more_ relevant to get an overview > like the dashboard page). > > Anyone know about workarounds - maybe pass some magic option to let it > be more patient before timing out? As a workaround, the following page provides similar information. https://qa.debian.org/developer.php?login=d...@jones.dk Alex
Re: IPv6 problem for one debian mirror
> Vincent Danjean, on Wed 08 Feb 2017 01:05:51 +0100, wrote: >> However, the machine answers to IPv4 connections but not to IPv6 >> $ time wget -6 ftp.fr.debian.org >> --2017-02-08 00:53:58-- http://ftp.fr.debian.org/ >> Résolution de ftp.fr.debian.org (ftp.fr.debian.org)… 2a01:e0c:1:1598::2 >> Connexion à ftp.fr.debian.org (ftp.fr.debian.org)|2a01:e0c:1:1598::2|:80… ^C > > No problem here (Orange ISP). > >> So, who should be contacted to fix this problem (ie either remove >> the IPv6 for debian.proxad.net. or makes this machine to answer again >> to IPv6 or change the ftp.fr.debian.org alias or ...) ? > > It's between your ISP and free. Unfortunately ipv6 is not so well > connected, the Cogent IPv6 network is for instance notably *not* > connected to google, so I wouldn't be surprised to see other such > issues. Which is your ISP? That's probably where to start. No problem here (french ISP Free). I had this problem once, and it was because I had improperly configure the MTU of my default route. It was configured as 1500 (default) because I wanted to have a static ipv6 address and my connexion needs it to be set as 1480. Compare the result of the following command between SLAAC and manual configuration. $ ip -6 route | grep default default via fe80::1 dev br0 proto ra metric 1024 expires 1714sec mtu 1480 hoplimit 64 Alex
Re: Bug#807019: tracking bin-num - broken unison due to binnmu upload
Hi, >> The change done in unison 2.48 to overcome this looks pretty big... I'm >> not sure I'll be able/willing to provide a unison2.40.102 any more. >> Moreover, this package was created to provide compatibility with >> previous Debian releases, but another change in OCaml 4.02 makes it >> incompatible anyway (both communicating unisons need to be compiled with >> the same version of OCaml in practice, which won't be the case any more >> when one side is Debian stable, and the other Debian testing). IMHO, >> that's a design flaw in Unison that cannot be easily fixed. >> > > A possible way out for stable (and old-stable) users could be to use 2.48 > from backports, when 2.48 will be packaged and migrated to testing. The backport is indeed a nice way out of this, the rebuild is straightforward (only tried for amd64). http://sousmonlit.zincube.net/~niol/apt/pool/main/u/unison/unison_2.48.3-1~bpo80+1.dsc This should be integrated in the backports.d.o repositories. Alex
Bug#735154: ITP: sockjs-twisted -- Simple library for adding SockJS support to a twisted application
Package: wnpp Severity: wishlist Owner: Alexandre Rossi * Package name: sockjs-twisted Version : 1.2.1 Upstream Author : Christopher Gamble * URL : http://github.com/Fugiman/sockjs-twisted * License : BSD Programming Lang: Python Description : Simple library for adding SockJS support to a twisted application SockJS-Twisted passes all SockJS-Protocol v0.3.3 tests, and all SockJS-Client qunit tests. In addition to basic SockJS usage, it supports : - hosting multiple SockJS services off of one port, - offering of static resources, dynamic pages, and SockJS endpoints off of a single port, - multiplexing. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140113101017.19312.73245.reportbug@ripley
Bug#707093: ITP: libhtmlcleaner-java -- Java HTML Parser library
Package: wnpp Severity: wishlist Owner: Alexandre Rossi * Package name: libhtmlcleaner-java Version : 2.2 Upstream Author : Vladimir Nikic * URL : http://htmlcleaner.sourceforge.net/ * License : BSD Programming Lang: Java Description : Java HTML Parser library HtmlCleaner can be used in java code, as command line tool or as Ant task. It is designed to be small, independent (no runtime dependencies except JRE 1.5+), fast and flexible (its behavior is configurable through number of parameters). Although the main motive was to prepare ordinary HTML for XML processing with XPath, XQuery and XSLT, structured data produced by HtmlCleaner may be consumed and handled in many other ways. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130507120552.2351.46046.reportbug@ripley
Bug#565946: ITP: remotepad-server -- Server for mouse/keyboard X11 remote control using Apple's iPhone
Package: wnpp Severity: wishlist Owner: Alexandre Rossi * Package name: remotepad-server Version : 1.10 Upstream Author : Kawamoto Yosihisa * URL : http://www.tenjin.org/RemotePad/ * License : GPL and BSD-like Programming Lang: C Description : Server for mouse/keyboard X11 remote control using Apple's iPhone RemotePad is an open source application that controls the mouse cursor of your desktop PC. This way, you can use your iPhone or iPod touch as a wireless touchpad! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#463973: ITP: deejayd -- A media player daemon
> > Yes. Apparently what's special about this is that it can be > > controlled over the network. Probably not the only one but > > noticeable enough to be mentioned in a short description. > > mpd also supports that (tcp/6600). Yep this project is very similar to mpd. As far as I know, it improves over mpd with the following features : - play queue - video support (this is also an advantage over XMMS2 but I do not know this project well enough to do a full comparison) - xine or gstreamer backend (i.e. more supported media formats, well tested media backends) - more easily extensible protocol because of XML and easier to extend because of Python - asynchronous notifications other the network (you can subscribe to song changes, etc, XMMS2 also has this) - webradios dedicated mode - integrated web interface It has the following drawbacks compared to mpd : - uses more memory and perhaps more CPU time (because written in Python vs optimized C) but it keeps reasonable, you'll see if you give it a try. - no ReplayGain support (this is a planned feature). - younger project thus less stable, less tested although the codebase is not very large (we use everything we can reuse) and we've got quite a big test suite. - no Zeroconf support. - only 3 clients (cmdline, web, maemo platform) and GUIs still have rough edges. This is a summary of what I know. I think all those projects are complementary. deejayd does not have (yet?) unique features, but it is a unique combination of features. Also of interest, there is a page that explains why we started the project. http://mroy31.dyndns.org/~roy/projects/deejayd/wiki/Why/ Should all this fit in the package description? Thanks, Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#463973: ITP: deejayd -- A media player daemon
Package: wnpp Severity: wishlist Owner: Alexandre Rossi <[EMAIL PROTECTED]> * Package name: deejayd Version : 0.6.2 Upstream Author : Mickaël Royer <[EMAIL PROTECTED]> * URL : http://mroy31.dyndns.org/~roy/projects/deejayd/ * License : GPL Programming Lang: Python Description : A media player daemon Deejayd is a multi purpose media player that can be completely controlled through the network using XML messages. It suppports playlists, searching, many media tags. It can playback many music and video formats using either its xine (recommended) or its gstreamer backend. Preliminary packaging may be browsed in the upstream VCS viewer[0]. Built packages work well, are lintian and linda clean, and build in a clean pbuilder chroot. I plan to search for a sponsor once we sort some internal bug and some packaging issues (remove debian/* from upstream tarball[1] as DDs mostly seem to prefer that). Reporting any issue (on the packaging or on the sofware) is very welcome, especially because this is my first debian package. [0] http://mroy31.dyndns.org/~roy/projects/deejayd/browser [1] http://mroy31.dyndns.org/~roy/archives/deejayd/deejayd-0.6.2.tar.gz -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-vserver-amd64 Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Re: hot to build i386 on amd64 using pbuilder?
Hi, > > Logging into the chroot reveals /dev/null is 644, not 666 as I would expect. > > > > How can I fix the permissions of /dev/null under the chroot? > > > > Are my problems likely to be cause by the fact that my machine is > > running as a vserver? > > Actually /dev/null is not even a character device inside the chroot: > # ls -l /dev/null > -rw-r--r-- 1 root root 0 Jan 17 14:00 /dev/null As I use cowbuilder, my quick fix for this (and which works perfectly) was : $ chmod 666 /var/cache/pbuilder/etch-amd64.cow/dev/null I assume that modifying the base tgz for pbuilder would not achieve the same thing, as mknod would be run after extraction, would it? Anyway this was a better compromise for me than giving MKNOD capabilities inside the vserver guest. Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#434465: ITP: vbrfix -- tool to correct MP3 files with incorrect Variable BitRate information
Hi, Description : tool to correct MP3 files that have broken Variable BitRate information For the record, I have had very good results with mp3packer : http://omion.dyndns.org/mp3packer/mp3packer.html A VBR null frame is placed at the beginning of the file to tell the MP3 player information about the song length and indexing through the song. Is that what is called the VBR header or sometimes the Xing header? Cheers, Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
