Bug#894426: ITP: mlbstreamer -- Interface to the MLB.TV media offering
Package: wnpp Severity: wishlist Owner: Sebastien Delafond * Package name: mlbstreamer Version : 0.0.2 Upstream Author : Tony Cebzanov * URL : https://github.com/tonycpsu/mlbstreamer * License : GPL-2 Programming Lang: Python Description : Interface to the MLB.TV media offering A collection of tools to stream and record baseball games from MLB.TV. While the main streaming content is mostly for paid MLB.TV subscribers only, there are a significant number of features and views available to non-subscribers as well including one free game each day.
Re: Bug#894369: ITP: egpg -- Wrapper tool to easily manage and use keys with GPG
On 29/03/2018 15:54, Yago González wrote: > Package: wnpp > Severity: wishlist > Owner: Yago González > > * Package name: egpg > Version : 2.1 > Upstream Author : Dashamir Hoxha > * URL : https://github.com/dashohoxha/egpg > * License : GPL-3 > Programming Lang: Shell > Description : Wrapper tool to easily manage and use keys with GPG > > Easy GnuPG (egpg) is a wrapper script that tries to simplify the process of > using GnuPG. In order to make things easier, it is opinionated about the > "right" way to use GnuPG. > > It helps manage (e.g. generate, revoke...) the keys as well as use them > to verify, sign and encrypt messages. > The last time Easy GnuPG has been discussed on the GnuPG mailing list: thread starting around this message https://lists.gnupg.org/pipermail/gnupg-users/2016-April/055835.html and later https://lists.gnupg.org/pipermail/gnupg-users/2016-May/056007.html Easy GnuPG was not deemed ready for end users, and technical issues with the code were identified. I think including it in Debian is akin to recommend it and somehow a statement on its technical cryptographic validity. It seemed that people on the GnuPG mailing list were not too enthusiastic about reviewing it. Has something changed since then? Is there an (informal) evaluation of the code or of the project in general from a third party? Cheers, Daniele
Bug#894430: ITP: python-orderedattrdict -- Python OrderedDict with attribute-style access
Package: wnpp Severity: wishlist Owner: Sebastien Delafond * Package name: python-orderedattrdict Version : 1.5 Upstream Author : S Anand * URL : https://github.com/sanand0/orderedattrdict * License : MIT Programming Lang: Python Description : Python OrderedDict with attribute-style access An ordered dictionary with attribute-style access. . AttrDict behaves exactly like collections.OrderedDict, but also allows keys to be accessed as attributes. . It also allows for loading JSON and YAML while preserving the order of keys . This will be a dependency for mlbstreamer.
Bug#894431: ITP: python-memoize -- Simple memoizing module
Package: wnpp Severity: wishlist Owner: Sebastien Delafond * Package name: python-memoize Version : 1.0.2 Upstream Author : Mike Boers * URL : http://github.com/mikeboers/PyMemoize * License : BSD-3 Programming Lang: Python Description : Simple Python cache and memoizing module This is a (relatively) simple Python memoizing module (ie. a function cache), in which any dict-like can be used as the actual storage object. This will be a dependency for mlbstreamer.
Bug#894434: ITP: libauthen-u2f-tester-perl -- FIDO/U2F Authentication Test Client
Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: libauthen-u2f-tester-perl Version : 0.02 Upstream Author : Michael Schout * URL : https://metacpan.org/release/Authen-U2F-Tester * License : Artistic or GPL-1+ Programming Lang: Perl Description : FIDO/U2F Authentication Test Client Authen::U2F::Tester provides the tools needed to test support for U2F in an application. He can thus emulate a U2F device. This package is used by next version of libcrypt-u2f-perl during build process.
Bug#894435: ITP: python-wsproto -- WebSockets state-machine based protocol implementation
Package: wnpp Severity: wishlist Owner: Sebastien Delafond * Package name: python-wsproto Version : 0.11.0 Upstream Author : Benno Rice * URL : https://github.com/python-hyper/wsproto * License : MIT Programming Lang: Python Description : WebSockets state-machine based protocol implementation Pure-Python implementation of a WebSocket protocol stack. It's written from the ground up to be embeddable in whatever program you choose to use, ensuring that you can communicate via WebSockets, as defined in RFC6455, regardless of your programming paradigm. This will be a dependency of mitmproxy v3.
Re: Debian part of a version number when epoch is bumped
On Wed, Mar 28, 2018 at 11:39:58PM +0200, Christian T. Steigies wrote: >... > You still have not convinced me that I did anything wrong with the version > number and you keep ignoring my request for propper official documentation > how to use and not use an epoch. Maybe you all can read between the lines > of the policy or just magically know how this was intended. But I can not > read your mind and I assume the majority of regular DDs can neither. If it > is incorrect to start with the debian revision from scratch after an epoch, > please document it where a regular person can easily find it, especially if > I am not the first person to fall into this trap. I do not consider this > bug report a suitable place for that (one of my packages has been used > before in an Ubuntu packaging manual to show how to report a bug and nobody > told me about this nor the "bug" until after years somebody finally reported > the bug, is this the plan for moon-buggy and epochs?). >... There are two problems here. The first is the use of an epoch in a situation where it shouldn't be used. The actual "trap" is when a maintainer used an epoch in such a situation. Once introduced in a package an epoch cannot ever be undone, so all that can be done on that is to make it clearer that it is wrong to use an epoch in such cases. The second problem is about filename overlap after incorrect epoch usage. It is important to understand that this is only relevant for cases where an epoch was used where it shouldn't have been: When an epoch is used as intended for a change in the upstream version numbering scheme (e.g. from 20171224 to 1.0), there is no overlap in version numbers. Launchpad gave an error on that, and this is better than the silent breakage in Debian of the assumption that no filename is ever used twice in Debian. I would consider it a bug in dak that it doesn't know about all versions and filenames that ever existed in Debian. It would be wrong to document in Debian policy that skipping Debian revisions is required in such cases, since the only case where this second problem can happen is when a maintainer used an epoch in a situation where it shouldn't be used (first problem).[1] For the future it should be documented better that using an epoch is wrong in such cases, but for past incorrect epoch usage all that can be done is to limit the damage. Things that cannot be undone for moon-buggy: - the epoch - two files moon-buggy_1.0.51-1.dsc exist in Debian, with different contents [2] What can be done for moon-buggy is to use a Debian revision that doesn't result in filenames that are duplicates with pre-epoch packages. > Christian cu Adrian [1] in theory upstream could also create such a situation with frequent changes in the versioning scheme, but that's not a problem in practice [2] not in Ubuntu, where this problem was caught -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#894446: ITP: libplack-handler-fcgi-ev-perl -- PSGI handler for FCGI::EV
Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: libplack-handler-fcgi-ev-perl Version : 0.01 Upstream Author : Tatsuhiko Miyagawa * URL : https://metacpan.org/release/Plack-Handler-FCGI-EV * License : Artistic or GPL-1+ Programming Lang: Perl Description : asynchronous PSGI handler using FCGI::EV Plack::Handler::FCGI::EV is an asynchronous PSGI handler using FCGI::EV as its backend. It can be used to replace Plack::Handler::FCGI.
Bug#894447: ITP: libplack-handler-fcgi-engine-perl -- Plack::Handler backend using FCGI::Engine
Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: libplack-handler-fcgi-engine-perl Version : 0.22 Upstream Author : Stevan Little * URL : https://metacpan.org/release/FCGI-Engine * License : Artistic or GPL-1+ Programming Lang: Perl Description : Plack::Handler backend using FCGI::Engine Plack::Handler::FCGI::Engine is a subclass of Plack::Handler::FCGI which will use the Plack::Handler::FCGI::Engine::ProcManager process manager by default, instead of FCGI::ProcManager.
Bug#894448: ITP: libfcgi-engine-perl -- flexible engine for running FCGI-based applications
Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: libfcgi-engine-perl Version : 0.22 Upstream Author : Stevan Little * URL : https://metacpan.org/release/FCGI-Engine * License : Artistic or GPL-1+ Programming Lang: Perl Description : flexible engine for running FCGI-based applications FCGI::Engine helps manage FCGI based web applications by providing a wrapper which handles most of the low-level FCGI details for you. It can run FCGI programs as simple scripts or as full standalone socket based servers who are managed by FCGI::Engine::ProcManager.
Bug#894449: ITP: libfcgi-async-perl -- FCGI engine using IO::Async
Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: libfcgi-async-perl Version : 0.22 Upstream Author : Paul Evans * URL : https://metacpan.org/release/FCGI-Async * License : Artistic or GPL-1+ Programming Lang: Perl Description : FCGI engine using IO::Async FCGI::Async is a subclass of Net::Async::FastCGI. It provides a slightly different API where it can take an argument containing the IO::Async::Loop object, rather than be added as Notifier object within one. It is provided mostly as a backward-compatibility wrapper for older code using this interface.
Re: Upcoming shift to Ayatana (App)Indicator(s)
Hi Simon, On Fr 30 Mär 2018 01:29:01 CEST, Simon McVittie wrote: On Thu, 29 Mar 2018 at 21:19:35 +, Mike Gabriel wrote: On Do 29 Mär 2018 15:54:26 CEST, Simon McVittie wrote: Which concrete libraries and packages does this refer to? As a Debian/GNOME contributor who has not been involved in Ubuntu or Ayatana, I've been confused in the past about what the difference is between libindicate, libindicator, libappindicator and possibly others. The maintained src:packages in Debian currently are: Rephrasing to check whether I understand, is this a correct summary of libraries to which an indicator client might be linked, from a Debian perspective? Rephrasing is good. Thanks. src:libayatana-indicator (libayatana-indicator(3-)?7): maintained fork of libindicator, recommended for indicator renderers (the indicator equivalent of the freedesktop.org/X11 notification area) and maybe StatusNotifierItem client apps (apps with the indicator equivalent of a GtkStatusIcon) Yes. Correct. Supplemented by an extra-fancy-widgets library called "ayatana-ido" (src:pkg) forked from Ubuntu's "ido" (indicator display objects). src:libayatana-appindicator (libayatana-appindicator(3-)?1): maintained fork of libappindicator, recommended for SNI client apps GTK-3 SNI applications, yes. In Qt5, there must be something similar. Natively in Qt5, I guess. I should know more about this. Maybe someone with Qt5 insights can provide additional info. src:libdbusmenu: dependency of lib(ayatana-)?appindicator and libindicate Yes, it provides an API for sending menu structures over a DBus interface. Side note: Please forget libindicate, it is about to be dead. It was used to send new-message-notifications between applications and the indicator-messages system indicator. Handles otherwise nowadays. src:libindicator (libindicator(3-)?7): deprecated library for both indicator renderers and SNI client apps; replace with libayatana-indicator (requires little or no porting?); orphaned Little porting, for renderers only. SNI applications don't directly depend on lib(ayatana)-indicator. src:libappindicator (libappindicator(3-)?1): deprecated library for SNI client apps; replace with libayatana-appindicator (requires little or no porting?); orphaned Little porting. Here is an example for transmission-gtk: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894410 It basically can be reduced to a 2-3 liner patch. Porting an SNI application from libappindicator to libayatana-appindicator implicitly ports it from libindicator to libayatana-indicator. src:libindicate (libindicate5, libindicate-gtk*): deprecated^2 library for SNI client apps; replace with libayatana-appindicator (requires non-trivial porting); orphaned, should be removed Nope. The libindicate library can be dropped completely. Implementations can simply be removed from applications, the libindicate code path was used to notify (ayatana-)indicator-messages about new events having occurred in communication applications (new email, new chat post, etc.). I will look deeper into this after Easter. ... and many of those have both GTK+ 2 and GTK+ 3 flavours, and sometimes a separate GUI-agnostic shared library for D-Bus protocols. Yes. I hope you can see why I was confused by all the lib(ayatana-)?(app)?indicat(e|or)((-gtk)?3)? libraries involved in this! Absolutely!!! If libayatana-appindicator and libayatana-indicator require no source-level porting from their non-Ayatana counterparts (same symbols, different SONAME), perhaps we could have transitional packages containing appropriate symlinks, rather than carrying around the orphaned libraries from which they were forked? Some little source code porting is needed. My goal was to allow parallel installation of lib(app)indicator and libayatana-(app)indicator. Here are some examples: Simple patch, exchange libappindicator by libayatana-appindicator: transmission-gtk: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=894410;filename=transmission_2.92-3_2.92-3%2Bayatanaindicators.debdiff;msg=5 More complex patch: support building against libappindicator and libayatana-appindicator alike (available shared libs decides what to build against): nm-applet: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=880169;filename=network-manager-applet_1.8.4-1%2Bayatanaindicator.debdiff;msg=10 mate-polkit: https://github.com/mate-desktop/mate-polkit/pull/41 Even more complex; choose what indicator implementation to use by configure option (a renderer, though): https://github.com/mate-desktop/mate-indicator-applet/commit/9d6ee461f95e059a42aea9392c37f5a752e9be3d (I'm more interested in SNI client apps here, and less interested in indicator renderers, because a random Debian developer is more likely to maintain a SNI client app than to maintain a renderer, so that seems like the side where it's particularly important to have a clear picture of what
Re: New lintian warning: vcs-deprecated-in-debian-infrastructure
On Mar 23 2018, Ben Finney wrote: >> You need online access to make use of the above information in any >> way. >> >> If you want to contact the maintainer you need internet access > > With the maintainer email address, I do not need internet access to > compose an email message. Without that information I can't. > >> if you want to visit the upstream homepage you need internet access > > With the upstream home page URL, I do not need internet access to > bookmark a URL. Without that URL I can't. Are that practical concerns or theoretical objections to the generality of the statement? You can still compose the email message, you'll just add the recipient address later once you have internet. Yeah, you can't bookmark the URL - but why would you? Just "bookmark" the name of the package, and once you have internet access use the (pre-existing) bookmark to the site that will give you a link to the upstream homepage. >> etc. > > So, there are plenty of uses for information that do not require > internet access *at the time of using* the information. Does "plenty" refer to the two examples you gave? Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Bug#894486: ITP: libnet-async-fastcgi-perl -- FastCGI engine using IO::Async
Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: libnet-async-fastcgi-perl Version : 0.25 Upstream Author : Paul Evans * URL : https://metacpan.org/release/Net-Async-FastCGI * License : Artistic or GPL-1+ Programming Lang: Perl Description : FastCGI engine using IO::Async Net::Async::FastCGI allows a program to respond asynchronously to FastCGI requests, as part of a program based on IO::Async. An object in this class represents a single FastCGI responder that the webserver is configured to communicate with. It can handle multiple outstanding requests at a time, responding to each as data is provided by the program. Individual outstanding requests that have been started but not yet finished, are represented by instances of Net::Async::FastCGI::Request.
Bug#894487: ITP: libnet-fastcgi-perl -- Perl toolkit to write FastCGI applications
Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: libnet-fastcgi-perl Version : 0.14 Upstream Author : Christian Hansen * URL : https://metacpan.org/release/Net-FastCGI * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl toolkit to write FastCGI applications Net::FastCGI aims to provide a complete API for working with the FastCGI protocol. The primary goal is to provide a function oriented and object oriented API which are not tied to a specific I/O model or framework. Secondary goal is to provide higher level tools/API which can be used for debugging and interoperability testing.
