Bug#898617: ITP: r-cran-ggridges -- Ridgeline Plots in 'ggplot2'
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-xyz Version : 0.5.0 Upstream Author : Claus O. Wilke, * URL : https://cran.r-project.org/package=ggridges * License : GPL-2 Programming Lang: GNU R Description : Ridgeline Plots in 'ggplot2' Ridgeline plots provide a convenient way of visualizing changes in distributions over time or space. This package enables the creation of such plots in 'ggplot2'. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-ggridges This package belongs to a set of dependencies for r-cran-brms which is needed to upgrade r-cran-emmeans to the latest upstream version.
Bug#898618: ITP: tmux-themepack-jimeh -- tmux theme pack by Jim Myhrberg
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: tmux-themepack-jimeh Version : 0+git20170413-748b16-1 Upstream Author : Jim Myhrberg * URL : https://github.com/jimeh/tmux-themepack * License : wtfpl Programming Lang: tmux Description : tmux theme pack by Jim Myhrberg A pack of tmux themes by Jim Myhrberg. It contains a basic theme and a set of powerline-enabled themes. I intend to maintain this in the Debian group on salsa.debian.org.
Bug#898623: ITP: python3-flask-assets -- Flask webassets integration.
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: python3-flask-assets Version : 0.12 Upstream Author : Michael Elsdörfer * URL : https://github.com/miracle2k/flask-assets * License : BSD-2 Programming Lang: Python Description : Flask webassets integration. Flask-Assets provides integration of webassets into Flask applications. (This is a dependency for realms-wiki)
Bug#898624: ITP: python-flask-oauth -- OAuth extension for Flask
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: python-flask-oauthlib Version : 0.9.4 Upstream Author : Hsiaoming Yang * URL : https://flask-oauthlib.readthedocs.io/en/latest/ * License : BSD Programming Lang: Python Description : OAuth extension for Flask Flask-OAuthlib is designed to be a replacement for Flask-OAuth. It depends on oauthlib. The client part of Flask-OAuthlib shares the same API as Flask-OAuth, which is pretty and simple. Features * Support for OAuth 1.0a, 1.0, 1.1, OAuth2 client * Friendly API (same as Flask-OAuth) * Direct integration with Flask * Basic support for remote method invocation of RESTful APIs * Support OAuth1 provider with HMAC and RSA signature * Support OAuth2 provider with Bearer token (Dependency for realms-wiki)
Bug#898628: ITP: python-pallets-sphinx-themes -- Sphinx themes for Pallets and related projects
Package: wnpp Severity: wishlist Owner: Ondřej Nový * Package name: python-pallets-sphinx-themes Version : 1.0.1 Upstream Author : Pallets team * URL : https://github.com/pallets/pallets-sphinx-themes * License : BSD-3-clause Programming Lang: Python Description : Sphinx themes for Pallets and related projects These are themes for the Pallets projects. Available themes: * flask * jinja * werkzeug * click I would like to maintain this package inside DPMT team. I need it as B-D for flask update.
Re: [1/2] MBF: Defunct alioth addresses in the Maintainer: field (serious)
On 05/05/18 17:34, Christoph Biedl wrote: > A lot of now defunct alioth addresses are used in the Maintainer: > field. This makes the packages rc-buggy for an invalid address. Before doing the MBF, can you send an email with all the people in Uploaders in Bcc? It may trigger some package updates or some late list migrations. I would prefer to avoid getting 700 RC bugs, but after that I guess there's no option but to file them. Cheers, Emilio
Bug#898635: ITP: r-cran-bayesplot -- GNU R plotting for bayesian models
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-bayesplot Version : 1.5.0 Upstream Author : Jonah Gabry, * URL : https://cran.r-project.org/package=bayesplot * License : GPL-3+ Programming Lang: GNU R Description : GNU R plotting for bayesian models Plotting functions for posterior analysis, model checking, and MCMC diagnostics. The package is designed not only to provide convenient functionality for users, but also a common set of functions that can be easily used by developers working on a variety of R packages for Bayesian modeling, particularly (but not exclusively) packages interfacing with 'Stan'. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-bayesplot This package belongs to a set of dependencies for r-cran-brms which is needed to upgrade r-cran-emmeans to the latest upstream version.
Bug#898642: ITP: libpdl-vectorvalued-perl -- utilities for vector-valued PDLs
Package: wnpp Severity: wishlist Owner: Laurent Baillet * Package name: libpdl-vectorvalued-perl Version : 1.0.7 Upstream Author : Bryan Jurish * URL : https://metacpan.org/release/PDL-VectorValued * License : GPL-1+ or Artistic Programming Lang: Perl Description : utilities for vector-valued PDLs This module provides some utilities for vector-valued PDLs. It is a requirement for PDL:CCS which is itself a requirement for AI::MXNet, a nice Perl interface to MXNet machine learning library. I plan to package these packages within the Debian Perl Team.
Bug#898671: ITP: libtest-more-utf8-perl -- enhance Test::More for UTF8-based projects
Package: wnpp Owner: Florian Schlichting Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libtest-more-utf8-perl Version : 0.05 Upstream Author : Mons Anderson * URL : https://metacpan.org/release/Test-More-UTF8 * License : Artistic or GPL-1+ Programming Lang: Perl Description : enhance Test::More for UTF8-based projects Test::More::UTF8 is a simple extension for the widely used Test::More module. By default, it will do a "binmode ':utf8'" on all of Test::Builder's output handles thus enabling the easy use flagged strings without warnings like "Wide character in print ..." The package will be maintained under the umbrella of the Debian Perl Group. libtest-more-utf8-perl is a new dependency of libtext-template-perl (from 1.53) -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#898673: ITP: r-cran-brobdingnag -- Very Large Numbers in R
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-brobdingnag Version : 1.2 Upstream Author : Robin K. S. Hankin * URL : https://cran.r-project.org/package=Brobdingnag * License : GPL-2 Programming Lang: GNU R Description : Very Large Numbers in R Handles very large numbers in R. Real numbers are held using their natural logarithms, plus a logical flag indicating sign. The package includes a vignette that gives a step-by-step introduction to using S4 methods. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-brobdingnag This package belongs to a set of dependencies for r-cran-brms which is needed to upgrade r-cran-emmeans to the latest upstream version.
Autodetection of packages that need visibility annotations
Hi all, Linux shared libraries by default allow for runtime interposition of symbols. This comes in handy for customization of malloc but might also have undesired consequences. Firstly, it badly affects performance of generated code as 1) compiler is not allowed to optimize (inline/clone/split) functions in fear that they will be interposed 2) calls to intra-library functions have to go through PLT 3) ld.so symbol resolution takes longer time (due to larger dynamic symbol tables) Also interposition hurts code correctness as it increases the chance of 1) inadvertent symbol collisions (see Flameeys' https://flameeyes.blog/2013/02/23/redundant-symbols/ and other related posts on his blog) 2) clients relying on private symbols (and later breaking and complaining when such symbols are removed) Recommended way to fix interposition is to build libraries with `-fvisibility=hidden` and use [GNU visibility annotations](https://gcc.gnu.org/wiki/Visibility) to mark public symbols. In effort to promote a wider use of those in open-source projects, I've recently made a simple tool to help locate Debian packages which would benefit the most from such annotations (https://github.com/yugr/ShlibVisibilityChecker). The tool (based on libclang) compares symbols exported from shlibs with those declared in package headers and reports the difference i.e. exported symbols which aren't present in headers. The idea is that such symbols are likely to be internal library symbols and thus should be marked as hidden. Here's an example usage for libacl1 package: # # Needs to be run in chroot # make clean all # scripts/debiancheck libacl1 Binary symbols not in public interface of acl: __acl_extended_file __acl_from_xattr __acl_to_xattr __bss_start closed _edata _end _fini head high_water_alloc _init next_line num_dir_handles walk_tree For a total of 14 (25%). Tool, albeit heuristic and imprecise, turned out to be useful - it could successfully process ~60% of packages I tried (main reason for failures were missing #includes in packages' public headers which are arguably package bugs). Some resulting upstream bugs are in https://github.com/yugr/ShlibVisibilityChecker#tropheys The main reason for writing this mail is that albeit I'd be happy to do more visibility patching myself, Debian has 50K packages and it would be infeasible for me, both in terms of computing power and personal time to handle this task on my own (not to mention that upstreams may be hesitant to take patches from unknown contributors). Can I suggest that interested maintainers try the tool on packages that they maintain and add visibility annotations if they turn out to provide noticeable savings (or at least bug upstream projects to enable visibility themselves)? I'd obviously be happy to fix any arising bugs or add missing features to the tool. -Yury Gribov
Re: Autodetection of packages that need visibility annotations
On Tue, May 15, 2018 at 1:29 PM, Yuri Gribov wrote: > In effort to promote a wider use of those in open-source > projects, I've recently made a simple tool to help locate Debian > packages which would benefit the most from such annotations > (https://github.com/yugr/ShlibVisibilityChecker). In case you would like to get this (or your other QA tools) into Debian, I would be happy to sponsor you. https://mentors.debian.net/intro-maintainers -- bye, pabs https://wiki.debian.org/PaulWise
