Bug#869757: ITP: golang-github-biogo-hts -- biogo high throughput sequencing repository
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: golang-github-biogo-hts Version : 1.0.1+git20170705.18.8bf89f2-1 Upstream Author : bíogo * URL : https://github.com/biogo/hts * License : BSD-3-clause Programming Lang: Go Description : biogo high throughput sequencing repository SAM and BAM handling for the Go language. . bíogo/hts provides a Go native implementation of the SAM specification for SAM and BAM alignment formats commonly used for representation of high throughput genomic data, the BAI, CSI and tabix indexing formats, and the BGZF blocked compression format. The bíogo/hts packages perform parallelized read and write operations and are able to cache recent reads according to user-specified caching methods. The bíogo/hts APIs have been constructed to provide a consistent interface to sequence alignment data and the underlying compression system in order to aid ease of use and tool development. I intend to package this inside pkg-go team. This library is a dependency of packer. I need sponsor to upload. Regards, Shengjing Zhu signature.asc Description: PGP signature
New package split of util-linux
Hello! I'm looking for help with ideas about a new package split for the util-linux suite. Currently the main binary packages are: util-linux mount bsdutils (Then there are a bunch of other less important binary packages also built.) All of the three above packages have the Essential: yes control field set. This basically means when ever upstream writes a new tool and we decide to ship it, it instantly becomes part of the essential set. Additionally when one of these new or existing tools grows a new dependency that package (library?) instantly becomes pseudo-essential. The current package split being problematic has already resulted in setpriv currently being a separate package to avoid making it essential and it's new dependency pseudo-essential. I'd like to merge this tool into another package with a set of tools and make the setpriv a transitional package. Disclaimer: I'm not interested in (further) "micro-packaging". I also don't see any real reason for the mount package to be separate from the util-linux package. In short, I'm considering a new package split to be needed. If people have ideas or suggestions about this package split I'm interested to hear them. Things I'd like your to consider when suggesting a new package split: - how can we easily ship additional new tools from upstream in it? - how does it deal with new/existing dependencies to avoid making everything pseudo-essential? - how can we take over things currently shipped by other source pkgs? eg. eject[1], su/login[2], etc. - how can we make sure the essential set is as small as possible? - how can we make sure the dependencies being made pseudo-essential is kept as small as possible? - how do we transition to it from the current package split? Another possibly related issue I'd like to get feedback on is that I personally find it useful for these 'low-level utilities' packages like util-linux is to keep 'mechanism' (the tools) and 'policy' (how they are used, eg. init scripts, cron jobs, etc.) separate. The util-linux are currently pretty much mechanism only, with the notable exception of hwclock policy that *only* applies under sysvinit. I have thus considered moving this policy over to the sysvinit package but problems with moving conffiles between packages has made me spend my time elsewhere. There are though a number of different requests to introduce more policy in the util-linux package. Eg. use hwclock policy under systemd when rtc drivers are modules (rather than built in)[3], ship fstrim cron jobs[4], etc. As said I'd like to keep util-linux free from this kind of policy, so suggestions on where to put them instead or potentially how a new package split could deal with this is welcome. In case you've read this far I'll also throw in a general request for help with the util-linux package. All help is welcome and needed. If you're looking for specific issues I'll suggest looking at #869191 which currently blocks updating to a new upstream release. Also please send patches to the relevant util-linux bug report (or directly to upstream is even better if it's an upstream issue). General bug triaging also welcome, because I'm sure there are open bug reports than can likely just be closed after investigating them and their current status. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737658 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833256 [3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855203 [4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864806 Regards, Andreas Henriksson
Re: New package split of util-linux
On Wed, Jul 26, 2017 at 10:18:46AM +0200, Andreas Henriksson wrote: > I'm looking for help with ideas about a new package split for the > util-linux suite. > > Currently the main binary packages are: > util-linux > mount > bsdutils > (Then there are a bunch of other less important binary packages also > built.) > All of the three above packages have the Essential: yes control field > set. This basically means when ever upstream writes a new tool and we > decide to ship it, it instantly becomes part of the essential set. > I also don't see any real reason for the mount package to be separate > from the util-linux package. But why should mount be Essential? It's useless in containers and chroots. > In short, I'm considering a new package split to be needed. > If people have ideas or suggestions about this package split I'm > interested to hear them. What about making the split at different levels of essentialness? With the new Important: yes (not be confused with priority: important), this makes three levels, and thus three packages: * stuff that's needed on every Debian system * stuff needed on every bare-metal box / "real" VM * things you can go without Meow! -- ⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition: ⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal ⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs (the five fishes + two breads affair) ⠈⠳⣄ • use glitches to walk on water
Bug#869765: ITP: node-jed -- Gettext Style i18n for Modern JavaScript Apps
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-jed Version : 1.1.1 Upstream Author : Alex Sexton * URL : https://github.com/SlexAxton/Jed#readme * License : Expat Programming Lang: JavaScript Description : Gettext Style i18n for Modern JavaScript Apps If you don't specifically need a gettext implementation, look at MessageFormat instead, as it has better support for plurals/gender and has built-in locale data. . Jed doesn't include a Gettext file parser, but several third-party parsers exist that can have their output adapted for Jed. . Node.js is an event-based server-side JavaScript engine. This library is a dependency of gitlab signature.asc Description: OpenPGP digital signature
Bug#869776: ITP: python-hbmqtt -- MQTT client/broker for asyncio
Package: wnpp Severity: wishlist Owner: Stein Magnus Jodal * Package name: python-hbmqtt Version : 0.9 Upstream Author : Nicolas Jouanin * URL : https://hbmqtt.readthedocs.io/ * License : Expat Programming Lang: Python Description : MQTT client/broker for asyncio HBMQTT is a MQTT client and broker implementation built on top of asyncio. HBMQTT implements the full set of MQTT 3.1.1 protocol specifications and provides the following features: * Support QoS 0, QoS 1 and QoS 2 messages flow * Client auto-reconnection on network lost * Authentication through password file (more methods can be added through a plugin system) * Basic $SYS topics * TCP and websocket support * SSL support over TCP and websocket * Plugin system The package will be maintained in the Python Modules Team.
Bug#869775: ITP: python-transitions -- Lightweight state machine library
Package: wnpp Severity: wishlist Owner: Stein Magnus Jodal * Package name: python-transitions Version : 0.5.3 Upstream Author : Tal Yarkoni * URL : https://github.com/pytransitions/transitions * License : Expat Programming Lang: Python Description : Lightweight state machine library transitions is a lightweight, object-oriented state machine implementation. python-transitions is a dependency of python-hbmqtt. The package will be maintained in the Python Modules Team.
Bug#869819: ITP: golang-github-denverdino-aliyungo -- Go SDK for Aliyun (Alibaba Cloud)
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: golang-github-denverdino-aliyungo Version : 0.0~git20170721.0.80ceb80-1 Upstream Author : Li Yi * URL : https://github.com/denverdino/aliyungo * License : Apache-2.0 Programming Lang: Go Description : Go SDK for Aliyun (Alibaba Cloud) This is an unofficial Go SDK for Aliyun Services. . Following services are supported: * ecs: Elastic Compute Service * oss: Open Storage Service * slb: Server Load Balancer * dns: DNS * sls: Logging Service * ram: Resource Access Management * rds: Relational Database Service * cms: Cloud Monitor Service * cs: Container Service * sts: Security Token Service * dm: Direct Mail * sms: Short Message Service * push: Cloud Mobile Push * opensearch: OpenSearch * mq: Message Queue * nas: Network Attached Storage * common: Common libary of Aliyun Go SDK * util: Utility helpers It's the new dependency for packer. I will package this inside pkg-go team and need sponsor as well. Regards, Shengjing Zhu signature.asc Description: PGP signature
Re: New package split of util-linux
On Wed, Jul 26, 2017 at 11:03:08AM +0200, Adam Borowski wrote: > On Wed, Jul 26, 2017 at 10:18:46AM +0200, Andreas Henriksson wrote: > > I'm looking for help with ideas about a new package split for the > > util-linux suite. > > Currently the main binary packages are: > > util-linux > > mount > > bsdutils > > (Then there are a bunch of other less important binary packages also > > built.) > > All of the three above packages have the Essential: yes control field > > set. This basically means when ever upstream writes a new tool and we > > decide to ship it, it instantly becomes part of the essential set. > > I also don't see any real reason for the mount package to be separate > > from the util-linux package. > But why should mount be Essential? It's useless in containers and chroots. That's not true. It is not /required/ for basic operation of containers and chroots, which is maybe what you meant, but that doesn't mean it's useless. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#869829: ITP: golang-github-ncw-dropbox-sdk-go-unofficial -- unofficial Dropbox v2 API SDK for Go
Package: wnpp Severity: wishlist Owner: Dr. Tobias Quathamer * Package name: golang-github-ncw-dropbox-sdk-go-unofficial Version : 1.0.0+git20170530.11.5d9f46f-1 Upstream Author : Nick Craig-Wood * URL : https://github.com/ncw/dropbox-sdk-go-unofficial * License : Expat Programming Lang: Go Description : unofficial Dropbox v2 API SDK for Go An unofficial Go SDK for integrating with the Dropbox API v2. Tested with Go 1.5+ . WARNING: This SDK is NOT yet official. There is no formal Dropbox support (https://www.dropbox.com/developers/support) for this SDK at this point. Not all SDK features may be implemented and implemented features may be buggy or incorrect. This package is a dependency of the new upstream version of rclone. Regards, Tobias signature.asc Description: OpenPGP digital signature
Bug#869839: ITP: maven-reporting-api -- Maven Reporting API
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: maven-reporting-api Version : 3.0 Upstream Author : The Apache Software Foundation * URL : http://maven.apache.org/shared/maven-reporting-api/ * License : Apache-2.0 Programming Lang: Java Description : Maven Reporting API This library contains the base API for Maven plugins generating code reports. It was originally part of libmaven2-core-java but was spun off in the latest release. This package is required to upgrade the maven-invoker-plugin to the latest release. This package will be maintained by the Java Team.
Weather
Please look at the the following for a possible debian package. http://www.unidata.ucar.edu/software/gempak/ Thanks, Jonathan Moore
