Re: debian/rules and DEB_BUILD_PROFILES vs _OPTIONS
Mattia Rizzolo: > On Sun, Sep 06, 2020 at 10:53:05PM +0200, Christian Kastner wrote: > [...] >> Or do dpkg or debhelper apply some kind of mapping logic from _OPTIONS >> to _PROFILES for the popular options nocheck, nodoc, noopt? > > debhelper does. various helpers do things differently with such > options. You should read the manpages for more details. > It does not in the general case. It does for nodoc because $HISTORICAL_REASONS. >> Or are we supposed to transition to just _PROFILES in the long term? > > There were talks around that with the people involved in writing up the > _PROFILES spec, not sure where that go (nowhere I think). > I think it would make sense for us (Debian) to look at migrating some of these use cases to rely solely on _PROFILES. I dislike us having to stick with a permanent papercut because we invented _PROFILES after _OPTIONS (as one of many "semi-permanent papercuts" in Debian packaging that I would like to remove eventually). ~Niels
Bug#894786: RFP: python-pytest-flake8 -- pytest plugin to check FLAKE8 requirements
Control: retitle -1 ITP: python-pytest-flake8 -- pytest plugin to check FLAKE8 requirements Control: owner -1 ! X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org On Wednesday, April 04 2018, Julien Puydt wrote: > * Package name: python-pytest-flake8 > Version : 1.0.0 > Upstream Author : Thorsten Lockert > * URL : https://github.com/tholo/pytest-flake8 > * License : BSD > Programming Lang: Python > Description : pytest plugin to check FLAKE8 requirements > > This pytest plugin makes it possible to check source code for Flake8 > style guide enforcement. > > The newest path.py versions use that to check the sources ; I have a > patch to disable that for now. I will package this. The current version is 1.0.6. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/ signature.asc Description: PGP signature
Bug#969708: ITP: ipyparallel -- Interactive Parallel Computing with IPython
Package: wnpp Severity: wishlist Owner: Joseph Nahmias * Package name: ipyparallel Version : 6.3.0 Upstream Author : The IPython Development Team * URL : https://github.com/ipython/ipyparallel * License : BSD Programming Lang: Python Description : Interactive Parallel Computing with IPython ipyparallel is a Python package and collection of CLI scripts for controlling clusters for Jupyter. ipyparallel is the new home of IPython.parallel. . ipyparallel contains the following CLI scripts: . ipcluster - start/stop a cluster ipcontroller - start a scheduler ipengine - start an engine ipyparallel is a dependancy for the Jupyter metakernel. As with metakernel, looking to maintain this within the DPMT.
Re: debian/rules and DEB_BUILD_PROFILES vs _OPTIONS
On Sun, Sep 06, 2020 at 10:53:05PM +0200, Christian Kastner wrote: > It seems that "nocheck" and "nodoc" can be used with both variables. > > However, which one is to be used in debian/rules recipes? Or both, as > suggested here [1]? The thing is, according to the build profile spec, if you specify nodoc or nocheck in _PROFILES you *MUST* also specify it on _OPTIONS (talking about when you do the build), so… > Looking at random packages, newer packages seem to favor just checking > DEB_BUILD_PROFILES to conditionally build documentation, but that would > mean that DEB_BUILD_OPTIONS as recommended by policy is not honored. Yeah, that might cause chances of failing builds if built with nodoc I guess… > Or do dpkg or debhelper apply some kind of mapping logic from _OPTIONS > to _PROFILES for the popular options nocheck, nodoc, noopt? debhelper does. various helpers do things differently with such options. You should read the manpages for more details. > Or are we supposed to transition to just _PROFILES in the long term? There were talks around that with the people involved in writing up the _PROFILES spec, not sure where that go (nowhere I think). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
debian/rules and DEB_BUILD_PROFILES vs _OPTIONS
It seems that "nocheck" and "nodoc" can be used with both variables. However, which one is to be used in debian/rules recipes? Or both, as suggested here [1]? Looking at random packages, newer packages seem to favor just checking DEB_BUILD_PROFILES to conditionally build documentation, but that would mean that DEB_BUILD_OPTIONS as recommended by policy is not honored. Or do dpkg or debhelper apply some kind of mapping logic from _OPTIONS to _PROFILES for the popular options nocheck, nodoc, noopt? Or are we supposed to transition to just _PROFILES in the long term? [1] https://lists.debian.org/debian-devel/2019/01/msg00080.html
Bug#969658: ITP: lookatme -- interactive command-line presentation tool
Package: wnpp Severity: wishlist Owner: Reiner Herrmann X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: lookatme Version : 1.2.0 Upstream Author : James Johnson * URL : https://github.com/d0c-s4vage/lookatme * License : MIT Programming Lang: Python3 Description : interactive command-line presentation tool lookatme is an extensible terminal-based presentation tool that renders Markdown documents and supports themes, syntax highlighting, live and manual source reloading and can embed external files and live terminals into slides.
Bug#969654: ITP: gap-nq -- provides the ANU nilpotent quotient program for computing nilpotent factor groups of finitely presented groups and makes it available as part of the gap ecosystem.
Package: wnpp Severity: wishlist Owner: Joachim Zobel * Package name: gap-nq Version : 2.5.4 Upstream Author : Werner Nickel * URL : https://www.gap-system.org/Packages/nq.html * License : GPL-2+ Programming Lang: C, GAP 4 Description : provides the ANU nilpotent quotient program for computing nilpotent factor groups of finitely presented groups and makes it available as part of the gap ecosystem. What the package actually does is best described by the upstream author: https://gap-packages.github.io/nq/README.html I am packaging this because it is a dependency for #968545.
Re: how to override piuparts for package transition to testing
Ask the release team ("unblock" bug against release.debian.org, or
debian-release@l.d.o): they can override the automated checks.
Bug#969652: ITP: xbrzscale -- Intelligent graphics file upscaling tool
Package: wnpp Severity: wishlist Owner: Peter Blackman X-Debbugs-CC: debian-devel@lists.debian.org * Package name: xbrzscale Version : 1.8 Upstream Author : Przemysław Grzywacz Zenju * URL : https://github.com/atheros/xbrzscale https://sourceforge.net/projects/xbrz/ * License : GPL-3+ Programming Lang: C++ Description : Intelligent graphics file upscaling tool Scale graphics files with the xBRZ algorithm. . xBRZ by Zenju is a modified version of xBR. It uses the same basic idea as xBR's pattern recognition and interpolation, but with a different rule set designed to preserve fine image details as small as a few pixels. This makes it useful for scaling the details in faces, and in particular eyes. xBRZ is optimized for multi-core CPUs and 64-bit architectures and shows 40–60% better performance than HQx even when running on a single CPU core only. It supports scaling images with an alpha channel, and scaling by integer factors from 2× up to 6×.
how to override piuparts for package transition to testing
Hi, How to override piuparts in getting a package to transition to testing? Package src:debian-parl is [soon removed from testing], due to dependency on package src:mozilla-noscript (and a few other reasons effective later - and depending on when you read this email my attempt at nudging to postpone may have succeded so that those other reasons are newer than that of src:mozilla-noscript, but those _future_ issues are not the subject of this email). That dependency issue is solved in unstable, but the newer package release [is blocked] from transitioning to testing due to a [bug in piuparts]. How do I get the Debian machinery to ignore piupart, so that debian-parl can transition to testing? - Jonas [soon removed from testing]: https://tracker.debian.org/pkg/debian-parl [is blocked]: https://qa.debian.org/excuses.php?package=debian-parl [bug in piuparts]: https://alioth-lists.debian.net/pipermail/piuparts-devel/2020-September/009165.html -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#969634: ITP: shellescape -- Escape arbitrary strings for use as command line arguments
Package: wnpp Severity: wishlist Owner: Jai Flack * Package name: shellescape Version : 1.2.2-1 Upstream Author : Alessio Treglia * URL : https://github.com/alessio/shellescape * License : Expat Programming Lang: Go Description : Escape arbitrary strings for use as command line arguments Escape arbitrary strings for safe use as command line arguments. Contents of the package This package provides the shellescape.Quote() function that returns a shell-escaped copy of a string. This functionality could be helpful in those cases where it is known that the output of a Go program will be appended to/used in the context of shell programs' command line arguments. Especially when creating pipeline of commands which might end up being executed by a shell interpreter, it is particularly unsafe to not escape arguments. escargs utility escargs reads lines from the standard input and prints shell-escaped versions. Unlinke xargs, blank lines on the standard input are not discarded. I intend to maintain this under the umbrella of the Go packaging team
Bug#969632: ITP: golang-github-galdor-cmdline -- A command line parser written in Go
Package: wnpp Severity: wishlist Owner: Jai Flack * Package name: golang-github-galdor-cmdline Version : 1.1.1-1 Upstream Author : Nicolas Martyanoff * URL : https://github.com/galdor/go-cmdline * License : ISC Programming Lang: Go Description : Command line parser written in Go cmdline is a Go library to parse command line options (with optional default values), arguments and subcommands. The `examples` directory contains examples for the various features of `cmdline`. You can run them with `go run`. Feel free to copy and use these examples in your own application. I intend to maintain this under the umbrella of the Go packaging team
Bug#969629: ITP: golang-github-nwaples-rardecode -- A go package for reading RAR archives.
Package: wnpp Severity: wishlist Owner: Jai Flack * Package name: golang-github-nwaples-rardecode Version : 1.1.0-1 Upstream Author : Nicholas Waples * URL : https://github.com/nwaples/rardecode * License : BSD-2-clause Programming Lang: Go Description : A go package for reading RAR archives. A go package for reading the contents and attributes of RAR archives. I intend to maintain this under the umbrella of the Go packaging team
