Bug#1036795: ITP: sphinx-design -- sphinx extension for creating responsive web components
Package: wnpp Severity: wishlist Owner: Dave Jones X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: sphinx-design Version : 0.4.1 Upstream Author : Executable Books * URL : https://sphinx-design.readthedocs.io/en/latest/ * License : MIT Programming Lang: Python Description : sphinx extension for creating responsive web components This is the intended successor [1] to the sphinx-panels extension, which is currently in Debian. The intent is to maintain it from the python team. [1]: https://sphinx-design.readthedocs.io/en/latest/get_started.html#migrating-from-sphinx-panels
Bug#1007924: ITP: rshell -- A remote shell for working with MicroPython boards
Package: wnpp Severity: wishlist Owner: Dave Jones X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rshell Version : 0.0.31-1 Upstream Author : https://github.com/dhylands/rshell * URL : https://pypi.org/project/rshell/ * License : MIT Programming Lang: Python Description : A remote shell for working with MicroPython boards A simple shell which runs on the host and uses MicroPython's raw-REPL to send Python snippets to the board in order to get file-system information, to copy files to and from MicroPython's file-system. It also has the ability to invoke the MicroPython REPL, so rshell can be used as a terminal emulator as well. Currently, the standard method for installing this is to use pip3. However, given it has minimal dependencies (pyserial and pyudev) which are already packaged nicely in Debian, there's no particular reason this shouldn't be deb-packaged too. The only other (direct) means of manipulating the file-system on a MicroPython device currently available in Debian (that I'm aware of) is the Thonny editor. However, Thonny requires a graphical environment, whilst rshell is also suitable for console only environments. I'm happy to maintain this package as part of the Python team.
Bug#998243: ITP: lg-gpio -- Control GPIO pins via the kernel's gpiochip device interface
Package: wnpp Severity: wishlist Owner: Dave Jones * Package name: lg-gpio Version : 0.2.0.0-1 Upstream Author : https://github.com/joan2937/lg * URL : https://abyz.me.uk/lg * License : public-domain Programming Lang: C, Python * Vcs : https://salsa.debian.org/python-team/packages/lg-gpio Section : electronics Description : Control GPIO pins via the kernel's gpiochip device interface This package provides a comprehensive userspace GPIO interface akin to libgpiod (which is already in Debian), but crucially with additional methods for performing PWM (and other interfaces). This makes it a viable replacement for RPi.GPIO (also in Debian) both in scripts that directly use that library, as well as those using gpiozero (again, already in Debian). In the latter case, the current Debian version of gpiozero (1.4 in stable) relies upon RPi.GPIO as its pin driver. However from 1.6 onwards (in unstable) it also supports lg-gpio as a (preferred) pin driver (though I don't think the patch for preferring lg is currently in the Debian version of the packaging). I'm happy to maintain this package as part of the Python team (although the Raspi team might seem more appropriate, there's nothing Raspberry Pi specific in lg-gpio). A request for sponsorship is (possibly prematurely!) open in #990280.
Bug#924643: ITP: colorzero -- Construct, convert, and manipulate colors in a Pythonic manner
Package: wnpp Severity: wishlist Owner: Dave Jones * Package name: colorzero Version : 1.1 Upstream Author : Dave Jones * URL : https://colorzero.readthedocs.io/ * License : BSD 3-clause Programming Lang: Python Description : Construct, convert, and manipulate colors in a Pythonic manner Colorzero is a library for working with colors in Python. It is not intended to be as comprehensive as colormath, but is intended to be a little easier to use, particularly for beginners. The major difference with colorzero is that colors are tuples and thus immutable. Standard mathematical operators (addition, subtraction, multiplication, etc.) are used to generate new colors. Conversions are provided for a wide variety of systems including YUV, RGB565, CMYK, CIE Lab, and so on. The GPIO Zero package (which I'm one of the upstream developers for, and which was recently kindly added to Debian by Peter Green) is currently at version 1.4.1. We released 1.5.0 recently and this has grown a dependency on my colorzero library (which was split out from my picamera library last year). It's already packaged and in Raspbian, but I'd like to get it upstream to ease the progress of GPIO Zero to 1.5.0 in Debian. I'm happy to handle maintainership of the package (I already do for Raspbian); possibly just need a sponsor to sanity check that there's nothing dreadfully broken in the current package? I've also got copies of colorzero 1.1 and gpiozero 1.5 stuffed in a PPA (https://launchpad.net/~waveform/+archive/ubuntu/pkg) for testing on Ubuntu on Pi, if that makes things any easier.
Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)
Hello, all. I am not currently a porter but I would like to be one for the s390x architecture. I am familiar with zSeries system programming and have a lot of experience in running Linux in virtual environments, mostly z/VM on large IBM processors.. I use Linux for 11 year, family with cross compiling tool chain. I am not a DD/DM. and I am somewhat surprised not to see Philiip Kern (pk...@debian.org) on the list. DJ On 10/02/2013 02:45 AM, Niels Thykier wrote: Hi, The final results are in: Summary table: Arch || DDs || NMs/DMs || Other || Total ---++-++-++---++-- armel || 3 || 0 || 1 ||4 armhf || 3 || 1 || 2 ||6 hurd-i386 || 5 || 0 || 3 ||8 ia64 || *0* || 0 || 3 ||3 kfreebsd-amd64 || 4 || 0 || 2 ||6 kfreebsd-i386 || 4 || 0 || 2 ||6 mips || 1 || 0 || 1 ||2 mipsel || 1 || 0 || 1 ||2 powerpc[1] || (1) || 0 || 2 || 2.5? s390x || *0* || 0 || 0 || *0* sparc[2] || 1 || 0 || 0 ||1 [1] The (1) and .5 is from a I am not primarily a porter [...]-remark, so I wasn't sure how to count it. [2] By the looks of it, if sparc was replaced by sparc64, we could be looking at 3 in the Other-column rather than 0. NMs/DMs include DMs and people currently in NM process. The Other column may include people who said they would like to become porters (but would need to be introduced to the job) and thus may imply some active recruiting from the current porters. This is at least true for hurd-i386. The current policy says that we require 5 developers (i.e. DDs) for release architectures[AP], so based on that only amd64, i386 and hurd-i386 would pass this requirement. It is quite possible we need to revise that requirement, but most of the architectures would (still) do well to attract a few more (DD) porters. I have attached a file with my notes of who are behind those numbers. If your name is missing or you believe I have miscounted something[CD] for an architecture listed in the table above, please reply to this email *promptly* (CC'ing me explicitly is fine) with your concerns or corrections. At this time, I have *not* updated the arch qualification table yet. I will do that in a couple of days. We will also follow up on this in the next bits from the release team. ~Niels [AP] http://release.debian.org/jessie/arch_policy.html [CD] I may (or may not) have been caffeine-deprived when I did the counting. You are free to make assumptions about whether that has affected my ability to do addic^Htion or parsing your email(s) properly. -- Dave Jones V/Soft Software www.vsoft-software.com Houston, TX 281.578.7544 -- 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/524c3ab0.2020...@vsoft-software.com
