Bug#903953: ITP: python-ilorest -- Python based library for HPE iLO RESTful API on HPE iLO 4 and iLO 5
Package: wnpp Severity: wishlist Owner: Carsten Schoenert * Package name: python-ilorest Version : 2.3.1 Upstream Author : 2016-2018 Hewlett Packard Enterprise Restful API Group Jack Garcia Matthew Kocurek Prithvi Subrahmanya * URL : https://github.com/HewlettPackard/python-ilorest-library * License : Apache2.0 Programming Lang: Python Description : Python based library for HPE iLO RESTful API on iLO 4 and iLO 5 The Python iLO RESTful library is the platform on which the HPE RESTful tool was built on. It’s main purpose is to simplify the inband and outband communication to the HPE RESTful API. The HPE RESTful API for iLO is a RESTful application programming interface for the management of iLO and iLO Chassis Manager based HPE servers. REST (Representational State Transfer) is a web based software architectural style consisting a set of constraints that focus on a system’s resource. HPE REST library performs the basic HTTP operations GET, POST, PUT, PATCH and DELETE on resources using the HATEOS (Hypermedia as the Engine of Application) REST architecture. The API allows the clients to manage and interact with iLO through a fixed URL and several URIs. I've to deal with HPE hardware and servers mostly every day and the python library provided by HPE seems to be useful for managing mass configuration of that hardware. As HPE is one of the main contributors of the Debian project and also using hardware from HPE I guess it's worth to package this library. The source is also providing a Sphinx based documentation and some examples how to library can be used. I'm not an experienced Python library packaging person so I'm happy to find other people to co-maintain this library, talk to me on DC18 please or by email! So far I could read and study the ilorest-library isn't fully python3 ready, I'd start by packaging only the python2 variant for now. Regards Carsten
Bug#903954: ITP: sphinxcontrib-restbuilder -- Sphinx extension to build reST (reStructuredText) files
Package: wnpp Severity: wishlist Owner: Carsten Schoenert * Package name: sphinxcontrib-restbuilder Version : 0.2 Upstream Author : 2012-2013, Freek Dijkstra (gnidan) * URL : https://github.com/sphinx-contrib/restbuilder * License : BSD-2-clause Programming Lang: Python Description : Sphinx extension to build reST (reStructuredText) files This extension is in particular useful to use in combination with the autodoc extension to automatically generate documentation for use by any rst parser (such as the GitHub wiki). . In itself, the extension is fairly straightforward -- it takes the parsed reST file from Sphinx and outputs it as reST. This package is a build dependency for python-ilorest (#903953). As for python-ilorest I'm happy to find people who interested in co-maintaining. The package should be python3 ready now since upstream made some small adjustments recently. Regards Carsten
Bug#903955: ITP: ukui-window-switch -- Front of the window switch
Package: wnpp Severity: wishlist Owner: handsome_feng * Package name: ukui-window-switch Version : 1.1.1 Upstream Author : Droiing * URL : https://github.com/ukui/ukui-window-switch * License : GPL-2+, LGPL-2.1+ Programming Lang: C++ Description : Front of the window switch Front of the window switcher in UKUI desktop environment. Provides the display function(Display window thumbnails and application icons) when the window is switching (press Alt+Tab key). This package will be maintained by the Kylin Team.
GCC and binutils updates for buster
GCC 8 is available in testing/unstable, and upstream is approaching the first point release. I am planning to make GCC 8 the default at the end of the week (gdc and gccgo already point to GCC 8). Most runtime libraries built from GCC are already used in the version built from GCC 8, so I don't expect runtime incompatibilities anymore. There is one more transistion involved, bumping the libgfortran version. A pre-release version of binutils 2.31 is in testing now, and the final 2.31 release in unstable. These are the major versions for the upcoming buster release, still planning updates to a potential GCC 8.3.0 (estimated Jan 2019) release and binutils 2.31.1 release, or doing equivalent updates from the release branches. There are still a bunch of build failures triggered by GCC 8 [1], so fixing these should get some priority now. See [2] for changes in GCC 8, and the porting guide [3]. I'll be at DebCamp for the second half of the week, and at DebConf, so if there is interest for bug squashing sessions, feel free to grab me, and we can schedule such sessions on a short notice. GCC 5 and GCC 6 are going away, and I am planning the same with GCC 7 as soon as there are upstream kernel and glibc releases which are released after the GCC 8.1.0 release from April. The Debian release team lists toolchain support for our release architectures, and according to [4], the amd64, i386, armel, armhf, arm64 architectures are supported as primary architectures, and s390x is supported as a secondary architectures. Some notes on other candidates for release architectures: - armel: The armv4t default isn't used very much anymore, and we had issues in the past. - armhf: While arm-linux-gnueabihf is not explicitly listed as a primary architecture, I'm told that the arm-linux-armeabi triplet covers the hard float variants as well. - ppc64el: Not documented as primary architecture, but according to the backend maintainers the powerpc64-linux-gnu triplet includes the le variant. - mips*: There is no support for any mips-linux target either as a primary or secondary release architecture (only bare metal), which matches the experience with mips specific issues for the past Debian releases. I understand that port maintainers want to have their port included as a release architecture, however it becomes a burden if neither the upstream nor the Debian port maintainers can keep up with the general upstream development. Maybe we need something in between the alternatives of being a release arch or not, having the benefit of packages in testing/stable, but not being supported in a release. Matthias [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-8;users=debian-...@lists.debian.org [2] https://gcc.gnu.org/gcc-8/changes.html [3] https://gcc.gnu.org/gcc-8/porting_to.html [4] https://gcc.gnu.org/gcc-8/criteria.html signature.asc Description: OpenPGP digital signature
Bug#903965: ITP: ncbi-igblast -- Immunoglobulin and T cell receptor variable domain sequence analysis
Package: wnpp Severity: wishlist Owner: David Miguel Susano Pinto * Package name: ncbi-igblast Version : 1.9.0 Upstream Author : NCBI * URL : https://ncbi.github.io/igblast/ * License : PD Programming Lang: C++ Description : Immunoglobulin and T cell receptor variable domain sequence analysis IgBLAST allows users to view the matches to the germline V, D, and J genes, details at rearrangement junctions, the delineation of IG V domain framework regions, and complementarity determining regions. IgBLAST has the capability to analyse nucleotide and protein sequences, and can process sequences in batches. Furthermore, IgBLAST allows searches against the germline gene databases and other sequence databases simultaneously to minimize the chance of missing possibly the best matching germline V gene.
Bug#903973: ITP: orthanc-mysql -- Plugins to use MySQL or MariaDB as a database back-end to Orthanc
Package: wnpp Severity: wishlist Owner: Sebastien Jodogne * Package name: orthanc-mysql Version : 1.0 Upstream Author : Sebastien Jodogne * URL : https://www.orthanc-server.com/static.php?page=mysql * License : AGPL Programming Lang: C++ Description : Plugins to use MySQL or MariaDB as a database back-end to Orthanc Orthanc MySQL is a set of 2 plugins to Orthanc, a lightweight, RESTful Vendor Neutral Archive for medical imaging. These plugins override the default SQLite engine of Orthanc with a MySQL or MariaDB back-end. They bring scalability to Orthanc, making it enterprise-ready. This package should ideally be maintained by the Debian Med team, who already maintains Orthanc.
Bug#903976: ITP: sbws -- Simple Bandwidth Scanner
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: sbws Version: 1.0.0 Upstream Author: [Matt Traudt ] URL: [https://gitweb.torproject.org/sbws.git/] License: [CC0] Description: [Simple Bandwidth Scanner] Tor bandwidth scanner that generates bandwidth list (measurements) files to be read by Directory Authorities.
Bug#903977: ITP: sbws -- Simple Bandwidth Scanner
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: sbws Version: 1.0.0 Upstream Author: Matt Traudt URL: https://gitweb.torproject.org/sbws.git/ License: CC0 Description: Simple Bandwidth Scanner Tor bandwidth scanner that generates bandwidth list (measurements) files to be read by Directory Authorities.
Re: Bug#903815: ITP: pw -- A simple command-line password manager
On Mon, Jul 16, 2018 at 03:14:20PM +0200, Dashamir Hoxha wrote: It writes to `/dev/shm` which is not disk. All else that's been said aside, this idea is also dangerously incorrect in a typical configuration: the tmpfs backend will write to swap under memory pressure. (This is also true of the memory used by the process; if it's actually important to keep data from being written to persistent storage, it should be set unswappable using mlock. I have no idea how one would do this effectively in a shell script.) Mike Stone
Re: Bug#903815: ITP: pw -- A simple command-line password manager
On 18 July 2018 at 00:00, Michael Stone wrote: > On Mon, Jul 16, 2018 at 03:14:20PM +0200, Dashamir Hoxha wrote: > > > > It writes to `/dev/shm` which is not disk. > > All else that's been said aside, this idea is also dangerously incorrect in > a typical configuration: the tmpfs backend will write to swap under memory > pressure. (This is also true of the memory used by the process; if it's > actually important to keep data from being written to persistent storage, it > should be set unswappable using mlock. I have no idea how one would do this > effectively in a shell script.) It is possible, but ugly as hell in shell script. I did it in the following old script using foregrounded memlockd invocation, but that was written in shell script only really as an exercise in boredom/masochism. https://github.com/rowanthorpe/safe-key-setup/blob/master/safe-key-setup.sh#L131
Bug#904002: ITP: kylin-video -- Front-end for MPlayer and MPV
Package: wnpp Severity: wishlist Owner: handsome_feng * Package name: kylin-video Version : 1.1.7 Upstream Author : li xiang * URL : https://github.com/ukui/kylin-video * License : GPL Programming Lang: C++ Description : Front-end for MPlayer and MPV Qt5 Mplayer and MPV front-end, with basic features like playing videos and audios to more advanced features. It supports both x86 and ARM platform, and supports most of the audio and video formats. This package will be maintained by the Kylin Team.
Bug#904003: ITP: kylin-burner -- CD/DVD burning application for UKUI
Package: wnpp Severity: wishlist Owner: handsome_feng * Package name: kylin-burner Version : 3.0.6 Upstream Author : Wen Bo * URL : https://github.com/ukui/kylin-burner * License : GPL-2+, GPL-3+, LGPL-2+, LGPL-3+ Programming Lang: C Description : CD/DVD burning application for UKUI Kylin Burner is a CD/DVD mastering tool for the UKUI Desktop. It is designed to be simple and easy to use. kylin burner is fork from brasero, and did some adjustments: a. Simplify the type of recording, leaving only data burning and mirror burning b. Optimize and beautify the burning interface c. Fix some bugs in the arm platform. d. Shield the functions that not commonly used. This package will be maintained by the Kylin Team.
