Bug#904575: ITP: vanguards -- Additional protections for Tor Onion Services
Package: wnpp Severity: wishlist Owner: "Iain R. Learmonth" * Package name: vanguards Version : 0.1.1 Upstream Author : Mike Perry * URL : https://github.com/mikeperry-tor/vanguards * License : MIT Programming Lang: Python Description : Additional protections for Tor Onion Services vanguards uses the Stem Tor control port library to connect to a Tor control port. It has three defense subsystems: Vanguards, Rendguard, and Bandguards. All three subsystems apply to both service-side and client-side onion service activity, but NOT to any client traffic that exits the Tor network to the normal Internet. -- The package will be built to use PyPy in unstable and testing. Depending on the availability of a backport for pypy-stem (see #904454) a backport to stable may be built using CPython 3 instead of PyPy. The package will include a disabled by default systemd service file. This will be disabled by default as it's not great when two processes try to control tor at the same time and so starting a process to control tor should be an explicit action. This will be maintained within the pkg-privacy team.
Bug#904577: ITP: stylus -- stylus manager to customize web sites with themes and skins
Package: wnpp Severity: wishlist Owner: Dmitry Smirnov X-Debbugs-CC: debian-devel@lists.debian.org, pkg-mozext-maintain...@lists.alioth.debian.org Control: tags -1 help Control: affects -1 stylish Package name: Stylus Version: 1.0.0 License: GPL-3+ URL: https://add0n.com/stylus.html Vcs-Browser: https://salsa.debian.org/webext-team/stylus Description: stylus manager to customize web sites with themes and skins User styles are themes for web sites. User styles empower your browsing experience by letting you customize web sites. Take out irrelevant content, change colors, or completely redesign the entire site. You can even use user styles as themes on the interface of Firefox, Thunderbird, and SeaMonkey themselves. . Stylus lets you easily manage user styles. Add, delete, enable, disable, and organize with a few clicks of a mouse, no code to edit, no obscure configuration to find. Stylus's companion website, userstyles.org, hosts tens of thousands of user styles made by other Stylus users that you can try. . For you technical types out there, think of it this way: Stylus and userstyles.org are to CSS as Greasemonkey and userscripts.org are to JavaScript. Stylish changed hands and has been corrupted by new upstream, see #902937, #850452. Stylish is considered dead and will be removed from Debian. Stylus is a compatible Stylish successor, forked from older version of the latter. It has been preliminary packaged as WebExtension but needs more work, mostly regarding DFSG compliance. Due to time constrains I may not be able to finish the job but the hard part is already done. Any help is welcome and appreciated... signature.asc Description: This is a digitally signed message part.
Bug#904591: ITP: libproc-fastspawn-perl -- module to fork+exec, or spawn, a subprocess as quickly as possible
Package: wnpp Owner: Lucas Kanashiro Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name : libproc-fastspawn-perl Version : 1.2 Upstream Author : Marc A. Lehmann * URL : https://metacpan.org/release/Proc-FastSpawn * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to fork+exec, or spawn, a subprocess as quickly as possible The purpose of this small (in scope and footprint) module is simple: spawn a subprocess asynchronously as efficiently and/or fast as possible. Basically the same as calling fork+exec (on POSIX), but hopefully faster than those two syscalls. Apart from fork overhead, this module also allows you to fork+exec programs when otherwise you couldn't - for example, when you use POSIX threads in your perl process then it generally isn't safe to call fork from perl, but it is safe to use this module to execute external processes. The package will be maintained under the umbrella of the Debian Perl Group.
Bug#904593: ITP: libio-fdpass-perl -- module to pass a file descriptor over a socke
Package: wnpp Owner: Lucas Kanashiro Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name : libio-fdpass-perl Version : 1.2 Upstream Author : Marc A. Lehmann * URL : https://metacpan.org/release/IO-FDPass * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to pass a file descriptor over a socket This small low-level module only has one purpose: pass a file descriptor to another process, using a (streaming) unix domain socket (on POSIX systems) or any (streaming) socket (on WIN32 systems). The ability to pass file descriptors on windows is currently the unique selling point of this module. The package will be maintained under the umbrella of the Debian Perl Group.
Bug#904594: ITP: libanyevent-fork-perl -- module to create new processes
Package: wnpp Owner: Lucas Kanashiro Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name : libanyevent-fork-perl Version : 1.31 Upstream Author : FIXME * URL : https://metacpan.org/release/AnyEvent-Fork * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to create new processes AnyEvent::Fork allows you to create new processes, without actually forking them from your current process (avoiding the problems of forking), but preserving most of the advantages of fork. It can be used to create new worker processes or new independent subprocesses for short- and long-running jobs, process pools (e.g. for use in pre-forked servers) but also to spawn new external processes (such as CGI scripts from a web server), which can be faster (and more well behaved) than using fork+exec in big processes. Special care has been taken to make this module useful from other modules, while still supporting specialised environments such as App::Staticperl or PAR::Packer. The package will be maintained under the umbrella of the Debian Perl Group.
Re: Should the weboob package stay in Debian?
On Thu, Jul 19, 2018 at 04:15:12PM +0100, Jonathan Dowland wrote: As a pre-amble side-note, some issues of offending users with homophobic language have been addressed upstream, and I think we should aim to carry these patches in stable/testing/unstable. (I don't think we have processes for patching oldstable or o-o-stable, please correct me if I'm wrong. I also haven't yet verified that these patches are necessary in all of our suites.)[1] I think it would be worthwhile to file a BTS bug so it can be easily tracked which versions of the package we distribute still carry this bug, so I will do that. The binary names within are far more problematic. A full enumeration of the ones that IMHO must change will have to wait for a follow-up email. But it would certainly include "wetboobs", "boobsize", "boobtracker" and "flatboob". If the names are to change, I don't think there's any reason they should not change significantly; merely adding a hyphen would not be sufficient. I will attempt to suggest some names in a follow-up. I had a further thought about the names. Asides from the issue at hand, there is no consistency between the command names. Some are prefixed "boo", some are suffixed "oob", neither of which is particularly great at identifying the parent project, and many are neither. So a completely orthogonal rationale for renaming the tools would be to unify them under a common, identifying prefix or suffix, or some other common pattern. This would also permit the future development of a subcommand pattern like git uses, "woob weather", "woob parcel", etc., should that be desireable. I think the next best step for this particular suggestion would be for me to take it upstream, and, assuming it meets with some kind of positive response, I would also be happy to work towards implementing it. So I will raise this in upstream's Gitlab. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Should the weboob package stay in Debian?
On Tue, 24 Jul 2018 09:40:25 -0700, Steve Langasek wrote: >On Tue, Jul 24, 2018 at 01:15:52PM +0200, Stephan Seitz wrote: >> On Di, Jul 24, 2018 at 11:49:55 +0100, Matthew Vernon wrote: >> > accept that they are authoritative in this regard. Therefore, you should >> > rename the offensive parts of this package. > >> He certainly should NOT rename any parts of the package without upstream >> consent. If upstream doesn’t approve (and it seems that these names are part >> of upstream’s working culture), then the other choices are removing to >> package or keeping it as it is. > >Your "should not" does not follow from any of Debian's core principles >(DFSG, Debian Social Contract, Diversity Statement). Staying compatible with the rest of the world is not covered by our core principles? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Bug#904613: ITP: golang-layeh-gopher-luar -- simplifies data passing to and from gopher-lua
Package: wnpp Severity: wishlist Owner: Jongmin Kim X-Debbugs-CC: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org * Package name: golang-layeh-gopher-luar Version : 1.0.4-1 Upstream Author : Tim Cooper * URL : https://github.com/layeh/gopher-luar * License : MPL-2.0 Programming Lang: Go Description : simplifies data passing to and from gopher-lua Simplifies data passing to and from gopher-lua. This package is a dependency for micro (#13).
Re: Should the weboob package stay in Debian?
On Wed, Jul 25, 2018 at 07:05:33PM +0200, Marc Haber wrote: > On Tue, 24 Jul 2018 09:40:25 -0700, Steve Langasek > wrote: > >On Tue, Jul 24, 2018 at 01:15:52PM +0200, Stephan Seitz wrote: > >> On Di, Jul 24, 2018 at 11:49:55 +0100, Matthew Vernon wrote: > >> > accept that they are authoritative in this regard. Therefore, you should > >> > rename the offensive parts of this package. > >> He certainly should NOT rename any parts of the package without upstream > >> consent. If upstream doesn’t approve (and it seems that these names are > >> part > >> of upstream’s working culture), then the other choices are removing to > >> package or keeping it as it is. > >Your "should not" does not follow from any of Debian's core principles > >(DFSG, Debian Social Contract, Diversity Statement). > Staying compatible with the rest of the world is not covered by our > core principles? It is covered. We explicitly list a number of things that we consider to be of higher priority than arbitrary compatibility with third parties (free software; our users' needs; creating a developer community that is welcoming to all people, instead of one that mirrors a wider culture which discriminates against people based on their identity). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Should the weboob package stay in Debian?
On Wed, Jul 25, 2018 at 12:18:53PM -0700, Steve Langasek wrote: > On Wed, Jul 25, 2018 at 07:05:33PM +0200, Marc Haber wrote: > > Staying compatible with the rest of the world is not covered by our > > core principles? > > It is covered. We explicitly list a number of things that we consider to be > of higher priority than arbitrary compatibility with third parties (free > software; our users' needs; creating a developer community that is welcoming > to all people, instead of one that mirrors a wider culture which > discriminates against people based on their identity). If you put technical needs below religious ones (and this particular religion is especially vile), something is really wrong. Debian is supposed to be inclusive for all users. Working software is much more important than hurt feelings -- especially if you care about feelings of only a single group. The diversity statement we approved explicitely welcomes participation by everyone, and (by my reading) implicitly bans censorship. You're trying to promote censorship, and that I protest against. Meow! -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Re: Should the weboob package stay in Debian?
Marc Haber writes: > On Tue, 24 Jul 2018 09:40:25 -0700, Steve Langasek > wrote: >>On Tue, Jul 24, 2018 at 01:15:52PM +0200, Stephan Seitz wrote: >>> He certainly should NOT rename any parts of the package without upstream >>> consent. >> >>Your "should not" does not follow from any of Debian's core principles >>(DFSG, Debian Social Contract, Diversity Statement). > > Staying compatible with the rest of the world is not covered by our > core principles? Obviously we renamed packages (which made us incompatible with the rest of the world) already if needed. Rememver iceweasel or icedove? Possible renames is already built in our interpretation of DFSG §3, that we allow renaming when original names are forbidden by license). So: compatibility is not an absolute core principle. Best regards Ole
Re: Should the weboob package stay in Debian?
On Wed, Jul 25, 2018 at 09:25:11PM +0200, Ole Streicher wrote: > Marc Haber writes: > > Staying compatible with the rest of the world is not covered by our > > core principles? > > Obviously we renamed packages (which made us incompatible with the rest > of the world) already if needed. Rememver iceweasel or icedove? > > Possible renames is already built in our interpretation of DFSG §3, > that we allow renaming when original names are forbidden by license). Package names exist in Debian only. Every distribution has its own namespace, and relations matter only within that distribution. On the other hand, executable names do matter for compatibility with scripts. Especially for a CLI tool like weboob. Meow! -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Re: Should the weboob package stay in Debian?
On Wed, 25 Jul 2018 21:56:10 +0200, Adam Borowski wrote: > On Wed, Jul 25, 2018 at 12:18:53PM -0700, Steve Langasek wrote: > > It is covered. We explicitly list a number of things that we consider to be > > of higher priority than arbitrary compatibility with third parties (free > > software; our users' needs; creating a developer community that is welcoming > > to all people, instead of one that mirrors a wider culture which > > discriminates against people based on their identity). [..] > The diversity statement we approved explicitely welcomes participation by > everyone, No. The sentence goes on: "We welcome contributions from everyone as long as they interact constructively with our community". Promoting objectification of half of the world's population doesn't count as constructive social interaction in my understanding. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Re: Should the weboob package stay in Debian?
On Thu, Jul 26, 2018 at 12:55:50AM +0200, gregor herrmann wrote: > On Wed, 25 Jul 2018 21:56:10 +0200, Adam Borowski wrote: > > On Wed, Jul 25, 2018 at 12:18:53PM -0700, Steve Langasek wrote: > > > It is covered. We explicitly list a number of things that we consider to > > > be > > > of higher priority than arbitrary compatibility with third parties (free > > > software; our users' needs; creating a developer community that is > > > welcoming > > > to all people, instead of one that mirrors a wider culture which > > > discriminates against people based on their identity). > [..] > > The diversity statement we approved explicitely welcomes participation by > > everyone, > > No. The sentence goes on: > > "We welcome contributions from everyone as long as they interact > constructively with our community". > > Promoting objectification of half of the world's population doesn't > count as constructive social interaction in my understanding. That "objectification" is an invention of your particular religion[1]. If another package insults a totem law that declares all twins need to be killed at birth, would we remove calligra-gemini as it dares to include a reference to those in its name? Here we have an useful piece of software. Its authors believe that its somewhat puerile but harmless name serves well as a detector of those who are "offended first, think later". You're proposing to exclude them. What's wrong with looking at boobs? The vast majority of humankind (by measuring genital blood flow when viewing such an image, the percentage of women is actually higher than that of men) enjoys that. Many of them deny that, though, having been forced to believe in a "sin". I for one don't protest inclusion of the Bible in Debian, despite that text having been the cause of 100M deaths, nor Quran with its 75M. I wouldn't protest even the Communist Manifesto or Mein Kampf (stats hotly contested, but no doubt of the former being #1 and the latter #4). In comparison, the concept of boobs has a _positive_ effect. It does less harm than the concept of kittens, and no one but bird lovers protest those. So no, that _you_ want to not use a certain content doesn't mean anyone else should be denied that right. You want to make Debian less inclusive, poorer. Removing a perfectly working piece of software without a technical reason is certainly not "interacting constructively". Meow. [1]. And I insist on calling it a religion, as it has the hallmarks of one. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Re: Should the weboob package stay in Debian?
Quack, On 2018-07-25 22:35, Jonathan Dowland wrote: I think it would be worthwhile to file a BTS bug so it can be easily tracked which versions of the package we distribute still carry this bug, so I will do that. Agreed, we should ensure all fixes are in all versions and I'd be glad to have some help. Upstream agreed to fix the referenced problem without discussing, which is encouraging. So we should check the messages further and report them to have them fixed if any other insult slipped through. I think the next best step for this particular suggestion would be for me to take it upstream, and, assuming it meets with some kind of positive response, I would also be happy to work towards implementing it. So I will raise this in upstream's Gitlab. You're welcome to try convincing them. They were clear they did not want to rename but maybe they could agree on having a variant of the binaries along with the original ones. I also like the idea of a single binary with subcommands, would be easier than remembering all the commands. But as I said unless upstream does agree on something, we're not going to maintain an alternate version. \_o< -- Marc Dequènes
Re: Should the weboob package stay in Debian?
Adam Borowski - 25.07.18, 21:56: > On Wed, Jul 25, 2018 at 12:18:53PM -0700, Steve Langasek wrote: > > On Wed, Jul 25, 2018 at 07:05:33PM +0200, Marc Haber wrote: > > > Staying compatible with the rest of the world is not covered by > > > our > > > core principles? > > > > It is covered. We explicitly list a number of things that we > > consider to be of higher priority than arbitrary compatibility with > > third parties (free software; our users' needs; creating a > > developer community that is welcoming to all people, instead of one > > that mirrors a wider culture which discriminates against people > > based on their identity). > > If you put technical needs below religious ones (and this particular > religion is especially vile), something is really wrong. Debian is > supposed to be inclusive for all users. Working software is much > more important than hurt feelings -- especially if you care about > feelings of only a single group. How would Debian be inclusive for all users and developers in case it includes software which discriminates "only a single group"? I think this is not "only" about hurting feelings. -- Martin
