Bug#1053256: ITP: bypass-paywalls-firefox-clean -- Firefox browser plugin to bypass various paywalls
Package: wnpp Severity: wishlist Owner: Andres Salomon X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: bypass-paywalls-firefox-clean Version : 3.3.5.0 Upstream Contact: https://gitlab.com/magnolia1234 * URL : https://gitlab.com/magnolia1234/bypass-paywalls-firefox-clean * License : MIT Programming Lang: Javascript Description : Firefox browser plugin to bypass various paywalls Add-on allows you to read articles from (supported) sites that implement a paywall. You can also add a domain as custom site and try to bypass the paywall. . Note: this plugin may leak information about your web browsing based on the techniques used to bypass paywalls. For example, for some sites it will load text from Google's webcache, thereby letting Google know that you read a certain article. The plugin only operates on sites that you opt-into. I use this package on both firefox and chromium, and would welcome this to be co-maintained by Debian Mozilla Extension Maintainers if they're interested. I've already got a working package, but I'm still trying to figure out whether we really need separate source packages for the firefox and chromium plugins.
Re: Control header sent with done email didn't do what I expected, should it have?
On Mon, 25 Sep 2023, Jonathan Kamens wrote: > Thank you! A canonical answer at last. The reason why it wasn't implemented for -done and -forwarded is because the psuedoheader parsing for -done is pretty different, and we aren't doing any parsing for -forwarded. There's no technical reason why it couldn't be done for both, but at the time I implemented it, I didn't fully understand how much utility people would find from it. [I underestimated the value of being able to mail multiple bugs at the same time and use "Control: tag -1 foo".] [Enabling it for nnn@ was really just a case of that happening for free when I enabled it for submit@.] -- Don Armstrong https://www.donarmstrong.com Any excuse will serve a tyrant. -- Aesop
Re: allow missing description fields and empty long descriptions for Rust/etc packages?
On Fri, 2023-09-22 at 14:40 +0800, Paul Wise wrote: > Personally I think this boilerplate has little to no value, cutting the > long sentence down to something like just "Rust crate foo" would help This change has now been merged and will reach Debian eventually: https://salsa.debian.org/rust-team/debcargo/-/merge_requests/52 https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/545 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part