Bug#945270: ITP: foliate -- simple and modern ebook viewer
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: foliate Version : 1.5.3 Upstream Author : John Factotum (https://github.com/johnfactotum) * URL : https://github.com/johnfactotum * License : GPL-3 Programming Lang: JavaScript, Python3 Description : simple and modern ebook viewer Foliate is a simple ebook reader with the following features: - View .epub, .mobi, .azw, and .azw3 files in two-page view or scrolled view - Customize font, line-spacing, margins, and brightness - Light, sepia, dark, and invert mode, or add your own custom themes - Reading progress slider with chapter marks - Bookmarks and annotations - Find in book - Quick dictionary lookup with Wiktionary, Wikipedia, and dictd - Touchpad gestures—use two-finger swipe to turn the page - Basic text-to-speech support with eSpeak NG and Festival For a screenshot and review, see: https://robbinespu.gitlab.io/blog/2019/10/18/foliate-a-simple-and-modern-ebook-viewer-for-linux/ I plan to maintain this package under the gnome-team group on salsa.debian.net.
Re: Namespaces for Lintian Tags
Hi, On Wed, 20 Nov 2019, Felix Lechner wrote: > There are many motivations: Among those motivations, which one is the one that triggered this process and which one are there as "additional benefits" that you could identify to justify the change? > 1. Shortens tag names. I don't see that as a benefit, we copy/paste the tags into overrides or full lines into lintian-info. We rarely need to type them. > 2. Points to the code that issued the tag. "grep -r" on the codebase has been working well for me. This mapping is only really needed when you want to dig into the code anyway. > 3. Frees up name space (good tags are rare). Can you show examples of how this would help you concretely? I have a hard time seeing how difficult it can be to invent a new name for a new tag. > 4. Multiple checks can use the same tag in different contexts (i.e. > 'spelling'). spelling-error-in-binary spelling-error-in-description spelling-error-in-changelog etc is perfectly fine. > 5. Preempts name conflicts in case some check-writing is delegated to > expert teams. This is not a real problem, that's the kind of pseudo-benefit that you try to imagine to justify the change that you want (I have done that many times ;-)). > 6. Quicker to split large checks when components reuse tag names. I don't follow you. For me splitting checks means they get renamed and thus your tag names are renamed too. > 7. Brings consistency between Lintian and custom profile users, such > pkg-perl-tools and pkg-js-tools, who already have private namespaces. A very minor benefit IMO. Now can you do the same analysis with the disadvantages? Since the check is embedded in the tag name: * It's harder to move a tag from one check to another. * It's harder to rename a check. What else can you come up with? > The change is technically easy. (Lintian even has a way to track > renamed tags for overrides.) On an optical level, however, the change I was about to ask for overrides, but this would be a massive usage of this rename feature and it will confuse many persons. People will start to use the new name in overrides to avoid this confusion and it won't work with old lintians (not a big deal but still). > will affect a lot of people. It could even cause headaches for some > users, for example in derivatives. We would like to solicit your > input. What kind of headaches are you referring to? Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Consensus call: proposed build profile: noinsttest
I'm writing as an individual. I believe I read most if not all of the messages in the discussion. Your summary of the discussion is consistent with my understanding of the discussion.
Bug#945329: ITP: emacs-websocket -- Emacs WebSocket client and server
Package: wnpp Severity: wishlist Owner: Nicholas D Steeves Control: block 909336 by -1 Package name: emacs-websocket Version : 1.10+17.g491a60b-1 (declares 1.12, but untagged) Upstream Author : Andrew Hyatt URL : https://github.com/ahyatt/emacs-websocket License : GPL-3+ Programming Lang: elisp Description : Emacs WebSocket client and server Emacs Websocket is an elisp library that allows websocket clients to talk to websocket servers, and websocket servers to accept connections from websocket clients. This library is designed to be used by other library writers, to write apps that use websockets, and is not useful by itself. . Emacs IPython Notebook, Emacs Realtime Markdown Viewer, Kite, Markdown-preview-mode, and Atomic Chrome for Emacs use this library. I have started packaging this software because it is a prerequisite for Atomic Chrome for Emacs (RFP Bug #909336). I will soon use it. I am not aware of a package with similar functionality. If my experience with Atomic Chrome for Emacs is good then I plan to maintain both packages as part of the Debian Emacsen Team. I will need a sponsor for the initial upload. Regards, Nicholas
