Bug#947815: ITP: rust-spotify-tui -- Spotify for the terminal written in Rust
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: rust-spotify-tui Version : 0.11.0 Upstream Author : Alexander Keliris * URL : https://github.com/Rigellute/spotify-tui * License : MIT or Apache-2.0 Programming Lang: Rust Description : Spotify for the terminal written in Rust spotify-tui needs to connect to Spotify’s API in order to find music by name, play tracks etc. Instructions on how to set this up will be shown when you first run the app. This app uses the Web API from Spotify, which doesn't handle streaming itself. So you'll need either an official Spotify client open or a lighter weight alternative such as spotifyd. If you want to play tracks, Spotify requires that you have a Premium account.
Bug#906008: ITP: lizzie -- GUI for analyzing games in real time using Leela Zero
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: lizzie Version : 0.5 Upstream Author : featurecat * URL : https://github.com/featurecat/lizzie * License : GPL-3 Programming Lang: Java Description : GUI for analyzing games in real time using Leela Zero Features include: - show win rates and confidence levels for selected moves on the board - show best move sequence continuation, for these selected moves - displays a graph of winrate against move number - show whole game history including forked moves - interactive play including undo/redo - load and save games in SGF format
Re: Concerns to software freedom when packaging deep-learning based appications.
BTW, please keep me on CC, I am not subscribed to debian-devel. Ximin Luo: > Lumin: >> [..] >> >> My core concern is: >> >> Even if upstream releases their pretrained model under GPL license, >> the freedom to modify, research, reproduce the neural networks, >> especially "very deep" neural networks is de facto controled by >> PROPRIETARIES. >> >> [..] > I think in general when one raise concerns, one should do some research to > make it relevant to the actual real situation. Your mail cited my leela-zero > package but contained no information specific to it. I'll supply the missing > gaps: > > The Debian package leela-zero contains no "pretrained model", or "weights > file" in its terminology. > > Leela Zero contains a program (autogtp) that generates and uploads raw game > data, based on some weights you give it. Data generated by many volunteers is > collected together and is available here [1] released into the public domain > [2]. There's more than 1TB of it. > Correction here, there is currently 600GB generated since November 2017 and still growing. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Re: Concerns to software freedom when packaging deep-learning based appications.
Lumin: > [..] > > My core concern is: > > Even if upstream releases their pretrained model under GPL license, > the freedom to modify, research, reproduce the neural networks, > especially "very deep" neural networks is de facto controled by > PROPRIETARIES. > > [..] I think in general when one raise concerns, one should do some research to make it relevant to the actual real situation. Your mail cited my leela-zero package but contained no information specific to it. I'll supply the missing gaps: The Debian package leela-zero contains no "pretrained model", or "weights file" in its terminology. Leela Zero contains a program (autogtp) that generates and uploads raw game data, based on some weights you give it. Data generated by many volunteers is collected together and is available here [1] released into the public domain [2]. There's more than 1TB of it. The code to "compile"/"train" this raw data into a weights file is in training/* and contains code for several different frameworks including tensorflow (Debian package in-progress at [3]). The nice thing is that you can give it raw data, it will generate weights *periodically* so you can pause the training and give the weights to someone else, who can perhaps supply more data and run a different training algorithm on a different deep-learning platform. AFAICT that's how the currently-recommended weights [4] have been trained, by the efforts of many different people for the past year or so. For context, it is 110MB uncompressed and it's just a very big matrix of floating-point numbers in ASCII format. So the source code for everything is in fact FOSS, it's just the fact that the compilation/"training" process can't be run by individuals or small non-profit orgs easily. For the purposes of DFSG packaging everything's fine, we don't distribute any weights as part of Debian, and upstream does not distribute that as part of the FOSS software either. This is not ideal but is the best we can do for now. There are various ways to improve this situation, and none of them involve philosphical discussions on a mailing list about what is or isn't code or execution or proprietary whatever. The concepts are really very clear, we know what the "source code" equivalent is (raw data plus training algorithms), all of it is openly-licensed in the case of Leela Zero, and the problem is simply that we can't perform the execution transparently as part of FOSS infrastructure. Two approaches are: (1) get the hardware or (2) invent a method to verify the results, probably using magical crypto to generate a proof-of-execution that can be easily verified and then have deep-learning platforms do this. I'm pretty some there's some early-stage research on (2) as part of the recent hype around blockchains but I don't know what the specific progress is, someone can dig through this more. Also in practise, for the case of Leela Zero, verification of the deep learning results is "half-done" by having different weights/models play games against each other. In other words people can about performance in practise, and don't worry about the fact that the deep learning platform may embed secret specific corner cases into the compiled model for whatever reason. I think it's useful to cover these corner cases, for transparency and security, but a lot of work has to go into it beyond simply complaining about it on mailing lists. X [1] https://leela.online-go.com/training/ [2] https://github.com/gcp/leela-zero/issues/167 [3] https://salsa.debian.org/science-team/tensorflow [4] http://zero.sjeng.org/best-network -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Bug#903634: ITP: leela-zero -- Go engine with no human-provided knowledge, modeled after the AlphaGo Zero paper.
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: leela-zero Version : 0.15 Upstream Author : Gian-Carlo Pascutto * URL : https://github.com/gcp/leela-zero * License : GPL-3 Programming Lang: C++ Description : Go engine with no human-provided knowledge, modeled after the AlphaGo Zero paper. Go engine with no human-provided knowledge, modeled after the AlphaGo Zero paper A Go program with no human provided knowledge. Using MCTS (but without Monte Carlo playouts) and a deep residual convolutional neural network stack. This is a fairly faithful reimplementation of the system described in the Alpha Go Zero paper "Mastering the Game of Go without Human Knowledge". For all intents and purposes, it is an open source AlphaGo Zero. https://deepmind.com/documents/119/agz_unformatted_nature.pdf No network weights are in this package. If you manage to obtain the AlphaGo Zero weights, this program will be about as strong, provided you also obtain a few Tensor Processing Units. Lacking those TPUs, the author recommends a top of the line GPU - it's not exactly the same, but the result would still be an engine that is far stronger than the top humans. Download the best known network weights file from: http://zero.sjeng.org/best-network
Bug#877017: ITP: python-rstr -- easily generate random strings of various types
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name : python-rstr Version : 2.2.6 Upstream Author : Brendan McCollam * URL : https://bitbucket.org/leapfrogdevelopment/rstr/ * License : BSD-3-Clause Programming Lang: Python Description : Easily generate random strings of various types rstr is a helper module for easily generating random strings of various types. It could be useful for fuzz testing, generating dummy data, or other applications. It has no dependencies outside the standard library, and is compatible with Python 3. The basic method of rstr is rstr(). At a minimum, it requires one argument, an alphabet of characters from which to create a string. Inspired by the Java library of the same name, the xeger() method allows users to create a random string from a regular expression. You can combine rstr with Python's built-in string formatting to produce strings that fit a variety of templates.
Re: [Pkg-mozext-maintainers] Packaging WebExtensions compatible with multiple browsers
Yao Wei: > Hi, > > There are some problems for us to package Debian packages for > WebExtensions that can support Firefox and Chromium using the same > codebase. I do come up with my idea, but I still need a conclusion to > prepare a package: > > 1. Should we use different prefix for the WebExtensions packages that > support different browsers? > > I think webext- prefix can be good for this kind of packages. > > 2. Should we split the package for different browsers? > > There's current efforts packaging ublock-origin for both chromium and > xul-ext. However shifting to WebExtensions implies that the codebase > will be the same. To save disk space and lower the security risk not to > split the main package could be good. Some of the browser-dependent > files can be splitted to their dedicated packages. > > Inputs are welcome! > Hi Yao Wei, thanks for taking this forward! I have not been following the discussions very closely but this all seems sensible to me. Best, Ximin -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Bug#861130: ITP: typescript-types -- Supposedly "high quality" TypeScript type definitions
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: typescript-types Version : 20170424 Upstream Author : Boris Yankov * URL : http://definitelytyped.org/ * License : MIT Programming Lang: TypeScript Description : Supposedly "high quality" TypeScript type definitions TypeScript type definitions supplied by the DefinitelyTyped project, for JavaScript packages that don't supply their own type definitions. This description would be longer, but upstream does not give one on their website nor on their Github page. After some very painful experience using NPM, one can eventually deduce that these definitions are needed for certain typescript packages that build on top of javascript packages, where these latter packages don't themselves define any typescript types. This package contains a subset of the upstream type definitions because there are a ridiculous amount (a few hundred megabytes) and the vast majority of them are probably never going to be needed for Debian.
Bug#860116: RFH: cargo -- Rust package manager
Package: wnpp Severity: normal We request assistance with maintaining the cargo package, as well as Rust packaging in general. Firefox's next versions[1] will require rust, but the Debian pkg-rust team is severely short on time to maintain these packages. sylvestre@ and I are just about managing to keep rustc in Debian up-to-date in our spare time. lucab@ and gus@ know more about the rust ecosystem than either of us, but they have not been very active recently. lucab@ had been maintaining cargo. Right now, cargo needs to be updated to the next version, there are some open bugs about it: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=cargo I have not yet looked at this package myself but if there are any questions you can probably prod lucab@ to answer them. He has a different handle on IRC, you can join #debian-rust on OFTC to talk to us. After this, we will need to update rustc to 1.16.0. This is packaged in git, and it works (doko@ has already uploaded it to Ubuntu) however it uses some deprecated Makefiles which are to be removed in the next 1.17.0 release. Therefore, we should try to upload 1.16.0 using the new "rustbuild" buildsystem which also build-depends on cargo. (To try this out, remove --disable-rustbuild from d/rules.) After that, we will have to figure out how to cross-compile cargo and rust for other architectures. So far, we have been bootstrapping rustc on other arches by using upstream's binary blobs, but this is not the ideal approach, and will become even harder once we have the rustc<->cargo cyclic build dependency. Upstream themselves prefer the cross-compilation approach, and had previously given me some tips that I need to go dig out again from my IRC logs. At some point we should also start packaging actual rust packages. Josh Triplett had been planning to automate a large part of this, the work is still incomplete but we have a Rust Packaging policy already: https://wiki.debian.org/Teams/RustPackaging/Policy Package automation tools: https://anonscm.debian.org/cgit/pkg-rust/dh-cargo.git (low-level dh glue) https://crates.io/crates/debcargo (high-level automater) [1] https://buildd.debian.org/status/package.php?p=firefox&suite=experimental
Bug#783975: ITP: giac -- computer algebra system
Package: wnpp Followup-For: Bug #783975 Owner: Ximin Luo Control: retitle -1 RFP: giac -- computer algebra system
Bug#846643: ITP: sagenb -- The standalone Sage Notebook
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: sagenb Version : 0.13 Upstream Author : SageNB contributors * URL : https://github.com/sagemath/sagenb * License : GPL-3+ Programming Lang: Python, JS Description : The standalone Sage Notebook The Sage Notebook is a web-based graphical user interface for mathematical software. Sage is a different approach to mathematics software. It makes it easy for you to use most mathematics software together. Sage includes GAP, GP/PARI, Maxima, and Singular, and dozens of other open source math packages. It aims to be a viable open source alternative to Magma, Maple, Mathematica, and MATLAB. With the Sage Notebook anyone can create, collaborate on, and publish interactive worksheets. In a worksheet, one can write code using Sage, Python, and other software included in Sage. You can write programs that combine serious mathematics with anything else. Most of the notebook does not depend on having Sage installed. Only a few miscellaneous functions are imported from Sage.
Bug#845063: ITP: html2canvas -- Take screenshots of webpages directly in the browser
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: html2canvas Version : 0.5.0~beta4 Upstream Author : 2012-2016 Niklas von Hertzen * URL : https://github.com/niklasvh/html2canvas * License : Expat Programming Lang: JS Description : Take screenshots of webpages directly in the browser html2canvas allows you to take "screenshots" of webpages or parts of it, directly on the users browser. The screenshot is based on the DOM and as such may not be 100% accurate to the real representation as it does not make an actual screenshot, but builds the screenshot based on the information available on the page. It renders the current page as a canvas image, by reading the DOM and the different styles applied to the elements. It does not require any rendering from the server, as the whole image is created on the clients browser. However, as it is heavily dependent on the browser, this library is not suitable to be used in nodejs. It doesn't magically circumvent any browser content policy restrictions either, so rendering cross-origin content will require a proxy to get the content to the same origin. It is still in a very experimental state, so the author doesn't recommend using it in a production environment nor start building applications with it yet, as there will be still major changes made.
Bug#844784: ITP: d3-format -- Formatting numbers for human consumption
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: d3-format Version : 1.0.2 Upstream Author : 2010-2015 Mike Bostock * URL : https://github.com/d3/d3-format * License : BSD Programming Lang: JS Description : Formatting numbers for human consumption Sometimes JavaScript doesn’t display numbers the way you expect. For example, printing tenths with a naive simple loop might give you 0, 0.1, 0.2, 0.30004, 0.4, 0.5, 0.6001, 0.7001, 0.8, 0.9 - welcome to binary floating point! Yet rounding error is not the only reason to customize number formatting. A table of numbers should be formatted consistently for comparison; above, 0.0 would be better than 0. Large numbers should have grouped digits (e.g., 42,000) or be in scientific or metric notation (4.2e+4, 42k). Currencies should have fixed precision ($3.50). Reported numerical results should be rounded to significant digits (4021 becomes 4000). Number formats should appropriate to the reader’s locale (42.000,00 or 42,000.00). The list goes on. Formatting numbers for human consumption is the purpose of d3-format, which is modeled after Python 3’s format specification mini-language (PEP 3101).
Re: [buildd-tools-devel] Bug#843773: misleading timestamps in binnmus
(resending again to the correct addresses; I could never get used to debbugs CC behaviour.) Ximin Luo: > Ansgar Burchardt wrote: >> The date from the last sourceful upload should probably still be used >> for any date/time information included in generated files to ensure >> they are identical on all architectures (or at least to try to do so). >> >> If you change the date in the binNMU entry, SOURCE_DATE_EPOCH should >> probably be set to the date of the last sourceful upload (instead of >> just using the most recent changelog entry). >> > > Holger Levsen wrote: >> On Thu, Nov 10, 2016 at 08:59:48AM -0200, Johannes Schauer wrote: >>> One solution would be to increase SOURCE_DATE_EPOCH by 1 second for every >>> binNMU to a package. >>> >>> Any other ideas? >> >> set SOURCE_DATE_EPOCH to the creation time of that changelog.$arch >> entry? >> > > I'm tending towards the latter suggestion because it's simpler. There's no > need to stick to a +1 second scheme etc, and it might mislead people into > thinking they can do calculations with this - such as reversing the original > timestamp of the sourceful-upload. > > Our naming of "SOURCE_DATE_EPOCH" did not really take into account the fact > that a source package can be built with many different configurations to > create many different build products that are each reproducible themselves. > (Debian itself also doesn't do this too clearly, the "+bn" syntax "looks > like" it's just a suffix but actually signals an entirely different namespace > from source package versions.) > > If it helps one sleep better, one can interpret the "SOURCE" in > "SOURCE_DATE_EPOCH" to refer to "all implicit and explicit inputs of the > build result, including the source code of the package being built but also > the binary build dependencies". > > (If you want to be super-accurate, you can take the max() of all of the > changelogs of all of the transitive build-deps, but I think that's going a > bit too far.) > > X > -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Bug#841136: ITP: sagemath -- Sage: Open Source Mathematical Software
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: sagemath Version : 7.4 Upstream Author : SageMath developers * URL : https://www.sagemath.org/ * License : GPL-2+ Programming Lang: Python Description : Sage: Open Source Mathematical Software SageMath is a free open-source mathematics software system licensed under the GPL. It builds on top of many existing open-source packages: NumPy, SciPy, matplotlib, Sympy, Maxima, GAP, FLINT, R and many more. Access their combined power through a common, Python-based language or directly via interfaces or wrappers. Mission: Creating a viable free open source alternative to Magma, Maple, Mathematica and Matlab.
Bug#839099: ITP: ocamlbuild -- Build tool for building OCaml library and programs
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: ocamlbuild Version : 0.9.2 Upstream Author : Nicolas Pouillard, Berke Durak, projet Gallium, INRIA Rocquencourt * URL : https://github.com/ocaml/ocamlbuild * License : GPL-2 with OCamlbuild exception Programming Lang: OCaml Description : Build tool for building OCaml library and programs OCamlbuild is a generic build tool, that has built-in rules for building OCaml library and programs. It was distributed as part of the OCaml distribution for OCaml versions between 3.10.0 and 4.02.3. Starting from OCaml 4.03, it is now released separately. Its job is to determine the sequence of calls to the compiler — with the right set of command-line flags — needed to build your OCaml-centric software project. It was designed as a generic build system (it is in fact not OCaml-specific), but also to be expressive enough to cover the specifics of the OCaml language that make writing good Makefiles difficult, such as the dreaded units Foo and Bar make inconsistent assumptions about Baz error.
Bug#838488: ITP: python-unidiff -- Unified diff python parsing/metadata extraction library
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: python-unidiff Version : 0.5.2+git7 Upstream Author : Matias Bordese * URL : https://github.com/matiasb/python-unidiff/issues * License : MIT Programming Lang: Python Description : Unified diff python parsing/metadata extraction library Simple Python library to parse and interact with unified diff data Python's standard library has a difflib module which generates diffs, but cannot read or apply existing patch files. This module can do that.
Bug#818881: ITP: right-encoding -- Adds the Character Encoding menu to the context menu
Package: wnpp Followup-For: Bug #818881 Owner: Ximin Luo Control: tags -1 wontfix Control: close -1 Oh, turns out Thunderbird *does* have a View -> Character Encoding switcher for individual messages. It's just that this was disabled for the message I was looking at, because of https://bugzilla.mozilla.org/show_bug.cgi?id=1258875 I think the better way forward would be to fix that bug, rather than to package this, so I will close this bug.
Bug#818881: ITP: right-encoding -- Adds the Character Encoding menu to the context menu
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: right-encoding Version : 0.3.5 Upstream Author : JoungKyun <http://oops.org/> * URL : https://addons.mozilla.org/ko/firefox/addon/right-encoding-76838/ * License : BSD Programming Lang: JS Description : Adds the Character Encoding menu to the context menu Right Encoding is added menu that set the character set on the context menu (mouse right-click) on Firefox and Thunderbird. Equivalent functionality already exists in Firefox/Iceweasel, but amazingly Thunderbird/Icedove does not provide a way to temporarily override the encoding for a single message. That's where this extension is most useful.
Bug#817156: ITP: singular3 -- Computer Algebra System for Polynomial Computations (version 3)
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: singular3 Version : 3.1.7 Upstream Author : Singular Team * URL : https://www.singular.uni-kl.de/ * License : GPL Programming Lang: C++ Description : Computer Algebra System for Polynomial Computations (version 3) SINGULAR is a Computer Algebra System (CAS) for polynomial computations with emphasis on the special needs of commutative algebra, algebraic geometry, and singularity theory. The latest version, 4, is already in Debian. However, we need version 3 as a dependency package of Sagemath; the two versions have incompatible APIs and ABIs.
Bug#787311: RFP: python-flask-oldsessions -- legacy sessions for Flask
Package: wnpp Followup-For: Bug #787311 Owner: Ximin Luo Control: retitle -1 ITP: python-flask-oldsessions Hi, I'm going to package this, based on the stub from python-stdeb
Bug#813591: ITP: baka-mplayer -- A libmpv based media player
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: baka-mplayer Version : 2.0.4 Upstream Author : Daniel Clarke * URL : http://bakamplayer.u8sand.net/ * License : GPL-2 Programming Lang: C++ Description : A libmpv based media player Baka MPlayer is a free and open source, cross-platform, libmpv based multimedia player. Its simple design reflects the idea for an uncluttered and enjoyable environment for watching tv shows. Features: * Gesture seeking. * Smart playlist. * Dim Desktop. * Hardware accelerated playback (vdpau, vaapi, vda). * Youtube playback support (and others). * Multilingual support (we are looking for translators!). * And more...
Bug#811169: ITP: colorfultabs -- Color tabs differently and make them easy to distinguish
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: colorfultabs Version : 29.7 Upstream Author : Shivanand Sharma <http://www.binaryturf.com/> * URL : https://addons.mozilla.org/en-US/firefox/addon/colorfultabs/ * License : CC-BY-NC-ND-3.0-US Programming Lang: JS Description : Color tabs differently and make them easy to distinguish ColorfulTabs is a Firefox extension that colors every tab in a different color and makes them easy to distinguish. It also beautifying the overall appearance of Firefox. ColorfulTabs does one and/or more of the following: . * Colors each tab using pre selected colors in a definite order starting from the left. * Colors each tab using a unique and randomly generated color. * Colors each tab using a unique color depending on the site domain using a formula. * Allows user to chose colors. * Allows one to fade the background tabs for easy identification of the selected tab. * Allows quick identification of the tabs. * Allows quick identification of tab boundaries. * Increases usability and visibility for people with visual challenges. The author has given me an exception (via private email, which I will reproduce in debian/copyright) to create a derivative work for Debian. I understand that this is not DFSG and will be problematic for other distributions to work on top of - I will try to persuade him to re-license under a proper FOSS license; failing that I will upload to non-free instead.
Bug#806953: ITP: koji -- RPM-based build system
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: koji Version : 1.10.0 Upstream Author : Red Hat, Inc. * URL : https://fedoraproject.org/wiki/Koji * License : LGPL-2.1 Programming Lang: Python Description : RPM-based build system The Fedora Project uses Koji for their build system, as do several other projects. Koji's goal is to provide a flexible, secure, and reproducible way to build software. Key features: - New buildroot for each build - Robust XML-RPC APIs for easy integration with other tools - Web interface with SSL and Kerberos authentication - Thin, portable command line client - Users can create local buildroots - Buildroot contents are tracked in the database - Versioned data
Bug#799536: ITP: gnome-mpv -- simple GTK+ frontend for mpv
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: gnome-mpv Version : 0.5 Upstream Author : gnome-mpv <https://github.com/gnome-mpv> * URL : https://github.com/gnome-mpv/gnome-mpv * License : GPL-3+ Programming Lang: C Description : simple GTK+ frontend for mpv GNOME MPV is a simple GTK+ frontend for mpv. GNOME MPV interacts with mpv via the client API exported by libmpv, allowing access to mpv's powerful playback capabilities.
Bug#799475: ITP: libchardet -- universal charset detection library
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: libchardet Version : 1.0.4 Upstream Author : Joung-Kyun Kim <https://oops.org> * URL : https://ftp.oops.org/pub/oops/libchardet/ * License : MPL-1.1 or GPL-2+ or LGPL-2.1+ Programming Lang: C++ Description : universal charset detection library libchardet is based on Mozilla Universal Charset Detector library and detects the character set used to encode data. The original code was written by Netscape Communications Corporation for the Mozilla Browser. John Gardiner Myers packaged this code into the independent Encode-Detect perl module. To this, libchardet adds a C wrapping API and a library build environment with libtool, and removes the perl wrapping API.
Bug#743792: ITP: treesheets - Data organizer that can emulate spreadsheets, mind mappers, and small databases
Package: wnpp Followup-For: Bug #743792 Owner: Ximin Luo Control: retitle -1 ITP: treesheets - Data organizer that can emulate spreadsheets, mind mappers, and small databases Hi, I've begun packaging, and will be uploading preliminary test packages here: https://mentors.debian.net/package/treesheets X -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150623195143.20682.7640.reportbug@localhost.localdomain
Bug#764007: ITP: meek -- Pluggable transport to circumvent IP address blocking via public services
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: meek Version : 0.12 Upstream Author : David Fifield * URL : https://trac.torproject.org/projects/tor/wiki/doc/meek * License : CC0 1.0 Universal Programming Lang: Go Description : Pluggable transport to circumvent IP address blocking via public services Meek is a tool to circumvent censorship by relaying traffic through a third-party server that is hard to block, for example a CDN. It uses a trick called "domain fronting" to talk to a Tor relay-like service while appearing to talk to another domain. The traffic itself is HTTPS, aiming to look like a typical encrypted web session. This is similar in many respects to flashproxy-client/pt-websocket. I will be maintaining this as part of the Debian Go Packaging Team. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141002174821.19911.20997.reportbug@localhost.localdomain
Re: Bug#739626: How to name the websocket PT server in Debian; was ITP: tor-pt-websocket -- WebSocket pluggable transport
control: retitle 739626 ITP: pt-websocket -- WebSocket pluggable transport On 20/02/14 17:00, David Fifield wrote: > On Thu, Feb 20, 2014 at 03:58:02PM +0000, Ximin Luo wrote: >> - tor-pt-websocket or pt-websocket: These are unambigious but >> inconsistent with the other Tor pluggable transport in Debian, >> obfsproxy. And there is also "fteproxy" which will probably retain >> this naming when added to Debian in the future. > > I kind of like this option, with the idea that there will be more of > such in the future. > > websocket is a special case because the upstream package only has a > server (there is client code but just a toy that shouldn't be > installed). What will other packages that have a matched client and > server look like? People installing the client probably don't want to > install the server (and have their init.d messed with, etc.), and people > installing the server don't also need the client. > Lunar suggested pt-websocket since it is not intrinsically tied to Tor usage, so I will go with that. I think the longer name pt-websocket-server is unnecessary, since we are unlikely to ever release a pt-websocket-client, so I will stick pt-websocket. If anyone disagrees, please speak up soon, since I have all the packaging ready and just need to make some final tweaks before submitting it for sponsorship. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git signature.asc Description: OpenPGP digital signature
How to name the websocket PT server in Debian; was ITP: tor-pt-websocket -- WebSocket pluggable transport
+tor-dev and some relevant people, please keep CC Hey all, I'd like some advice on the naming of this package. I have some options in mind: - flashproxy-server: The main practical use of this package is with the flashproxy[1][2] system. However, as noted in the package description, it could be used in other situations outside of flashproxy. Importantly, the code and functionality does not know about rest of the flashproxy system; as far as it is concerned, it is a "plain" Tor pluggable transport, in the sense that it "only" implements a stream-transformation in the same way as e.g. obfsproxy does, without the complexity involving addresses that (the other parts of) flashproxy provides. - tor-pt-websocket or pt-websocket: These are unambigious but inconsistent with the other Tor pluggable transport in Debian, obfsproxy. And there is also "fteproxy"[3] which will probably retain this naming when added to Debian in the future. - wsproxy-server: short and unambigious, consistent with "obfsproxy" and "fteproxy", but upstream has not adopted this naming. (We do not have a general convention for naming Pluggable Transports, but several others have been called *proxy, e.g. sshproxy[4] and aforementioned[3].) X [1] http://crypto.stanford.edu/flashproxy [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721845 [3] http://fteproxy.org/ [4] https://github.com/Yawning/sshproxy On 20/02/14 15:42, Ximin Luo wrote: > Package: wnpp > Severity: wishlist > Owner: Ximin Luo > > * Package name: tor-pt-websocket > Version : 0~git20140130 > Upstream Author : David Fifield > * URL : > https://gitweb.torproject.org/pluggable-transports/websocket.git > * License : CC0 > Programming Lang: Go > Description : WebSocket pluggable transport - server > > Pluggable transports are tools that transform a stream of application traffic > into a different format on the network. This helps to bypass network-level > censorship. > > This package contains a server transport plugin that accepts connections > transformed to look like the websocket protocol. This is typically used to > enhance systems like Tor, to provide service even to censored users. > > See flashproxy-client for a corresponding client transport plugin, meant for > users to bypass censorship, that is compatible with the websocket protocol > that > this package expects. > > (The source package also contains a websocket-client transport plugin, but > this is just a demo that is less effective than flashproxy-client, and not > meant to be used in real situations.) > -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -- 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/5306260a.8000...@pwned.gg
Bug#739626: ITP: tor-pt-websocket -- WebSocket pluggable transport
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: tor-pt-websocket Version : 0~git20140130 Upstream Author : David Fifield * URL : https://gitweb.torproject.org/pluggable-transports/websocket.git * License : CC0 Programming Lang: Go Description : WebSocket pluggable transport - server Pluggable transports are tools that transform a stream of application traffic into a different format on the network. This helps to bypass network-level censorship. This package contains a server transport plugin that accepts connections transformed to look like the websocket protocol. This is typically used to enhance systems like Tor, to provide service even to censored users. See flashproxy-client for a corresponding client transport plugin, meant for users to bypass censorship, that is compatible with the websocket protocol that this package expects. (The source package also contains a websocket-client transport plugin, but this is just a demo that is less effective than flashproxy-client, and not meant to be used in real situations.) -- 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/20140220154205.23198.30847.reportbug@localhost.localdomain
Bug#739599: ITP: golang-goptlib -- library for Tor pluggable transports written in Go
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: golang-goptlib Version : 0~git20140130 Upstream Author : David Fifield * URL : https://gitweb.torproject.org/pluggable-transports/goptlib.git * License : CC0 Programming Lang: Go Description : library for Tor pluggable transports written in Go goptlib is a little Go library which understands the Tor pluggable transport managed-proxy protocol. It is useful for developers writing Tor pluggable transports in Go. -- 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/20140220111532.23845.60695.reportbug@localhost.localdomain
Bug#736844: ITP: mozilla-password-editor -- Create and edit entries in the password manager in Mozilla applications
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: mozilla-password-editor Version : 2.7.2 Upstream Author : Daniel Dawson * URL : https://addons.mozilla.org/en-US/firefox/addon/saved-password-editor/ * License : GPL-3 Programming Lang: JavaScript Description : Create and edit entries in the password manager in Mozilla applications This extension allows you to enter data into the Password Manager database instead of relying on Firefox, Thunderbird, SeaMonkey, etc., to do it, as well as making changes to existing entries. This add-on also adds commands to the Password Manager window, which it makes accessible through Tools > Saved Passwords as well as a toolbar button. -- 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/20140127144723.1716.99635.reportbug@localhost.localdomain
Re: Bug#733860: ITP: pond -- Forward secure, asynchronous messaging for the discerning.
(I am not on debian-devel, please don't forget to CC me.) On 03/01/14 17:45, Tollef Fog Heen wrote: > ]] Ximin Luo > >> Package: wnpp >> Severity: wishlist >> Owner: Ximin Luo >> >> * Package name: pond >> Version : 0:git~2014-01-01 > > You might want to use a version number such as 0~20140101+git+$sha1 or > similar. 0:git probably isn't even valid as a Debian version number, > since : is used for epochs. > Thanks, I will do that. The previous one was just a placeholder that I guessed, I will read through the version syntax spec properly before I commit to anything. >> So Pond is not email. Pond is forward secure, asynchronous messaging >> for the discerning. Pond messages are asynchronous, but are not a >> record; they expire automatically a week after they are received. Pond >> seeks to prevent leaking traffic information against everyone except a >> global passive attacker. > > Am I understanding it correctly that this is somewhat like sending an > encrypted message to a key's fingerprint in a DHT with an expiration > tacked on, or is this completely off the mark? > It's somewhat off the mark :p The encryption keys are ephemerally generated using a ratchet to provide forward secrecy. The network structure is client-to-federated-servers rather than completely decentralised like a DHT. The servers provide availability, but are otherwise trusted with very little private information. (There is still some metadata leakage I believe.) The design also tries to protect against timing/length analyses. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git signature.asc Description: OpenPGP digital signature
Bug#733860: ITP: pond -- Forward secure, asynchronous messaging for the discerning.
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: pond Version : 0:git~2014-01-01 Upstream Author : Adam Langley * URL : https://pond.imperialviolet.org/ * License : BSD Programming Lang: Go Description : Forward secure, asynchronous messaging for the discerning. For secure, synchronous communication we have OTR and, when run over Tor, this is pretty good. But while we have secure asynchronous messaging in the form of PGP email, it's not forward secure and it gratuitously leaks traffic information. While a desire for forward secure PGP is hardly new, it still hasn't materialised in a widely usable manner. Additionally, email is used predominately for insecure communications (mailing lists, etc) and is useful because it allows previously unconnected people to communicate as long as a (public) email address is known to one party. But the flip side to this is that volume and spam are driving people to use centralised email services. These provide such huge benefits to the majority of email communication, so it's unlikely that this trend is going to reverse. But, even with PGP, these services are trusted with hugely valuable traffic information if any party uses them. So Pond is not email. Pond is forward secure, asynchronous messaging for the discerning. Pond messages are asynchronous, but are not a record; they expire automatically a week after they are received. Pond seeks to prevent leaking traffic information against everyone except a global passive attacker. -- 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/20140101140014.10109.87951.reportbug@localhost.localdomain
Bug#727212: ITP: cpp-netlib -- C++ Network Library
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: cpp-netlib Version : 0.10.1 Upstream Author : cpp-netlib authors * URL : http://cpp-netlib.org/ * License : Boost Software License - Version 1.0 Programming Lang: C++ Description : C++ Network Library The C++ Network Library Project aims to build upon the latest C++ standard (currently C++11) to provide easy to use libraries for network programming. We use the latest compiler versions and features with an eye on pushing the boundaries on leveraging what's available in C++. Currently the library contains an HTTP client and server implementation, a stand-alone URI library, a network message framework, and some concurrency tools. -- 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/20131023132218.24849.76672.reportbug@localhost.localdomain
Bug#592133: RFP: curlpp -- C++ wrapper for libcurl
Package: wnpp Followup-For: Bug #592133 Owner: Ximin Luo Hey, any progress on this? If you don't have time to work on it, I do - in which case please tell me the preferred place to host the git repo - e.g. alioth, debian, etc. Thanks, Ximin -- 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/20130905163700.28877.81635.reportbug@localhost.localdomain
Bug#721845: ITP: flashproxy -- ephemeral browser-based pluggable transport for Tor
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: flashproxy Version : 1.2 Upstream Author : David Fifield * URL : http://crypto.stanford.edu/flashproxy/ * License : MIT Programming Lang: Python, JavaScript, Go, Shell Description : ephemeral browser-based pluggable transport for Tor Flash proxies are a new way of providing access to a censorship circumvention system such as Tor. A flash proxy is a miniature proxy that runs in a web browser. It checks for clients that need access, then conveys data between them and a Tor relay. Tor has bridge relays, but in some cases even these can be blocked despite the fact that their addresses are handed out only a few at a time. The purpose of this project is to create many, generally ephemeral bridge IP addresses, with the goal of outpacing a censor's ability to block them. Rather than increasing the number of bridges at static addresses, we aim to make existing bridges reachable by a larger and changing pool of addresses. -- 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/20130904144428.5225.22272.reportbug@localhost.localdomain
Bug#659826: ITP: mozilla-gnome-keyring -- Store mozilla passwords in GNOME Keyring.
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: mozilla-gnome-keyring Version : 0.6.1 Upstream Author : Ximin Luo * URL : https://github.com/infinity0/mozilla-gnome-keyring * License : MPL-1.1 or GPL-2+ or LGPL-2.1+ Programming Lang: C++ Description : Store mozilla passwords in GNOME Keyring. This extenion integrates gnome-keyring into xulrunner applications as the software security device. -- 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/20120213234545.5347.3093.reportbug@localhost.localdomain
Bug#636866: ITP: status-4-evar -- Status bar widgets and progress indicators for Firefox 4+
Package: wnpp Severity: wishlist Owner: Ximin Luo I intend to package this as part of the pkg-mozext group. * Package name: status-4-evar Version : 0.2011.07.20.21 Upstream Author : Sparky Bluefang https://addons.mozilla.org/en-US/firefox/user/861193/ * URL : https://addons.mozilla.org/en-US/firefox/addon/status-4-evar/ * License : MPL-1.1 Programming Lang: Javascript Description : Status bar widgets and progress indicators for Firefox 4+ That status bar was removed in Firefox 4.0. While some of the status bar items did find new homes, some did not, and you might not like where they ended up. There were also some nice innovations during the development of Firefox 4.0, such as progress/links/status in the location bar, which unfortunately didn't make it to the final release. Status-4-Evar aims to bring back (some of) the old status bar items, give you more control over the built-in Firefox features, and provide new alternatives. -- 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/20110806145630.17747.75928.reportbug@localhost.localdomain
Bug#636865: ITP: tree-style-tab -- Show tabs like a tree
Package: wnpp Severity: wishlist Owner: Ximin Luo I intend to package this as part of the pkg-mozext group. * Package name: tree-style-tab Version : 0.12.2011061701 Upstream Author : piro_or * URL : https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/ * License : MPL 1.1 or GPL 2.0 or LGPL 2.1 Programming Lang: Javascript Description : Show tabs like a tree This provides tree-style tab bar, like a folder tree of Windows Explorer. New tabs opened from links (or etc.) are automatically attached to the current tab. If you often use many many tabs, it will help your web browsing because you can understand relations of tabs. -- 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/20110806145135.17702.14498.reportbug@localhost.localdomain
Bug#636399: ITP: cookiesafe-lite -- Control which websites have permission to set cookies.
Package: wnpp Severity: wishlist Owner: Ximin Luo I intend to package this as part of the pkg-mozext group. * Package name: cookiesafe-lite Version : 1.4 Upstream Author : csdev https://addons.mozilla.org/en-US/firefox/user/7045/ * URL : https://addons.mozilla.org/en-US/firefox/addon/cs-lite/ * License : GPL-2 Programming Lang: Javascript Description : Control which websites have permission to set cookies. This extension will allow you to easily control cookie permissions. It can be accessed from the statusbar, a toolbar button, or the context menu. Just click on the icon to allow, block, or temporarily allow the site to set cookies. You can also view, clear or edit the cookies and exceptions by right clicking on the cs lite icon. This is a lighter, scaled down version of CookieSafe. It contains less features, but is considerably easier to use. The extension has been completely recoded from top to bottom making this the most stable version to date. -- 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/20110802214326.11567.35488.reportbug@localhost.localdomain
