Bug#1008970: ITP: pyimagetool -- Image Tool for multidimensional analysis
Package: wnpp Severity: wishlist Owner: Neil Williams X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org * Package name: pyimagetool Version : 1.0 Upstream Author : Kyle Gordon * URL : https://github.com/kgord831/PyImageTool * License : GPL3 Programming Lang: Python Description : Image Tool for multidimensional analysis Python Image Tool can be used to visualise analysis of data in microscopy (STM, SSM, optics), ARPES, XRD, or other multidimensional datasets on regularly gridded coordinates. . This package installs the module for Python 3 and an example helper script to create a writeable data cache. This package will be maintained within the Debian Science Team. The module provides the support to plot the data using Qt but each plot requires a custom script, based on the packaged helper, to load the data and supporting parameters. No desktop file is provided.
Bug#1008566: ITP: xrt -- XRay Tracer and wave propagation
Package: wnpp Severity: wishlist Owner: Neil Williams X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org * Package name: xrt Version : 1.4.0-1 Upstream Author : Konstantin Klementiev * URL : https://github.com/kklmn/xrt * License : Expat Programming Lang: Python Description : XRay Tracer and wave propagation XRayTracer is a python software library for ray tracing and wave propagation in x-ray regime. It is primarily meant for modeling synchrotron sources, beamlines and beamline elements. Includes a GUI for creating a beamline and interactively viewing it in 3D. This package will be maintained as part of the PaN team and Debian Science Team.
Bug#1008144: ITP: looktxt -- Convert free format text file into scientific data formats
Package: wnpp Severity: wishlist Owner: Neil Williams X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org * Package name: looktxt Version : 1.5-1 Upstream Author : Emmanuel Farhi * URL : https://github.com/farhi/looktxt * License : GPL-2+ Programming Lang: C Description : Convert free format text file into scientific data formats Search and export numerics from any text/ascii file. Data sets (scalar, vector, matrix) are given unique names, based on file content. Results can be generated for e.g. Matlab, YAML, IDL, Scilab, Octave, XML, HTML, and NeXus/HDF5. This package will be maintained with the Debian Science Team.
Bug#1006607: Extended the long description
EPICS is the Experimental Physics and Industrial Control System. . This package installs the library for Python 3 and a collection of EPICS applications, including: . * AreaDetector Display to view EPICS Area Detector images * Step Scan * Strip Chart to plot recent history of Process Variables * EPICS Instruments to help organise EPICS Process Variables * Sample Stage - a GSECARS-specific GUI for moving a set of motors for a sample stage, grabbing microscope images and saving named positions * Motor Setup - to configure EPICS Motors. * Ion Chamber - synchrotron-beamline specific application to calculate absored and transmitted flux in photons/sec and write back to EPICS Process Variables. * XRF Collector - interact with a small EPICS database to collect data from a multi-element flourescence detector. -- Neil Williams = https://linux.codehelp.co.uk/ pgpILJqOFBMBX.pgp Description: OpenPGP digital signature
Bug#1006607: ITP: epicsapps -- Collection of applications for EPICS
Package: wnpp Severity: wishlist Owner: Neil Williams X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org * Package name: epicsapps Version : 0.9.2 Upstream Author : Matthew Newville * URL : https://github.com/pyepics/epicsapps * License : EPICS Programming Lang: Python Description : Collection of applications for EPICS EPICS is the Experimental Physics and Industrial Control System. epicsapps provides a collection of apps that use EPICS and the epicsapps Python3 library. epicsapps is a dependency for xraylarch and will be maintained with the Debian PaN maintainers and Debian Science Team.
Bug#1005764: ITP: wxutils -- wxPython utilities and convenience functions
Package: wnpp Severity: wishlist Owner: Neil Williams X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org * Package name: wxutils Version : 0.2.4 Upstream Author : Matthew Newville * URL : https://github.com/newville/wxutils * License : Expat Programming Lang: Python Description : wxPython utilities and convenience functions The wxutils library is a small collection of functions and classes, and is by no means comprehensive. . The aim is to simplify code, reduce boiler-plate, make wxPython coding a bit more python-like, and prevent repeating code across several projects. This package is a dependency of xraylarch and will be maintained within the Debian Python Team.
Bug#1005763: ITP: wxmplot -- wxPython plotting widgets using matplotlib
Package: wnpp Severity: wishlist Owner: Neil Williams X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org * Package name: wxmplot Version : 0.9.46 Upstream Author : Matthew Newville * URL : https://github.com/newville/wxmplot * License : Expat Programming Lang: Python Description : wxPython plotting widgets using matplotlib wxmplot bridges the gap between matplotlib and wxPython by providing wxPython widgets and user-friendly functions for basic 2D line plots, image display, and some custom plots. This package is a dependency of xraylarch and will be maintained within the Debian Python Team.
Bug#1005114: ITP: python-model-bakery -- smart object creation facility for Django (Python 3 version)
Package: wnpp Severity: wishlist Owner: Neil Williams X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org * Package name: python-model-bakery Version : 1.4.0 Upstream Author : berinfontes * URL : https://github.com/model-bakers/model_bakery * License : Apache 2 Programming Lang: Python Description : smart object creation facility for Django (Python 3 version) Model-Bakery is the replacement for model-mommy and offers you a smart way to create fixtures for testing in Django. With a simple and powerful API you can create many objects with a single line of code. . This package provides Python 3 module bindings only. The model-mommy name was dropped upstream in favour of model-bakery. """ Model Mommy’s creator and the maintainers decided to rename the project to not reinforce gender stereotypes for women in technology """ Note: the newest model-bakery is a *lower* version string than the legacy model-mommy which it replaces and the package is in no way a drop-in replacement. model-mommy will need to persist until packages migrate. New upstream versions will only be made as model-bakery. Model-Bakery includes support for Django4 which is not going to be supported, upstream, by model-mommy. This package will be maintained within the Debian Python Team. Freexian is using a system which can be the first to migrate to the new bakery.
Bug#1004958: ITP: xraydb -- X-ray Reference Data
Package: wnpp Severity: wishlist Owner: Neil Williams X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org * Package name: xraydb Version : 4.4.7 Upstream Author : Matthew Newville * URL : https://github.com/xraypy/XrayDB * License : Public domain Programming Lang: Python Description : X-ray Reference Data X-ray Reference Data in SQLite library, including a Python3 interface. The database contains data about the interactions of X-rays with matter. xraydb is needed as a build-dependency of xraylarch (ITP #949126) xraydb will be maintained by the Debian PaN Maintainers as part of the Debian Science Team.
Bug#1003950: ITP: pyobjcryst -- Object-Oriented Crystallographic Library Python3 bindings
On Tue, 18 Jan 2022 16:16:38 +0200 Andrius Merkys wrote: > Hi Neil, > > On 2022-01-18 16:03, Neil Williams wrote: > > The package build-depends in libobjcryst (ITP #1001380) which in > > turn build-depends on cctbx (ITP: 679905), so packaging work will > > continue for a while until cctbx is accepted from NEW and > > libobjcryst can go through NEW. > > I have many times pushed interdepending packages to NEW at the same > time, without waiting for dependencies to be accepted first. I am > aware that I risk a situation to have packages without their > dependencies in the archive, but waiting for long chains of > dependencies to be accepted serially may take prolonged periods of > time. Thanks. Neither libobjcryst nor pyobjcryst at yet ready for NEW. Once I have a working stack I will look at how libobjcryst and pyobjcryst transit through NEW. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpkLbq9Jw5eL.pgp Description: OpenPGP digital signature
Bug#1003950: ITP: pyobjcryst -- Object-Oriented Crystallographic Library Python3 bindings
Package: wnpp Severity: wishlist Owner: Neil Williams X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org * Package name: pyobjcryst Version : 2.2.1-1 Upstream Author : Prof. Simon Billinge * URL : https://github.com/diffpy/pyobjcryst * License : BSD-like custom Programming Lang: C++, Python Description : Object-Oriented Crystallographic Library Python3 bindings Python bindings to ObjCryst++, the Object-Oriented Crystallographic Library. . Some examples offer 3D support which can use python3-ipywidgets. . This package installs the library for Python 3. This package is to be maintained within the Debian PaN Maintainers team and Debian Science Team. The package build-depends in libobjcryst (ITP #1001380) which in turn build-depends on cctbx (ITP: 679905), so packaging work will continue for a while until cctbx is accepted from NEW and libobjcryst can go through NEW.
Bug#679905: 2021.8+ds2-1 - Pending
On Fri, 17 Dec 2021 12:57:48 +0200 Andrius Merkys wrote: > Hi Neil, > > On 2021-12-16 11:19, Neil Williams wrote: > > README.source: > > > > cctbx for Debian > > > > > > CCTBX upstream does not manage SONAME versions, so a version is > > added in the Debian patches. This means that new upstream releases > > of cctbx should update the patch to cause a SONAME bump for all >100 > > cctbx libraries and a transition in the archive. > > I see you have switched from having all libraries in cctbx/ > subdirectory [1] to public libs and libdevel locations. Personally I > do think Debian as a downstream should be setting SONAMEs. This does > not seem to be forbidden by the policy, but in case the upstream > introduces SONAMEs, clashes may occur. Moreover, caring for ABI > compatibility is a lot of work. When trying to package libobjcryst, it became obvious that a SONAME had to be applied to cctbx, just as libobjcryst itself needs to patch in a SONAME. It is an extra amount of work but C++ symbols based on a package using lots of templates are fuzzy at best and with so many different modules in cctbx, the only practical way to handle it seems to be a new SONAME each time. The header files are also problematic. We might be able to restrict SONAME changes to upstream versions which make changes to the header files included in libcctbx-dev rather than every new upstream release. Until we've got cctbx through NEW, it is going to be hard to tell. > On a separate thread, I managed to package reduce [2] locally. > However, as you have also noted it, the name of source, binary and > executable is problematic. Maybe it is worth trying to talk to > upstream about renaming it to avoid clashes. Maybe package it as pdb-reduce or pdb-hydrogen-reduce ? /usr/bin/reduce does not exist in Debian yet but it may be worth packaging the script as pdb-reduce with a note in README.Debian - anyone switching from using the upstream build to Debian packages will need to make other changes anyway. > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679905#98 > [2] https://github.com/rlabduke/reduce > > Best, > Andrius > > -- Neil Williams = https://linux.codehelp.co.uk/ pgpAlKxg1rYlj.pgp Description: OpenPGP digital signature
Bug#679905: 2021.8+ds2-1 - Pending
MODULES = cctbx cbflib scitbx crys3d libtbx iotbx wxtbx smtbx debian/control: Computational Crystallography Toolbox contains following modules: boost_adaptbx: wrappers for Boost functionality in CCTBX cctbx: Libraries for general crystallographic applications, useful for both small-molecule and macro-molecular crystallography. crys3d: Modules for the display of molecules, electron density, and reciprocal space data. fable: Fortran EMulation library for porting Fortran77 to C++. iotbx: Working with common crystallographic file formats. omptbx: OpenMP interface. scitbx: General scientific calculations. his includes a family of high-level C++ array types, a fast Fourier transform library, and a C++ port of the popular L-BFGS quasi-Newton minimizer. smtbx: Small-Molecule crystallography. wxtbx: wxPython controls used in the Phenix GUI and various utilities 108 shared libraries are built in the current package: boost_adaptbx_boost_thread_test_ext.so.0.0.1 boost_adaptbx_graph_breadth_first_search_ext.so.0.0.1 boost_adaptbx_graph_clustering_algorithm_ext.so.0.0.1 boost_adaptbx_graph_connected_component_algorithm_ext.so.0.0.1 boost_adaptbx_graph_ext.so.0.0.1 boost_adaptbx_graph_graph_structure_comparison_ext.so.0.0.1 boost_adaptbx_graph_maximum_clique_ext.so.0.0.1 boost_adaptbx_graph_metric_ext.so.0.0.1 boost_adaptbx_graph_min_cut_max_flow_ext.so.0.0.1 boost_adaptbx_graph_utility_ext.so.0.0.1 boost_adaptbx_python_streambuf_test_ext.so.0.0.1 boost_optional_ext.so.0.0.1 boost_python_hybrid_times_ext.so.0.0.1 boost_python_meta_ext.so.0.0.1 boost_rational_ext.so.0.0.1 boost_tuple_ext.so.0.0.1 cctbx_adp_restraints_ext.so.0.0.1 cctbx_adptbx_ext.so.0.0.1 cctbx_anharmonic_ext.so.0.0.1 cctbx_array_family_flex_ext.so.0.0.1 cctbx_asymmetric_map_ext.so.0.0.1 cctbx_covariance_ext.so.0.0.1 cctbx_crystal_ext.so.0.0.1 cctbx_dmtbx_ext.so.0.0.1 cctbx_eltbx_attenuation_coefficient_ext.so.0.0.1 cctbx_eltbx_chemical_elements_ext.so.0.0.1 cctbx_eltbx_covalent_radii_ext.so.0.0.1 cctbx_eltbx_fp_fdp_ext.so.0.0.1 cctbx_eltbx_henke_ext.so.0.0.1 cctbx_eltbx_icsd_radii_ext.so.0.0.1 cctbx_eltbx_neutron_ext.so.0.0.1 cctbx_eltbx_sasaki_ext.so.0.0.1 cctbx_eltbx_tiny_pse_ext.so.0.0.1 cctbx_eltbx_wavelengths_ext.so.0.0.1 cctbx_eltbx_xray_scattering_ext.so.0.0.1 cctbx_emma_ext.so.0.0.1 cctbx_french_wilson_ext.so.0.0.1 cctbx_geometry_ext.so.0.0.1 cctbx_geometry_restraints_ext.so.0.0.1 cctbx_maptbx_ext.so.0.0.1 cctbx_masks_ext.so.0.0.1 cctbx_math_ext.so.0.0.1 cctbx_merging_ext.so.0.0.1 cctbx_miller_ext.so.0.0.1 cctbx_multipolar_ext.so.0.0.1 cctbx_orientation_ext.so.0.0.1 cctbx_sgtbx_asu_ext.so.0.0.1 cctbx_sgtbx_ext.so.0.0.1 cctbx_statistics_ext.so.0.0.1 cctbx_symmetry_search_ext.so.0.0.1 cctbx_translation_search_ext.so.0.0.1 cctbx_uctbx_ext.so.0.0.1 cctbx_xray_ext.so.0.0.1 cctbx_xray_observations_ext.so.0.0.1 determine_unit_cell_ext.so.0.0.1 fable_ext.so.0.0.1 iotbx_detectors_bruker_ext.so.0.0.1 iotbx_detectors_ext.so.0.0.1 iotbx_dsn6_map_ext.so.0.0.1 iotbx_dtrek_ext.so.0.0.1 iotbx_pdb_ext.so.0.0.1 iotbx_pdb_hierarchy_ext.so.0.0.1 iotbx_scalepack_ext.so.0.0.1 iotbx_shelx_ext.so.0.0.1 iotbx_wildcard_ext.so.0.0.1 iotbx_xplor_ext.so.0.0.1 libasymmetric_map.so.0.0.1 libcctbx_sgtbx_asu.so.0.0.1 libcctbx.so.0.0.1 libiotbx_pdb.so.0.0.1 libiotbx_xplor.so.0.0.1 libomptbx.so.0.0.1 libscitbx_boost_python.so.0.0.1 libscitbx_minpack.so.0.0.1 libscitbx_slatec.so.0.0.1 libsmtbx_refinement_constraints.so.0.0.1 omptbx_ext.so.0.0.1 scitbx_array_family_flex_ext.so.0.0.1 scitbx_array_family_shared_ext.so.0.0.1 scitbx_cubicle_neighbors_ext.so.0.0.1 scitbx_fftpack_ext.so.0.0.1 scitbx_glmtbx_ext.so.0.0.1 scitbx_graphics_utils_ext.so.0.0.1 scitbx_iso_surface_ext.so.0.0.1 scitbx_lbfgsb_ext.so.0.0.1 scitbx_lbfgs_ext.so.0.0.1 scitbx_linalg_ext.so.0.0.1 scitbx_lstbx_normal_equations_ext.so.0.0.1 scitbx_math_ext.so.0.0.1 scitbx_minpack_ext.so.0.0.1 scitbx_r3_utils_ext.so.0.0.1 scitbx_random_ext.so.0.0.1 scitbx_rigid_body_ext.so.0.0.1 scitbx_sparse_ext.so.0.0.1 scitbx_stl_map_ext.so.0.0.1 scitbx_stl_set_ext.so.0.0.1 scitbx_stl_vector_ext.so.0.0.1 scitbx_suffixtree_shared_ext.so.0.0.1 scitbx_suffixtree_single_ext.so.0.0.1 scitbx_wigner_ext.so.0.0.1 smtbx_ab_initio_ext.so.0.0.1 smtbx_array_family_ext.so.0.0.1 smtbx_refinement_constraints_ext.so.0.0.1 smtbx_refinement_least_squares_ext.so.0.0.1 smtbx_refinement_restraints_ext.so.0.0.1 smtbx_stl_map_ext.so.0.0.1 smtbx_structure_factors_direct_ext.so.0.0.1 std_pair_ext.so.0.0.1 README.source: cctbx for Debian CCTBX upstream does not manage SONAME versions, so a version is added in the Debian patches. This means that new upstream releases of cctbx should update the patch to cause a SONAME bump for all >100 cctbx libraries and a transition in the archive. -- Neil Williams = https://linux.codehelp.co.uk/ pgpviA0gWR68C.pgp Description: OpenPGP digital signature
Bug#679905: Working build being tested
On Thu, 9 Dec 2021 15:30:42 +0200
Andrius Merkys wrote:
> Hi Neil,
>
> On 2021-12-09 12:06, Neil Williams wrote:
> > On Thu, 9 Dec 2021 11:22:28 +0200
> > Andrius Merkys wrote:
> >> On 2021-12-09 11:05, Neil Williams wrote:
> >>> Only the cctbx cbflib scitbx crys3d libtbx iotbx wxtbx smtbx
> >>> modules are enabled. Some modules require dependencies which are
> >>> not available within Debian.
> >>
> >> What are the dependencies needed to build the rest of the modules?
> >> I would gladly lend a hand to get them into Debian.
> >
> > Depends how far you want to push the bootstrap script.
> >
> > Two I've found so far:
> >
> > https://github.com/rlabduke/reduce
> >
> > https://salsa.debian.org/science-team/dials
>
> AFAIR, dials depend on cctbx. Might be a circular dependency.
... or it may just be that it needs reduce (which is a terrible name
for a package)
> > My work on cctbx is only going to go as far as the requirements for
> > libobjcryst and thereby pyobjcryst.
>
> Understood. I am mostly interested in dials and xia2.
AFAICT there is neither dials nor xia2 support available to be
compiled from the current bootstrap of cctbx. The bootstrap script is
confusing but it looks like there could be circular dependencies with
both dials and xia2.
The bootstrap script looks like it would try to download:
https://github.com/xia2/xia2/archive/main.zip
https://github.com/dials/dials/archive/main.zip
Salsa CI is configured for cctbx, there are test packages available
from those CI pipelines. https://salsa.debian.org/science-team/cctbx
There's just a cctbx and python3-cctbx binary package at the
moment. Note that the internal layout of the packages **is** going to
change. There is no apparent API within the libraries, so I cannot
(yet) package cctbx such as to create Policy-compliant lib* or -dev
packages. So I am currently including all .so files into a cctbx/
subdirectory and packages using cctbx will have to be patched to use
that location and use a (= ${binary:Version}) dependency - I've
described this in README.source.
--
Neil Williams
=
https://linux.codehelp.co.uk/
pgpX_nYPpU1_i.pgp
Description: OpenPGP digital signature
Bug#1001380: ITP: libobjcryst -- Object-Oriented Crystallographic Library for C++
Package: wnpp Severity: wishlist Owner: Neil Williams X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org * Package name: libobjcryst Version : 2021.1.1-1 Upstream Author : Vincent Favre-Nicolin vinc...@users.sourceforge.net * URL : https://github.com/diffpy/libobjcryst * License : GPL Programming Lang: C++ Description : Object-Oriented Crystallographic Library for C++ libobjcryst expands the ObjCryst++ source to make it easier to use as a system shared lirbary but does not include GUI related files from ObjCryst++. This package will use CCTBX from #679905 and be maintained by the Debian PaN Maintainers and Debian Science Team.
Bug#679905: Working build being tested
On Thu, 9 Dec 2021 11:22:28 +0200 Andrius Merkys wrote: > Hi Neil, > > On 2021-12-09 11:05, Neil Williams wrote: > > New upstream version is now building in Salsa CI. > > > > https://salsa.debian.org/science-team/cctbx > > Awesome news! Are you getting binary packages that could be used by > reverse-dependencies of cctbx? > > > This build is targeted at supported libobjcryst and thereby > > pyobjcryst. > > > > https://salsa.debian.org/science-team/cctbx/-/blob/master/debian/README.source > > > > cctbx for Debian > > > > > > Only the cctbx cbflib scitbx crys3d libtbx iotbx wxtbx smtbx modules > > are enabled. Some modules require dependencies which are not > > available within Debian. > > What are the dependencies needed to build the rest of the modules? I > would gladly lend a hand to get them into Debian. Depends how far you want to push the bootstrap script. Two I've found so far: https://github.com/rlabduke/reduce https://salsa.debian.org/science-team/dials My work on cctbx is only going to go as far as the requirements for libobjcryst and thereby pyobjcryst. -- Neil Williams = https://linux.codehelp.co.uk/ pgpxpf5c2SNLg.pgp Description: OpenPGP digital signature
Bug#679905: Working build being tested
owner 679905 ! retitle 679905 ITP: cctbx -- Computational Crystallography Toolbox thanks New upstream version is now building in Salsa CI. https://salsa.debian.org/science-team/cctbx This build is targeted at supported libobjcryst and thereby pyobjcryst. https://salsa.debian.org/science-team/cctbx/-/blob/master/debian/README.source cctbx for Debian Only the cctbx cbflib scitbx crys3d libtbx iotbx wxtbx smtbx modules are enabled. Some modules require dependencies which are not available within Debian. -- Neil Williams = https://linux.codehelp.co.uk/ pgpj6bSjsvlqz.pgp Description: OpenPGP digital signature
Bug#1001000: O: puppet-beaker -- test harness providing platform abstraction and VM provisioning
Package: wnpp Severity: normal X-Debbugs-Cc: codeh...@debian.org Control: affects -1 src:puppet-beaker The freexian packaging team is no longer maintaining puppet-beaker or the dependencies, so I am orphaning the puppet-beaker package. The package VCS is already part of the Debian team in Salsa: https://salsa.debian.org/debian/puppet-beaker.git The package description is: Test harness focused on acceptance testing via interactions between multiple (virtual) machines. It provides platform abstraction between different Systems Under Test (SUTs), and it can also be used as a virtual machine provisioner - setting up machines, running any commands on those machines, and then exiting. . Beaker runs tests written in Ruby, and provides additional Domain-Specific Language (DSL) methods. This gives you access to all standard Ruby along with acceptance testing specific commands. -- Neil Williams = https://linux.codehelp.co.uk/ pgp6Aq0EywQZ7.pgp Description: OpenPGP digital signature
Bug#1000996: O: ruby-beaker-hostgenerator -- command line utility designed to generate beaker host config files
Package: wnpp Severity: normal X-Debbugs-Cc: codeh...@debian.org Control: affects -1 src:ruby-beaker-hostgenerator The freexian packaging team is no longer maintaining puppet-beaker or the dependencies, so I am orphaning the ruby-beaker-hostgenerator package. The package VCS is already part of the Debian team in Salsa: https://salsa.debian.org/debian/ruby-beaker-hostgenerator.git The package description is: beaker-hostgenerator is a command line utility designed to generate beaker host config files using a compact command line SUT specification.
Bug#1000995: O: ruby-in-parallel -- lightweight Ruby library with very simple syntax for parallelization
Package: wnpp Severity: normal X-Debbugs-Cc: codeh...@debian.org Control: affects -1 src:ruby-in-parallel The freexian packaging team is no longer maintaining puppet-beaker or the dependencies, so I am orphaning the ruby-in-parallel package. The package VCS is already part of the Debian team in Salsa: https://salsa.debian.org/debian/ruby-in-parallel.git The package description is: A lightweight Ruby library with very simple syntax, making use of Process.fork to execute code in parallel. . Many other Ruby libraries that simplify parallel execution support one primary use case - crunching through a large queue of small, similar tasks as quickly and efficiently as possible. This library primarily supports the use case of executing a few larger and unrelated tasks in parallel, automatically managing the stdout and passing return values back to the main process. . This library was created to be used by Puppet's Beaker test framework to enable parallel execution of some of the framework's tasks, and allow users to execute code in parallel within their tests. . If you are looking for something that excels at executing a large queue of tasks in parallel as efficiently as possible, you should take a look at the parallel project.
Bug#1000994: O: ruby-open-uri-redirections -- openuri patch to allow redirections between HTTP and HTTPS
Package: wnpp Severity: normal X-Debbugs-Cc: codeh...@debian.org Control: affects -1 src:ruby-open-uri-redirections The freexian packaging team is no longer maintaining puppet-beaker or the dependencies, so I am orphaning the ruby-open-uri-redirections package. The package VCS is already part of the Debian team in Salsa: https://salsa.debian.org/debian/ruby-open-uri-redirections.git The package description is: This applies a patch to OpenURI to optionally allow redirections from HTTP to HTTPS, or from HTTPS to HTTP.
Bug#1000993: O: ruby-pry-byebug -- step-by-step debugging and stack navigation capabilities in pry using byebug
Package: wnpp Severity: normal X-Debbugs-Cc: codeh...@debian.org Control: affects -1 src:ruby-pry-byebug The Freexian packagign team is no longer maintaining puppet-beaker and dependencies, so I am orphaning the ruby-pry-byebug package. The VCS is already part of the Debian team in Salsa: https://salsa.debian.org/debian/ruby-pry-byebug.git The package description is: Adds step-by-step debugging and stack navigation capabilities to pry using byebug. . To use, invoke pry normally. No need to start your script or app differently: execution will stop in the first statement after your binding.pry.
Bug#1000992: O: ruby-stringify-hash -- ruby hash object that treats symbols and strings interchangeably
Package: wnpp Severity: normal X-Debbugs-Cc: codeh...@debian.org Control: affects -1 src:ruby-stringify-hash The freexian packaging team is no longer maintaining puppet-beaker or the dependencies, so I am orphaning the ruby-stringify-hash package. The package VCS is already part of the Debian team in Salsa. https://salsa.debian.org/debian/ruby-stringify-hash.git The package description is: A ruby hash object that treats symbols and strings interchangeably, and also recursively merges hashes.
Bug#1000444: ITP: horae -- interactive graphical processing and analysis of EXAFS data
Package: wnpp Severity: wishlist Owner: Neil Williams X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org * Package name: horae Version : 071~svn537-3 Upstream Author : Bruce Ravel * URL : https://github.com/bruceravel/horae * License : custom (contrib) Programming Lang: Perl Description : interactive graphical processing and analysis of EXAFS data ATHENA is an interactive graphical utility for processing EXAFS data. It handles most of the common data handling chores of interest, including deglitching, aligning, merging, background removal, and Fourier transforms. . ARTEMIS is an interactive graphical utility for fitting EXAFS data using theoretical standards from FEFF and sophisticated data modelling along with flexible data visualization and statistical analysis. . HEPHAESTUS is a souped up periodic table for the x-ray absorption spectroscopist. It provides a number of utilities involving tables of absorption coefficients and other chemical data. This package was removed due to the removal of ifeffit which has now been fixed and reintroduced. horae was the only dependency removed with ifeffit. The original use case for horae still exists and would have been retained if ifeffit had not had to be removed. Other alternatives are not yet ready for packaging. This package is to be maintained with the Debian Science Team.
Bug#996254: ITP: python-platformdirs -- Determine appropriate platform-specific data directories
Package: wnpp Severity: wishlist Owner: Neil Williams X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-platformdirs Version : 2.4.0 Upstream Author : Bernát Gábor * URL : https://github.com/platformdirs/platformdirs * License : MIT Programming Lang: Python Description : Determine appropriate platform-specific data directories Python helper module for desktop applications to find the correct location to store user data and configuration, according to the platform. This package is a dependency of the new upstream version of black and will be maintained with the Debian Python team.
Bug#996203: ITP: ifeffit -- Interactive XAFS analysis program
Package: wnpp Severity: wishlist Owner: Neil Williams X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org * Package name: ifeffit Version : 2:1.2.11d-11 Upstream Author : Matt Newville * URL : https://cars.uchicago.edu/ifeffit/Documentation * License : GPL-2+ Programming Lang: C, Fortran, Perl Description : Interactive XAFS analysis program IFEFFIT is an interactive program for XAFS analysis. It combines the high-quality analysis algorithms of AUTOBK and FEFFIT with graphical display of XAFS data and general data manipulation. . IFEFFIT comes as a command-line program, but the underlying functionality is available as a programming library. The IFEFFIT library can be used from C, Fortran, Tcl, and Perl. This package is to be maintained with the Debian Science Team and is a reintroduction of the same package, with all Python and GUI elements omitted from the packaging (no working Python3 support is available).
Bug#995819: ITP: xrstools -- x-ray Raman scattering tools
Package: wnpp Severity: wishlist Owner: Neil Williams X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org * Package name: xrstools Version : 0.15.0+git20210910+c147919d-1 Upstream Author : European Synchrotron Radiation Facility * URL : https://gitlab.esrf.fr/ixstools/xrstools/-/tree/mac * License : MIT Programming Lang: Python Description : x-ray Raman scattering tools Collection of tools and Python3 modules to extract and analyze x-ray Raman scattering (XRS) data from ID20 of the European Synchrotron Radiation Facility This package is to be maintained with the Debian Science Team.
Bug#995371: ITP: navarp -- Navigation tool for ARPES data
Package: wnpp Severity: wishlist Owner: Neil Williams X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org * Package name: navarp Version : 1.0.0-1 Upstream Author : Federico Bisti * URL : https://gitlab.com/fbisti/navarp * License : GPL3 Programming Lang: Python Description : Navigation tool for ARPES data NavARP provides a navigation tool for Angle Resolved Photoemission spectroscopy data. NavARP is a companion app during ARPES data acquitision (as in beamtime) and set of dedicated libraries helping to get high quality figures for publication. This package is to be maintained with the Debian Science Team.
Bug#994993: Switch O: to RM: due to FTBFS & missing dependency
reassign 994991 ftp.debian.org retitle 994991 RM: centreon-connectors -- ROM; FTBFS needs dependency not in Debian, unmaintained. reassign 994993 ftp.debian.org retitle 994993 RM: centreon-engine -- ROM; FTBFS needs dependency not in Debian, unmaintained. thanks See also 994986 centreon-connectors and centreon-engine depend on an unversioned shared library from the centreon-clib source package without setting any version requirements themselves and without centreon-clib declaring any Breaks or other relationship on the dependencies. Furthermore, centreon upstream do not maintain the API of libcentreon-clib across upstream releases. Therefore, updating centreon-clib caused a FTBFS in each dependency. Both centreon-connectors and centreon-engine have new upstream versions which should match the updated centreon-clib but these new versions require a new build dependency which is not yet packaged for Debian. All three packages are already orphaned - the work to package the new dependency would be required if the packages are adopted. To fix the current FTBFS problems in unstable, please remove centreon-connectors and centreon-engine. -- Neil Williams = https://linux.codehelp.co.uk/ pgpFEajGfl_cb.pgp Description: OpenPGP digital signature
Bug#994986: Unversioned library problems
centreon-clib has an unversioned library: /usr/lib/libcentreon_clib.so Centreon upstream do not maintain this API across upstream releases. Each centreon dependency using centreon-clib needs to be the same upstream source version as centreon-clib itself. Additionally, packages which depended on centreon-clib have not had a versioned dependency in the past, e.g.: Build-Depends: debhelper (>= 11), cmake, libcentreon-clib, pkg-config, libssh2-1-dev, libperl-dev, libgcrypt20-dev (Should have been libcentreon-clib=19.10.0~) When centreon-clib was updated, these dependencies then failed to build against the new centreon-clib. e.g. In file included from /<>/perl/build/../inc/com/centreon/connector/perl/checks/timeout.hh:24, from /<>/perl/src/checks/timeout.cc:20: /usr/include/com/centreon/task.hh:38:9: note: declared here 38 | task& operator=(task const& t) = delete; | ^~~~ make[4]: *** [CMakeFiles/centreonconnectorperl.dir/build.make:122: CMakeFiles/centreonconnectorperl.dir/<>/perl/src/checks/timeout.cc.o] Error 1 make[4]: Leaving directory '/<>/perl/build' make[3]: *** [CMakeFiles/Makefile2:111: CMakeFiles/centreonconnectorperl.dir/all] Error 2 (The new upstream version of the dependency cannot be uploaded yet as it introduces a build-dependency which is not yet packaged for Debian.) Previous uploads relied on parallel uploads of the same upstream release. If centreon-clib is adopted, suitable Breaks: versions will need to be added for centreon-broker centreon-connectors and centreon-engine. If any dependencies of centreon-clib are introduced / adopted / reintroduced into Debian, strict versioned dependencies on the source version of centreon-clib will be required. (i.e. = not >=) -- Neil Williams = https://linux.codehelp.co.uk/ pgpbKfP9mlnV4.pgp Description: OpenPGP digital signature
Bug#994997: O: tcmu
Package: wnpp Severity: normal X-Debbugs-Cc: codeh...@debian.org Control: affects -1 src:tcmu The Freexian packaging team is no longer maintaining the centreon-* packages, so I am orphaning this package now. Library that handles the userspace side of the LIO TCM-User backstore LIO is the SCSI target in the Linux kernel. It is entirely kernel code, and allows exported SCSI logical units (LUNs) to be backed by regular files or block devices. But, if one want to get fancier with the capabilities of the device one is emulating, the kernel is not necessarily the right place. While there are userspace libraries for compression, encryption, and clustered storage solutions like Ceph or Gluster, these are not accessible from the kernel. . The TCMU userspace-passthrough backstore allows a userspace process to handle requests to a LUN. But since the kernel-user interface that TCMU provides must be fast and flexible, it is complex enough that one would like to avoid each userspace handler having to write boilerplate code. . tcmu-runner handles the messy details of the TCMU interface -- UIO, netlink, pthreads, and DBus -- and exports a more friendly C plugin module API. Modules using this API are called "TCMU handlers". Handler authors can write code just to handle the SCSI commands as desired, and can also link with whatever userspace libraries they like.
Bug#994995: O: ceph-iscsi -- common logic and CLI tools for creating and managing LIO gateways for Ceph
Package: wnpp Severity: normal X-Debbugs-Cc: codeh...@debian.org Control: affects -1 src:ceph-iscsi The Freexian packaging team is no longer maintaining the centreon-* packages, so I am orphaning this package now. The package description is: It includes the rbd-target-api daemon which is responsible for restoring the state of LIO following a gateway reboot/outage and exporting a REST API to configure the system using tools like gwcli. It replaces the existing 'target' service. . There is also a second daemon rbd-target-gw which exports a REST API to gather statistics. . It also includes the CLI tool gwcli which can be used to configure and manage the Ceph iSCSI gateway, which replaces the existing targetcli CLI tool. This CLI tool utilizes the rbd-target-api server daemon to configure multiple gateways concurrently.
Bug#994994: O: json11
Package: wnpp Severity: normal X-Debbugs-Cc: codeh...@debian.org Control: affects -1 src:json11 The Freexian packaging team is no longer maintaining the centreon-* packages, so I am orphaning this package now. The VCS will move out of the private salsa team & I'll do a QA upload. Description: Tiny JSON library for C++11 json11 is a tiny JSON library for C++11, providing JSON parsing and serialization. . The core object provided by the library is json11::Json. A Json object represents any JSON value: null, bool, number (int or double), string (std::string), array (std::vector), or object (std::map). . Json objects act like values. They can be assigned, copied, moved, compared for equality or order, and so on. There are also helper methods Json::dump, to serialize a Json to a string, and Json::parse (static) to parse a std::string as a Json object.
Bug#994993: O: centreon-engine
Package: wnpp Severity: normal X-Debbugs-Cc: codeh...@debian.org Control: affects -1 src:centreon-engine The Freexian packaging team is no longer maintaining the centreon-* packages, so I am orphaning this package now. The VCS will move out of the private salsa team & I'll do a QA upload. NOTE: the new version, 21.04.3, brings in a new dependency which is not yet packaged for Debian: conan. See also #994984 and #994991 This dependency will need to be packaged if centreon-engine is adopted. The current version of centreon-engine (19.10.8) does build. If this changes, centreon-engine may need to be removed. The description of centreon-engine is: Network, system, applicative supervision and monitoring - engine Centreon is a modular and flexible platform for network, system and applicative supervision and monitoring. . * monitoring of network services * monitoring of host resources * simple plugin design that allows users to easily develop their own service checks * parallelized service checks * ability to define network hierarchies * contact notifications when service or host problems occur and get resolved (via email, page, or user-defined method) * ability to define event handlers to be run during service or host events for proactive problem resolution * automatic log file rotation * support for implementing redundant monitoring hosts
Bug#994991: O: centreon-connectors
Package: wnpp Severity: normal X-Debbugs-Cc: codeh...@debian.org Control: affects -1 src:centreon-connectors The Freexian packaging team is no longer maintaining the centreon-* packages, so I am orphaning this package now. The VCS will move out of the private salsa team & I'll do a QA upload. NOTE: the new version, 21.04.2, brings in a new dependency which is not yet packaged for Debian: conan. include could not find requested file: /<>/conan_paths.cmake This dependency will need to be packaged if centreon-connectors is adopted. The current version of centreon-connectors (19.10.0) does build. If this changes, centreon-connectors may need to be removed. The centreon-connectors source description is: Network, system, applicative supervision and monitoring - ssh connector Centreon is a modular and flexible platform for network, system and applicative supervision and monitoring. . * monitoring of network services * monitoring of host resources * simple plugin design that allows users to easily develop their own service checks * parallelized service checks * ability to define network hierarchies * contact notifications when service or host problems occur and get resolved (via email, page, or user-defined method) * ability to define event handlers to be run during service or host events for proactive problem resolution * automatic log file rotation * support for implementing redundant monitoring hosts .
Bug#994986: O: centreon-clib
Package: wnpp Severity: normal X-Debbugs-Cc: codeh...@debian.org Control: affects -1 src:centreon-clib The Freexian packaging team is no longer maintaining the centreon-* packages, so I am orphaning this package now. The VCS will move out of the private salsa team & I'll do a QA upload to provide the new upstream version. The centreon-clib source builds the libcentreon-clib package: Network, system, applicative supervision and monitoring - core libraries Centreon is a modular and flexible platform for network, system and applicative supervision and monitoring. * monitoring of network services * monitoring of host resources * simple plugin design that allows users to easily develop their own service checks * parallelized service checks * ability to define network hierarchies * contact notifications when service or host problems occur and get resolved (via email, page, or user-defined method) * ability to define event handlers to be run during service or host events for proactive problem resolution * automatic log file rotation * support for implementing redundant monitoring hosts This package contains the core clib libraries.
Bug#994936: ITP: dmrgpp -- Density matrix renormalization group algorithm
Package: wnpp Severity: wishlist Owner: Neil Williams X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org * Package name: dmrgpp Version : 6.00-1 Upstream Author : Gonzalo Alvarez * URL : https://github.com/g1257/dmrgpp * License : UT Battelle Open Source Software License 11242008 Programming Lang: C, C++ Description : Density matrix renormalization group algorithm DMRGPP / DMRG++ is an implementation of the Density matrix renormalization group algorithm which attempts to find the lowest-energy matrix product state wavefunction corresponding to the total energy of the system. DMRGPP embeds the PsimagLite utility to obtain codes for the simulation of strongly correlated electrons. This package is to be maintained with the Debian Science Team.
Bug#994756: Update impact
severity 994756 important thanks The CVEs mentioned have been assessed as minor issues, likely to only cause the ccextractor command line utility to crash. The embedded gpac code in ccextractor is mostly limited to just the gpac source code files that ccextractor needs to process video files, so most, if not all, of the code paths in the upstream gpacmp4 directory should be reachable with appropriate test videos. bullseye and buster updates can be made via proposed-updates. Downgrading the bug against bullseye and buster versions to not block migration of the 0.93+ds2-1 fixes into bookworm, reflecting the assessed security impact. -- Neil Williams = https://linux.codehelp.co.uk/ pgpntHuAAZ3YQ.pgp Description: OpenPGP digital signature
Bug#994549: ITP: clpeak -- Profile OpenCL devices to find peak capacities
Package: wnpp Severity: wishlist Owner: Neil Williams X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org * Package name: clpeak Version : 1.1.0-1 Upstream Author : Krishnaraj Bhat * URL : https://github.com/krrishnarraj/clpeak * License : The Unlicense Programming Lang: C, C++ Description : Profile OpenCL devices to find peak capacities Clpeak is a synthetic benchmarking tool to measure peak capabilities of opencl devices. It only measures the peak metrics that can be achieved using vector operations and does not represent a real-world use case This package is to be maintained with the Debian OpenCL maintainers in Salsa. The Unlicence text: A license with no conditions whatsoever which dedicates works to the public domain. Unlicensed works, modifications, and larger works may be distributed under different terms and without source code.
Bug#976075: O: pyocd
Package: wnpp Severity: normal I'm no longer using pyocd, so it is orphaned. I would recommend it is added to the Debian Python team and moved to Salsa. Package description: ARM Cortex-M programming tools (Python3) pyOCD is an Open Source Python based library for programming and debugging ARM Cortex-M microcontrollers using CMSIS-DAP. . Includes support for flashing new binaries, resetting the device, halt, step, resume read/write memory and set/remove breakpoints.
Bug#976074: O: intelhex
Package: wnpp Severity: normal I'm no longer using intelhex and so I am orphaning the package. I would recommend that this package is added to the Debian Python team and moved to Salsa. (It's in Github for reasons related to my previous employment only.) Package description is: Python support for Intel HEX (Python3) The Intel HEX file format is widely used in the microprocessors and microcontrollers area as the de facto standard for code representation for microelectronic devices programming. . This package implements an intelhex Python library to read, write, create from scratch and manipulate data from HEX (also known as Intel HEX) file format.
Bug#784111: Removal of libxsettings is now possible
Bug#729891: fixed in matchbox-window-manager 1.2-osso21-3 Bug#729887: fixed in libmatchbox 1.9-osso8-5 Thanks to Moray Allen for closing these two bugs, it should be possible to remove libxsettings in due course. (Let the fixed packages migrate to buster.) Original rationale for removal from the two bugs: > Continuing the removal of GPE from Debian. Upstream has been dead > for some time. The environment itself is aimed at a dead platform > (iPAQ) and is unsuitable for use on current devices like phones or > tablets without widescale modification. I've no interest in > maintaining it any longer but rather than simply orphan ~60 packages, > I've decided to seek removal on the basis that the orphaned > environment would be unmaintainable in the long term. There is zero > prospect of GPE ever being ported to GTK3. > -- Neil Williams h...@codehelp.co.uk pgpWDOPzl0BV1.pgp Description: OpenPGP digital signature
Bug#910566: ITP: pyocd -- ARM Cortex-M programming tools (Python3)
Package: wnpp Severity: wishlist Owner: Neil Williams * Package name: pyocd Version : 0.12.0+dfsg Upstream Author : ARM Limited * URL : https://github.com/mbedmicro/pyOCD * License : Apache-2.0 Programming Lang: Python Description : ARM Cortex-M programming tools (Python3) pyOCD is an Open Source python 2.7 based library for programming and debugging ARM Cortex-M microcontrollers using CMSIS-DAP. . Includes support for flashing new binaries, resetting the device, halt, step, resume read/write memory and set/remove breakpoints. pyocd can be used by LAVA to automate validation of IoT devices. Firmware binaries and gdb elf files have had to be removed from the package due to lack of source.
Bug#910565: ITP: intelhex -- Intel HEX microcontroller format support for Python
Package: wnpp Severity: wishlist Owner: Neil Williams * Package name: intelhex Version : 2.1 Upstream Author : 2005-2016 Alexander Belchenko * URL : https://github.com/bialix/intelhex * License : BSD Programming Lang: Python Description : Intel HEX microcontroller format support for Python The Intel HEX file format is widely used in the microprocessors and microcontrollers area as the de facto standard for code representation for microelectronic devices programming. . This package implements an intelhex Python library to read, write, create from scratch and manipulate data from HEX (also known as Intel HEX) file format. intelhex is a dependency for pyocd which is also to be packaged.
Bug#910564: ITP: mando -- command line argument parser for python
Package: wnpp Severity: wishlist Owner: Neil Williams * Package name: mando Version : 0.6.4 Upstream Author : 2013 Michele Lacchia * URL : https://github.com/rubik/mando * License : MIT Programming Lang: Python Description : command line argument parser for python Mando attempts to simplify command line argument parsing with multiple commands by using decorators to infer the boilerplate for argparse directly from the function declarations. mando is a dependency for radon (same author).
Bug#910563: ITP: radon -- Code metric generator for python
Package: wnpp Severity: wishlist Owner: Neil Williams * Package name: radon Version : 2.3.1 Upstream Author : 2012-2017 Michele Lacchia * URL : https://github.com/rubik/radon * License : BSD Programming Lang: Python Description : Code metric generator for python Radon is a Python tool which computes various code metrics. Supported metrics are: . raw metrics: SLOC, comment lines, blank lines, &c. Cyclomatic Complexity (i.e. McCabe’s Complexity) Halstead metrics (all of them) the Maintainability Index (a Visual Studio metric) . Radon can be used either from the command line or programmatically through its API.
Bug#909562: ITP: black -- uncompromising Python code formatter
Package: wnpp Severity: wishlist Owner: Neil Williams * Package name: black Version : 18.6b4 Upstream Author : Łukasz Langa * URL : https://github.com/ambv/black * License : BSD-3-Clause Programming Lang: Python Description : uncompromising Python code formatter Black is the uncompromising Python code formatter. By using it, you agree to cede control over minutiae of hand-formatting. In return, Black gives you speed, determinism, and freedom from pycodestyle nagging about formatting. You will save time and mental energy for more important matters. . Blackened code looks the same regardless of the project you're reading. Formatting becomes transparent after a while and you can focus on the content instead. . Black makes code review faster by producing the smallest diffs possible. We'd like to use black as part of code review for LAVA and associated python packages. I'm currently investigating if this should be maintained by the LAVA team or the Python Modules team. The package needs a small patch to remove privacy-breaching tracking URLs from the docs.
Bug#881419: O: json-schema-validator
Package: wnpp Severity: normal With the removal of the V1 code from lava-dispatcher and lava-server, I will no longer be using this package, so it should be orphaned. The package description is: This package provides a JSON Schema validator conforming to a subset of second draft of the specification. JSON files can be verified against a schema expressed in the python source code, producing either a SchemaError exception or ValidationError exception. However, other schema validators exist which are not tied to a specific text format, e.g. voluptuous.
Bug#871961: O: perl-cross-debian -- Cross build support for Debian perl configurations
Package: wnpp Severity: normal I intend to orphan the perl-cross-debian package. I'm not doing cross-building so much any more, I have enough devices to do native ARM builds. I don't have time to keep using this package. If the package is not adopted, say, by the end of 2017, it should be removed. The package description is: This package provides the configuration values for selected versions of perl. Each set is compatible with the Debian configuration of that version of perl, to circumvent the use of compiled test binaries which will fail during a cross-build. . Also provides a helper script to push the relevant configuration files into the cross-build using support in debian/rules within perl.
Bug#835909: O: multistrap -- multiple repository bootstrap based on apt
On Fri, 02 Dec 2016 23:21:10 +0100 Johannes Schauer wrote: > Hi Neil, > > On Sun, 28 Aug 2016 18:32:38 +0100 Neil Williams > wrote: > > I intend to orphan the multistrap package. > > does this mean that the "upstream" copy on github will also not be > maintained by you anymore and is now dead as well? Yes, upstream is dead as well. Feel free to fork it. > As the author of a multistrap wrapper script (which then became > brickstrap) I'm interested in picking up multistrap development. > > Are there any tools that depend on it and with which backwards > compatibility has to be maintained? There seem to be no > Depends/Recommends/Suggests on it within Debian. I'm not aware of any and nobody else has expressed any interest in multistrap since I orphaned it. I have no use case for multistrap any longer. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp_emFuGI_OH.pgp Description: OpenPGP digital signature
Bug#835925: Bug#840323: debhelper: cmake build system: cross compilation
On Tue, 11 Oct 2016 06:33:06 +0200 Helmut Grohne wrote: > Hi Holger, > > On Mon, Oct 10, 2016 at 09:30:35PM +, Holger Levsen wrote: > > this seems a fairly strong statement, considering > > https://tracker.debian.org/pkg/dpkg-cross shows not a single bug > > filed against the package. I could file 15 RC bugs against dpkg-cross for the flagrant disregard of ALL Debian Policy, if you really want proof of the abominations that hide within it. However, cross-config has none of those issues, so to allow cross-config to exist in Stretch I want to see the removal of the dpkg-cross and libdebian-dpkgcross-perl binary packages instead. These should have been removed from Debian before we released Lenny, let alone Jessie. Yay for the inertia of cross-building in Debian. cross-config exists solely to allow the removal of the dpkg-cross and libdebian-dpkgcross-perl binaries. Even then, the contents of cross-config could end up in other packages just as easily. To repeat: > | summary 771496 If anything you are doing would fail after the > removal of dpkg-cross, you're doing it wrong. It's going away, > whether you want it to or not. That does *not* apply to cross-config and the original bug made it clear that the configuration elements could remain. > Quoting Neil Williams in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771496#46: > | summary 771496 If anything you are doing would fail after the > removal of dpkg-cross, you're doing it wrong. It's going away, > whether you want it to or not. Wrong package for this bug report. The package you need for CMake and other *configuration* support for cross-building (not *packaging* support for cross-building) is cross-config. https://packages.debian.org/sid/all/cross-config/filelist /etc/dpkg-cross/cmake/CMakeCross.txt That's the only file needed for CMake - it could just as easily be migrated into another package. > There is a reason why dpkg-cross is not part of jessie. > > Wookey, should we add a blocker bug keep it out of jessie? Holger: did you mean Stretch? If so, then instead of blocker bugs, what we need is a new upload which only leaves the cross-config binary package. But then I'm tired of this particular fight, that's why I orphaned it. However, Stretch must not release with the dpkg-cross and libdebian-dpkgcross-perl binary packages. If the new upload doesn't happen by the end of November 2017, then (as agreed at DebConf16), I'll have to do it as a final QA upload, leaving only the cross-config binary package. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpCF8XEbQJNa.pgp Description: OpenPGP digital signature
Bug#835925: O: dpkg-cross -- tools for cross compiling Debian packages
Package: wnpp Severity: normal I intend to orphan the dpkg-cross package which itself should be removed once the final dependencies are fixed. The package description is: dpkg-cross is a tool for installing libraries and headers from packages which have not been converted for Multi-Arch to support cross compiling.
Bug#835924: O: emdebian-archive-keyring -- GnuPG archive keys for the emdebian repository
Package: wnpp Severity: normal I intend to orphan the emdebian-archive-keyring package as I no longer have access to the keyring. The package description is: Emdebian digitally signs its Release files. This package contains the archive key used by both Emdebian Crush and Emdebian Grip. . The key is also available via the Emdebian website and as a udeb for debian-installer support.
Bug#835909: O: multistrap -- multiple repository bootstrap based on apt
Package: wnpp Severity: normal I intend to orphan the multistrap package. The package description is: A debootstrap replacement with multiple repository support, using apt to handle all dependency issues and conflicts. . Multistrap includes support for native and foreign architecture bootstrap environments. Foreign bootstraps only need minimal configuration on the final device. Also supports cleaning up the generated bootstrap filesystem to remove downloaded packages and hooks to modify the files in the bootstrap filesystem after the packages have been unpacked but before being configured. . Unlike debootstrap, multistrap relies on working versions of dpkg and apt outside the final filesystem. If dpkg supports MultiArch, foreign architecture libraries can be installed, where available. . Multistrap supercedes emdebian-rootfs and replaces the previous support for preparing root filesystems for specific machines and variants. Multistrap includes the previous emdebian-rootfs support for customisation of package selection and of files created within the root filesystem.
Bug#835908: O: pybit
Package: wnpp Severity: normal I'm orphaning pybit. The common part of the description is: buildd toolkit based on message queues. pyBit uses message queues to create a distributed, cross-platform buildd toolkit using a collection of buildds, using source from various VCS clients. pyBit is intended to support rapidly evolving software collections and can support multiple VCS frontends and multiple build backends.
Bug#835907: O: gpdftext -- GTK+ text editor for ebook PDF files
Package: wnpp Severity: normal I intend to orphan the gpdftext package. The package description is: gpdftext opens a simple text-based PDF file, typically intended for reading on an ebook reader and loads the text into a text editor window, autoformatting the text for long lines and paragraph breaks. . gpdftext is useful when the downloaded PDF uses a small font or wastes a lot of space in the margins so that a plain text file would display in a more comfortable font. . gpdftext supports spell checking and editor font selection and can save ASCII content as PDF.
Bug#835906: O: deb-gview -- GNOME viewer for .deb package files and contents
Package: wnpp Severity: normal I intend to orphan the deb-gview package. The package description is: Displays Debian control information, devscript details and details of the files that would be installed (names, sizes and locations). Files within the package can be viewed within the package or externally. . Accepts package locations on the command line to support the 'open' command in various file managers, one window for each package. Packages do not need to be installed to be viewed. Opening a changes file opens a new window for each package specified in the changes file. . Individual package files or packages referenced in a changes file can be viewed from local or remote filesystems.
Bug#832976: ITP: python-schema -- schema validation in Python
On Sat, 30 Jul 2016 13:54:11 +0100 Ghislain Antony Vaillant wrote: > Package: wnpp > Severity: wishlist > Owner: Ghislain Antony Vaillant > > * Package name: python-schema > Version : 0.6.2 > Upstream Author : Vladimir Keleshev > * URL : https://github.com/keleshev/schema > * License : Expat > Programming Lang: Python > Description : schema validation in Python > > Long-Description: > Schema is a library for validating Python data structures, such as > those obtained from config-files, forms, external services or > command-line parsing, converted from JSON/YAML (or something else) to > Python data-types. > > This package will be co-maintained by the Debian Python Modules Team. Isn't this much the same as the existing python-voluptuous package? A quick look at the README doesn't show anything that voluptuous can't do. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpHc6nSB8hB3.pgp Description: OpenPGP digital signature
Bug#819330: ITP: maim -- maim takes screenshots of your desktop
On Sat, 26 Mar 2016 13:18:59 -0700 Patrick O'Doherty wrote: > Package: wnpp > Severity: wishlist > Owner: "Patrick O'Doherty" > > * Package name: maim > Version : 3.3.41 > Upstream Author : Dalton Nell > * URL : naelst...@gmail.com > * License : GPL-3+ > Programming Lang: C, C++ > Description : maim takes screenshots of your desktop > > maim (make image) takes screenshots of your desktop. It has options > to take only a region, and relies on slop to query for regions. maim > is supposed to be an improved scrot. There are a number of packages in Debian which already do exactly this. What is this package actually going to add over the current set? Each desktop already has a screenshot applet of it's own and screengrab exists as a crossplatform screenshot tool. Is it executable remotely? Does it have some extras not covered in the description? There needs to be something to make this worth having in Debian besides being another me-too vanity package. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpYJJmcwZb1Y.pgp Description: OpenPGP digital signature
Bug#818266: ITP: python-django-casclient -- CAS client library for Django, K-State's version
On Tue, 15 Mar 2016 10:27:21 +0100 Joost van Baal-Ilić wrote: > Package: wnpp > Severity: wishlist > > * Package name: python-django-casclient > * URL : https://pypi.python.org/pypi/django-cas-client/, > https://github.com/kstateome/django-cas > * License : MIT > Programming Lang: Python > Description : CAS client library for Django, K-State's version Please expand on CAS for those who are unfamiliar wit it - it took quite some searching to work out what this acronym means in this context. > Django-cas is a CAS client library for Django. It is K-State's > fork of the original and includes Edmund Crewe's proxy ticket > patch and several additional features as well as features merged > from KTHse's django-cas2. > > I'll work on the packaging using debian-python's git at Alioth, at > https://anonscm.debian.org/cgit/python-modules/packages/python-django-casclient > . > > Bye, > > Joost > > -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpzLAU4nkpkn.pgp Description: OpenPGP digital signature
Bug#804315: [Vmdebootstrap-devel] Bug#804315: Namespace issues
On Mon, 9 Nov 2015 11:18:32 +1100 "Michael ." wrote: > >There is no namespace issue, we are building on the existing > >live-config > and > >live-boot packages that are maintained and bringing these into > >Debian as native projects. If necessary, these will be forks, but > >I'm hoping that won't have to happen and that we can integrate these > >packages into Debian and continue development in a collaborative > >manner. > > Actually there is and I think any person who works in a legal capacity > would verify that. No, in the Debian project, no team has exclusive rights over package namespaces - filename conflicts are different. Namespacing should be consistent with the purpose of the package to avoid confusion. live-build-ng is the next generation of build tool for live images. The name is appropriate. > With regards to collaboration, considering this is the first many > people have heard of this it seems to me you have not gone out of > your way to integrate people who have been working on these packages > into your project. As I said in my previous response to the Debian > Live list (which btw last time someone used the word Debian in a > unofficial capacity (Debian-Mulitmedia) they were asked to stop I > haven't seen any requests like this to the Debian Live mailing list > as yet) it would have been good if "instead of starting a new project > the group from the new project would be much better off assisting > with an already well established project > > >live-build has been deprecated by debian-cd, and live-build-ng is > >replacing it. In a purely Debian context at least, live-build is > deprecated. > >live-build-ng is being developed in collaboration with debian-cd and > >D-I. > > Just out of interests sake can you provide proof of this? He just did. Iain speaks as part of the debian-cd team. The debian-cd team deprecated live-build and have been looking for a replacement since before the Jessie release. I made a set of changes which underpin that support at DebConf15. Iain developed the code based upon that to deliver the missing support which is required by the debian-cd team. Job done. Well done, Iain. > You seem to be very intractable. No discussion, no change of heart, Correct. What has happened here is that the debian-cd team have finally found a solution to the provision of necessary support which has been lacking from the debian-live project for an inordinate amount of time. > not willing to discuss anything with people like Daniel who have been > doing this for years. If there has been correspondence from any part > of Debian and the team who are working on Debian-Live that shows this > is not something new and out of the blue I'll be very surprised. It's taken long enough already. There is no point waiting when the code is now working. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp2zh1K5d_EM.pgp Description: OpenPGP digital signature
Bug#804315: [Vmdebootstrap-devel] Bug#804315: Namespace issues
On Mon, 9 Nov 2015 08:59:41 +0100 chals wrote: > On Mon, Nov 9, 2015 at 12:45 AM, Iain R. Learmonth > wrote: > > Hi, > > > > It is worth noting that live-build is not a Debian project, it is an > > external project that claims to be an official Debian project. This > > is something that needs to be fixed. > > > > There is no namespace issue, we are building on the existing > > live-config and live-boot packages that are maintained and bringing > > these into Debian as native projects. If necessary, these will be > > forks, but I'm hoping that won't have to happen and that we can > > integrate these packages into Debian and continue development in a > > collaborative manner. > > > > live-build has been deprecated by debian-cd, and live-build-ng is > > replacing it. In a purely Debian context at least, live-build is > > deprecated. live-build-ng is being developed in collaboration with > > debian-cd and D-I. > > > > I'm aware that I'm going to be upsetting people, but this has been > > a long time coming and I'm not going to spend time bikeshedding > > over naming. I would rather spend that time on integration of live > > image creation into official Debian infrastructure and building the > > best system for live image creation possible. > > Apologies for making it look like Iain was the only voice on this. I've been unwell this weekend and Steve has been busy with the miniDebConf and is now (presumably) catching up on the sleep he lost whilst organising it. > Hi, > > Reading what you say, and I beg your pardon before going on, I can > tell that you absolutely have no idea about what the debian live > project is or about its history. But well, I have to admit that if > what you say is true, then you have a point. I've been involved with debian-live before. I remember a meeting with the live team at a previous debconf (Argentina?) where one of my previous rootfs build tools [multistrap] was being considered for a role within live but we didn't find a good match. > You say "I'm aware that I'm going to be upsetting people, but this has > been a long time coming" > > Yes you are absolutely right, you are upsetting people, people like me > who have contributed to debian for years and spent hours of effort to > make things better. Sorry, but I'm assuming you don't mean that Iain, Steve or I haven't spent years contributing and uploading to Debian and years and years of effort to make Debian better. > "A long time coming"? Excuse me, but the first thing I've ever heard > in all these years is that you and I mean you (not the debian cd team, > who supposedly is responsible for this upheaval) It is the team. Steve has been asking me for this support in vmdebootstrap for months and months. Every time there is a release or a point release, I get more nagging because he has to struggle with fixing live-*. > shows up from out of > the blue claiming that you have the right to do as you please and > decide about the future of the debian live team. Iain is not on his own. This comes from the debian-cd team. Steve has been nagging me for vmdebootstrap support to replace live-build since about a week after vmdebootstrap arrived in Debian, certainly before the Jessie release. > This is, from my point of view, an act of dictatorship and with my > authority as a debian user and contributor for years I demand you step > down from your position and ask for forgiveness to the debian live > team for being so rude, impolite and not worthy of any more of my > priceless words and time. Not going to happen. Just what "authority" is a user meant to have? Those who do the work in Debian earn the right to make the decisions on how that work is done in Debian. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpMSNdMSk6ws.pgp Description: OpenPGP digital signature
Bug#804315: [Vmdebootstrap-devel] Namespace issues
On Sat, 07 Nov 2015 10:40:36 +0100 Daniel Baumann wrote: > Hi Ian, > > nice to see you're interested in live-* stuff. however, please > consider renaming this package (and also src:live-support), it > invades/hijacks the Debian Live namespace. There is an explicit reason for this. vmdebootstrap is being extended explicitly to provide support for a replacement for live-build. This work is happening within the debian-cd team to be able to solve the existing problems with live-build. These problems include reliability issues, lack of multiple architecture support and lack of UEFI support. vmdebootstrap has all of these, we do use support from live-boot and live-config as these are out of the scope for vmdebootstrap. It is also helpful that live-build-ng is written in python. > I'm sure you can come up with a suitable namespace on your own, e.g. > vmdebootstrap-live and vmdebootstrap-live-support or something like > that). The objective is that debian-cd builds official Debian Live images without using live-build, using vmdebootstrap live support and live-build-ng instead. This work began at Debconf15 and has been extended in the vmdebootstrap sprint at the miniDebConfUK. Iain demonstrated a working Live image with UEFI built using vmdebootstrap and the work is set to continue. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpklkc8rOCmQ.pgp Description: OpenPGP digital signature
Bug#790685: ITP: python-conditional -- conditionally enter a context manager
On Tue, 30 Jun 2015 17:35:46 -0400 Sandro Tosi wrote: > at work we use it, so why not package it properly instead of keeping a > private deb? If I had upstream code which needed this support, I'd just embed it into the project and update the copyright instead of having a package for 18 lines in the first place. It's very generic and trivial python, it just doesn't seem worth the overhead of adding the dependency to setup.py and pydist-overrides, ensuring that the package gets backported to jessie etc. likely to find that a bit down the road we'd need to extend it a little bit more which would be a lot easier to do with the code not being a package. I wouldn't have thought it would be worthwhile to put through NEW, to be honest. In fact, even if the package existed in Debian, I'd expect other projects to simply implement the functionality inside a larger class instead of doing an import anyway. It's not as if there's anything truly innovative in the code which would be identifiable as an embedded copy. It's a (trivial) snippet, albeit interesting. However, I've used larger code samples from stackoverflow as the basis for changes to fix bugs before now. I wouldn't be surprised to find something this small in the documentation of a larger package (like django). Embedding is a problem when the code is of an appreciable size or complexity - this code doesn't qualify on either count. Isn't there a library into which this can be included instead of wasting mirror space on the whole packaging overhead? (Listing in Packages.gz, Contents.gz, mirrors, packages.debian.org and /var/cache/apt/ etc.) Or just add it to a utils.py in the project which uses it? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpm3ChC3rbYL.pgp Description: OpenPGP digital signature
Bug#790685: ITP: python-conditional -- conditionally enter a context manager
On Tue, 30 Jun 2015 16:17:04 -0400 Sandro Tosi wrote: > Package: wnpp > Severity: wishlist > Owner: Sandro Tosi > > * Package name: python-conditional > Version : 1.1 > Upstream Author : Stefan H. Holek > * URL : https://github.com/stefanholek/conditional > * License : BSD > Programming Lang: Python > Description : conditionally enter a context manager > > The conditional context manager comes handy when you always want to > execute a with-block but only conditionally want to apply its context > manager. An entire package for just 18 lines of python? 3 of those lines are docstring. Even if a few packages import it, it doesn't really seem worth packaging separately. Just wondering. https://github.com/stefanholek/conditional/blob/master/conditional/conditional.py -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpPeCnLUuYSg.pgp Description: OpenPGP digital signature
Bug#784110: O: libxsettings-client
Package: wnpp Severity: normal The GPE dependencies have already been removed but I have no need to maintain this any longer, so orphaning whilst the reverse dependencies are still available. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150503082430.25443.9498.reportbug@sylvester.codehelp
Bug#784111: O: libxsettings
Package: wnpp Severity: normal I'm no longer maintaining or using GPE, so it is time to orphan libxsettings - there are still reverse dependencies, so someone may want to keep it. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150503082535.25603.15828.reportbug@sylvester.codehelp
Bug#783833: ITP: python-obitools -- set of programs specifically designed for analyzing NGS data in a DNA metabarcoding contex
On Thu, 30 Apr 2015 16:23:36 + olivier sallou wrote: > Le jeu. 30 avr. 2015 à 17:42, Scott Kitterman a > écrit : > > > On Thursday, April 30, 2015 05:13:03 PM Olivier Sallou wrote: > > > Package: wnpp > > > Severity: wishlist > > > Owner: Olivier Sallou > > > > > > * Package name: python-obitools > > > Version : 1.1.16 > > > Upstream Author : Eric Coissac > > > * URL : http://metabarcoding.org//obitools/ > > > * License : CeCILL-V2 > > > Programming Lang: Python > > > Description : set of programs specifically designed for > > > analyzing > > NGS > > > data in a DNA metabarcoding contex > > > > > > The OBITools package is a set of programs specifically designed > > > for analyzing NGS data in a DNA metabarcoding context, taking > > > into account taxonomic information. OBITools enrich the Unix > > > command line interface > > with > > > a set of new commands dedicated to NGS data processing. Most of > > > them > > have a > > > name starting with the obi prefix. They automatically recognize > > > the input file format amongst most of the standard sequence file > > > formats (i.e. > > fasta, > > > fastq, EMBL, and GenBank formats). Nevertheless, options are > > > available to enforce some format specificity such as the encoding > > > system used in fastq files for quality codes. Most of the basic > > > Unix commands have their OBITools equivalent (e.g. obihead vs > > > head, obitail vs tail, obigrep vs grep), which is convenient for > > > scientists familiar with Unix. The main difference between any > > > standard Unix command and its OBITools counterpart is that the > > > treatment unit is no longer the text line but the sequence > > > record. As a sequence record is more complex than a single text > > > line, the OBITools programs have many supplementary options > > > compared to their Unix equivalents. > > > > According to the trove information on pypi [1] this is python only, > > not python3. We were hoping to not increase the amount of python > > packages needing > > porting to python3. Have you discussed python3 plans with upstream? > > > > Nope, not yet. However, as I discussed with one guy of the team some > time ago, I do not think there is any plan to go to python3. > This is an academic tool, and very often, they only focus on getting > something working and base maintenance. > > I understand the need to plan python3 switch, however we cannot block > tools used by the community. Not every package used by the community needs to be in Debian, especially if it comes under the classification of "written once, lobbed over the wall and forgotten" in terms of upstream maintenance. "base" maintenance includes keeping the package up to date with dependencies and that means working to get this package clean for python3 in time for when other dependencies become available. That is not a small task and if upstream are actually unwilling or unable to commit to that, then there is no point having the package in Debian when the stated aim is to make a significant effort on python3 support for Stretch, extending that further in Buster. It's tempting to have a package in Debian and I've done this myself in the past [0] - it turns out to be a quite bad idea if the package needs to be removed from Debian after only a single stable release due to lack of maintenance. Learn from the mistakes of those around you and don't upload packages which have a "removal timebomb" already primed. Use a bespoke repository which is available to the people who actually use it - you may find that it is simpler to then only build the package against current stable as that is probably what users are actually running. [0] https://qa.debian.org/developer.php?login=codehelp - there are too many packages there which were a good idea at the time but which only survived for one stable release - the entire GPE suite was already dying when it got uploaded. Uploading to Debian can *sometimes* inject life into an upstream project but it can also be a case of flogging a dying horse. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpK8cKz490go.pgp Description: OpenPGP digital signature
Bug#779189: ITP: django-kvstore -- Extensible key-value store backend for Django
Package: wnpp Severity: wishlist Owner: Neil Williams * Package name: django-kvstore Version : 1.0-1 Upstream Author : 2010 Six Apart Ltd. * URL : https://pypi.python.org/pypi/django-kvstore * License : BSD Programming Lang: Python Description : Extensible key-value store backend for Django This module provides an abstraction layer for accessing a key-value storage within a Django application using Postgresql. . A dedicated table needs to be created and then this table can be specified as the KEY_VALUE_STORE_BACKEND. Only primary key lookup queries are supported but the dictionary returned can be processed as normal. Also adding a README.Debian: django-kvstore 1.0 == This package provides a postgres backend. Other backends are available upstream but are not actively maintained, including: googleappengine (Google AppEngine data store) sdb (Amazon SimpleDB) tokyotyrant (Tokyo Tyrant) redis (Redis) Some non-persistent stores are also provided, mainly for testing purposes: locmem memcached This package will be a dependency of new code being added to lava-server and maintained by the Debian LAVA team. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150225100642.8972.81129.reportbug@sylvester.codehelp
Bug#762949: ITP: obs-build -- scripts for building RPM/debian packages for multiple distributions
On Fri, 26 Sep 2014 14:19:24 +0100 Dimitri John Ledkov wrote: > Package: wnpp > Owner: Dimitri John Ledkov > Severity: wishlist > > * Package name: obs-build > Version : 20140918 > Upstream Author : Adrian Schröter > * URL or Web page : https://github.com/openSUSE/obs-build > * License : GPL-2+ > Description : scripts for building RPM/debian packages for > multiple distributions > > This package provides scripts for building RPM and debian packages in > contained environments for various build distributions. These tools > are use by Open Build Service workers and openSUSE distribution by > default. > > By default it claims very generic paths: > /usr/bin/build > /usr/lib/build > > I'm planning to keep those as per upstream, if however there are > strong objections I'd be happy to change those to obs-build. Any number of packages could have claimed /usr/bin/build by now, instead we have sbuild, debuild, pdebuild, make, dpkg-buildpackage, git-buildpackage and a host of others. I don't see that obs deserves to be the "one true build" which may be the impression given by an overly common binary name. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Bug#748583: ITP: get directories of configuration files -- get directories of configuration files
On Sun, 18 May 2014 18:29:39 +0200 Jonas Smedegaard wrote: > Package: wnpp > Severity: wishlist > Owner: Jonas Smedegaard > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > * Package name: get directories of configuration files Maybe reportbug needs to check for whitespace in proposed package names ... libfile-config-dir-perl ? libfile-configdir-perl ? > Version : 0.013 > Upstream Author : Jens Rehsack > * URL : https://metacpan.org/release/File-ConfigDir > * License : Artistic or GPL-1+ > Programming Lang: Perl > Description : get directories of configuration files > > File::ConfigDir is a helper for installing, reading and finding > configuration file locations. It's intended to work in every > supported Perl5 environment and will always try to Do The Right > Thing(tm). > > This module is needed (indirectly) by recent releases of > libmoox-options-perl. > > It will be maintained in the Debian Perl team. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Bug#747356: ITP: lava-server -- Linaro Automated Validation Architecture server
Package: wnpp Severity: wishlist Owner: Neil Williams * Package name: lava-server Version : 2014.05 Upstream Author : 2010-2013, Linaro Limited * URL : http://www.linaro.org/projects/test-validation/ * License : GPL, LGPL, AGPL Programming Lang: Python Description : Linaro Automated Validation Architecture server This source package builds several packages: lava-server: This package replaces lava-deployment-tool to provide the Apache and WSGI configuration and LAVA support files to run the validation server on the local Apache instance as a lava-server virtual host as well as the scheduler and dispatcher. . This package can be configured as the master scheduler or as a remote worker, although limitations in the remote worker design mean that an unused database will need to be installed. lava: Metapackage to bring in all LAVA components on a single machine. lava-dev: This package provides a helper script to build LAVA packages from local git working copies and support for running the LAVA unit tests. lava-server-doc: This package contains an offline copy of the LAVA Manual available within LAVA server. . The manual includes use cases and examples to help users write tests for LAVA. This package will be maintained by the Debian LAVA team . -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140507190049.4816.76425.reportbug@sylvester.codehelp
Bug#747355: ITP: lava-dispatcher -- Linaro Automated Validation Architecture dispatcher
Package: wnpp Severity: wishlist Owner: Neil Williams * Package name: lava-dispatcher Version : 2014.05 Upstream Author : 2010-2013, Linaro Limited * URL : http://www.linaro.org/projects/test-validation/ * License : GPL, LGPL Programming Lang: Python Description : Linaro Automated Validation Architecture dispatcher This package provides lava-dispatcher to dispatch LAVA jobs to configured devices. . A range of devices are supported for ARM and x86 architectures. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140507185527.4579.95092.reportbug@sylvester.codehelp
Bug#747353: ITP: lavapdu -- LAVA PDU client and daemon
Package: wnpp Severity: wishlist Owner: Neil Williams * Package name: lavapdu Version : 0.0.3 Upstream Author : Matthew Hart * URL : http://www.linaro.org/projects/test-validation/ * License : GPL Programming Lang: Python Description : LAVA PDU client and daemon LAVA (Linaro Automated Validation Architecture) supports a number of APC power distribution units which allow control over the power supply to individual devices. Operations are recorded in a postgres database for the runner daemon to process. . This package contains the daemons to control the PDU and a client which LAVA can use to ensure that devices get a hard reboot if a soft reboot fails. The client connects to the listen daemon on the host running lavapdu-daemon. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140507184958.4424.44306.reportbug@sylvester.codehelp
Bug#747351: ITP: lava-coordinator -- LAVA Coordinator daemon
Package: wnpp Severity: wishlist Owner: Neil Williams * Package name: lava-coordinator Version : 0.1.5 Upstream Author : 2010-2013, Linaro Limited * URL : http://www.linaro.org/projects/test-validation/ * License : GPL Programming Lang: Python Description : LAVA Coordinator daemon This package provides coordinator daemon to provide communication and synchronisation methods for test jobs running on multiple configured devices on instances of LAVA (Linaro Automated Validation Architecture). . One coordinator daemon can support more than one LAVA instance in a single lab. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140507184625.4203.71655.reportbug@sylvester.codehelp
Bug#747350: ITP: lava-tool -- command line utility for LAVA
Package: wnpp Severity: wishlist Owner: Neil Williams * Package name: lava-tool Version : 0.10 Upstream Author : 2010-2013, Linaro Limited * URL : http://www.linaro.org/projects/test-validation/ * License : LGPL Programming Lang: Python Description : command line utility for LAVA This package provides a user space connection to a LAVA (Linaro Automated Validation Architecture) instance for submitting test jobs or querying the instance for device and job status over XMLRPC. This package will be maintained by the Debian LAVA team -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140507183907.3664.32036.reportbug@sylvester.codehelp
Bug#746182: ITP: django-longerusername -- allow longer usernames in django
Package: wnpp Severity: wishlist Owner: Neil Williams * Package name: django-longerusername Version : 0.4-1 Upstream Author : Steven Skoczen * URL : https://pypi.python.org/pypi/longerusername * License : BSD Programming Lang: Python Description : allow longer usernames in django This package provides a migration and a monkeypatch to make the django auth.user username field accept longer usernames, instead of the arbitrarily short 30 characters. . It is designed to be a simple include-and-forget project that makes a little headache go away. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140427195100.8842.54848.reportbug@sylvester.codehelp
Bug#745627: ITP: django-testproject -- Django test project support
Package: wnpp Severity: wishlist Owner: Neil Williams * Package name: django-testproject Version : 0.1.2 Upstream Author : Zygmunt Krynicki * URL : https://pypi.python.org/pypi/django-testproject * License : LGPL Programming Lang: Python Description : Django test project support This package provides django test project support to make it easier to run application unit tests without testing other parts of django core. . Projects can use run_tests to specify which parts of the codebase listed in INSTALLED_APPLICATIONS will run unit tests. https://git.linaro.org/lava/django-testproject.git -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140423141820.8259.42555.reportbug@sylvester.codehelp
Bug#745440: ITP: django-testscenarios -- Django unit test scenarios support
Package: wnpp Severity: wishlist Owner: Neil Williams * Package name: django-testscenarios Version : 0.7.3 Upstream Author : Zygmunt Krynicki * URL : https://pypi.python.org/pypi/django-testscenarios * License : LGPL Programming Lang: Python Description : Django unit test scenarios support This package provides django test support for using testscenarios.TestCase together with django.tests.TestCase. Tests can be given scenarios which all share the django database setup methods. 0.7.3 includes changes to port to django1.6 and is due for release on pypi shortly. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140421185946.29182.17516.reportbug@sylvester.codehelp
Bug#744795: ITP: django-restricted-resource -- Django Base model for ownership and access control
Package: wnpp Severity: wishlist Owner: Neil Williams * Package name: django-restricted-resource Version : 2014.02 Upstream Author : Zygmunt Krynicki * URL : https://git.linaro.org/lava/django-restricted-resource.git * License : LGPL Programming Lang: Python Description : Django Base model for ownership and access control Restricted resources can have owners, users or groups of users, organised within the django admin interface. Resources can be public or private to allow an app to provide access control over model objects. A small django module to support a larger validation framework. Team maintenance within Linaro. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140414194903.31781.75675.reportbug@sylvester.codehelp
Bug#744308: ITP: json-schema-validator -- JSON schema validation utility
Package: wnpp Severity: wishlist Owner: Neil Williams * Package name: json-schema-validator Version : 2.3.1 Upstream Author : Zygmunt Krynicki * URL : https://github.com/zyga/json-schema-validator * License : LGPL-3.0 Programming Lang: Python Description : JSON schema validation utility This package provides a JSON Schema validator conforming to a subset of second draft of the specification. . JSON files can be verified against a schema expressed in the python source code, producing either a SchemaError exception or ValidationError exception. I'm using this package as a dependency of a validation architecture which is due for packaging later. The upstream author is one of the uploaders and will be seeking DM status in due course. Packaging to be maintained in github. https://github.com/codehelp/pkg-json-schema-validator -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140412201516.30529.80369.reportbug@sylvester.codehelp
Bug#732603: ITP: python-daemonize -- Python module for writing system daemons
On Thu, 19 Dec 2013 10:46:02 +0100 Mike Gabriel wrote: > Package: wnpp > Severity: wishlist > Owner: Mike Gabriel > > * Package name: python-daemonize > Version : 2.2.1 > Upstream Author : Ilya Otyutskiy > * URL : http://pypi.python.org/pypi/daemonize > * License : Expat > Programming Lang: Python > Description : Python module for writing system daemons How does this compare to python-daemon which already exists in Debian and which does the same job? -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Bug#726786: O: libtext-vfile-asdata-perl
Package: wnpp Severity: normal I'm orphaning libtext-vfile-asdata-perl as I no longer use it. I contacted the debian-perl team on 14th Oct 2013 about the package, hopefully someone there will pick it up. The package details are: libtext-vfile-asdata-perl - generic perl module to read and write vfile files Works with such as vCard (RFC 2426) and vCalendar (RFC 2445). The result of loading this data is a collection of objects which will grant you easy access to the properties. Then the module can write your objects back to a data file. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Bug#726785: O: libtext-vcard-perl
Package: wnpp Severity: normal I'm orphaning libtext-vcard-perl as I no longer use it. I contacted the debian-perl team on 14th Oct 2013 about the package, hopefully someone there will pick it up. The package details are: libtext-vcard-perl - parse, edit and create multiple vCards Text::vCard::Addressbook provides an API to reading / editing and creating multiple vCards. A vCard is an electronic business card. This package has been developed based on rfc2426. Many applications (Apple Address book, MS Outlook, Evolution etc) can export and import vCards. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Bug#726770: O: svn-buildpackage
Package: wnpp Severity: normal I'm using svn less and less and I've lost interest in maintaining svn-buildpackage. I've checked with Jan and he feels the same way. So I'm orphaning svn-buildpackage. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Bug#726769: O: tslib
Package: wnpp Severity: normal I'm no longer developing code for touchscreens, I have no remaining interest in maintaining tslib. I've checked with Hector, he doesn't want to maintain tslib any longer either. The GPE team itself is likely to disband and GPE itself removed from Debian later as GPE consists of leaf packages. As tslib has reverse dependencies, I'm orphaning it in the hope that it can find a new maintainer. -- Neil Williams = codeh...@debian.org signature.asc Description: PGP signature
Bug#711794: ITP: vmdebootstrap -- Bootstrap Debian into a (virtual machine) disk image
Package: wnpp Severity: wishlist Owner: Neil Williams * Package name: vmdebootstrap Version : 0.1.0 Upstream Author : Lars Wirzenius * URL : https://gitorious.org/vmdebootstrap * License : GPL3 Programming Lang: Python Description : Bootstrap Debian into a (virtual machine) disk image vmdebootstrap is a wrapper around debootstrap to install Debian into a disk image, which can be used with a virtual machine (such as KVM). -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpv7NMfNe3Q6.pgp Description: PGP signature
Bug#703507: ITP: re2 -- fast, safe C++ regular expression library
On Wed, 20 Mar 2013 14:59:32 +0100 Andrew Shadura wrote: > On 20 March 2013 13:38, Adam D. Barratt wrote: > > This appears to have been in the archive for a couple of years already - > > http://packages.qa.debian.org/r/re2.html > > I wonder why is it still in experimental. Maybe it's worth > re-uploading it to unstable? This may help explain why: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591935#5 -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpDBd8XRs1Nv.pgp Description: PGP signature
Bug#696511: ITP: kazoo -- higher level API to Apache Zookeeper for Python clients.
Package: wnpp Severity: wishlist Owner: Neil Williams * Package name: kazoo Version : 0.8.0 Upstream Author : Kazoo Team * URL : https://kazoo.readthedocs.org * License : Apache License 2.0 Programming Lang: Python Description : higher level API to Apache Zookeeper for Python clients. Kazoo features: * Support for gevent 0.13 and gevent 1.0b * Unified asynchronous API for use with greenlets or threads * Lock, Party, Election, and Partitioner recipe implementations (more implementations are in development) * Data and Children Watchers * Integrated testing helpers for Zookeeper clusters * Simplified Zookeeper connection state tracking * Pure-Python based implementation of the wire protocol, avoiding all the memory leaks, lacking features, and debugging madness of the C library Kazoo is heavily inspired by Netflix Curator simplifications and helpers. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121221232414.11779.46769.reportbug@farglehob
Bug#694749: ITP: GNU Health -- Electronic Medical Record and Hospital Information System
On Thu, 29 Nov 2012 21:26:56 +0100 Emilien Klein wrote: > Package: wnpp > Severity: wishlist > Owner: Emilien Klein > > * Package name: GNU Health The package name cannot have a space, you'd need to change the name to be something like tryton-health-record or emrhis or something. GNU isn't a particularly helpful prefix for something which is not actually related to gnu.org but is instead using GNU as an indicator of it being free software (presumably). If the software only works with Tryton, then it would be reasonable to have tryton in the package name. > Version : 1.6.4 > Upstream Author : Luis Falcon > * URL : http://health.gnu.org/ > * License : GPLv3+ > Programming Lang: Python (Tryton modules) > Description : Electronic Medical Record and Hospital Information System > > GNU Health is a multi-user, highly scalable, centralized Electronic > Medical Record (EMR) and Hospital Information System (HIS) for Tryton, > so doctors and institutions all over the world, independently of their > economic status, will benefit from a centralized, high quality, secure > and scalable system. > -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpc4FwN7HUKW.pgp Description: PGP signature
Bug#694326: ITP: perl-cross-debian -- Cross build support for Debian perl configurations
Package: wnpp Severity: wishlist Owner: Neil Williams * Package name: perl-cross-debian Version : 0.0.1 Upstream Author : Neil Williams * URL : https://github.com/codehelp/perl-cross-debian * License : GPL Programming Lang: Perl Description : Cross build support for Debian perl configurations This package provides the configuration values for selected versions of perl, compatible with the Debian configuration of that version of perl, to avoid detection of these values during a cross-build. . Also provides a helper script to push the relevant configuration files into the cross-build using support in debian/rules within perl. Notes for debian-devel readers: The homepage links to the initial ideas for this package on my blog and I'll add more as the package develops. This package requires some changes in perl upstream and in the Debian perl package - details of those changes will be finalised prior to upload of this package to experimental. The intent is that this package will have a strict dependency on the latest version of perl which is supports or any lower version so that the version of perl in Debian testing should always cross compile for the list of supported architectures. Initially, the only supported architectures in perl-cross-debian will be armel and armhf with expected support for arm64. Join the team to support other architectures. The cross-build support in this package is specific to the Debian configuration of the specific version of upstream perl on the supported architectures. All cross-builds need the full list of build-dependencies for perl installed plus a suitable cross-compiler (not currently in Debian) and cross-dependencies (likely via dpkg-cross until MultiArch can handle -dev packages cleanly). -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121125142907.1345.7345.reportbug@sylvester.codehelp
Bug#692894: ITP: plum -- plum is a command line tool used to interact with the U-Boot netconsole of any LaCie product
On Sat, 10 Nov 2012 15:52:44 +0100 Maxime Hadjinlian wrote: > >> * Package name: plum > > netconsole on many more products. The package name is far from being as > > specific as the package itself. General purpose names are (relatively) > > fine for general purpose programs. > Well, plum is an acronym for Python LaCie das U-Boot Milchkuh, I'm not > really good at giving names, if you have any idea, feel free to share. lucie-uboot lucie-uboot-netconsole IMHO python isn't that relevant but you could just py- into there somewhere. The point is that the name should reflect just how specific this package is to a single bootloader, a single method of that bootloader and a single set of products using that bootloader. A change of name should also involve retitling the ITP. > > The Description isn't suitable for a real package, it should at the > > very least refer to uboot and lacie. Whichever keyword doesn't get > > added to the package name needs to be in the short description. > The word U-Boot and LaCie are in the description already. > >> Description : plum is a command line tool used to interact with the > >> U-Boot netconsole of any LaCie product At 92 characters that is too far long for the *short* description and it repeats the (proposed) package name. http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis The short description should be of the order of 50 characters. http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#s6.5.3.2 -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpHVvbwO9jBI.pgp Description: PGP signature
Bug#692894: ITP: plum -- plum is a command line tool used to interact with the U-Boot netconsole of any LaCie product
On Sat, 10 Nov 2012 13:55:41 +0100 Maxime Hadjinlian wrote: > Package: wnpp > Severity: wishlist > Owner: Maxime Hadjinlian > > * Package name: plum > Version : 0.1 > Upstream Author : Maxime Hadjinlian > * URL : http://github.com/maximeh/plum > * License : BSD > Programming Lang: C++, Python, Shell Scripts > Description : plum is a command line tool used to interact with the > U-Boot netconsole of any LaCie product Couldn't the package use a name which is more clearly identified as related to either lacie or uboot? The more specific the package name the better, unless the package is going to gain support for the uboot netconsole on many more products. The package name is far from being as specific as the package itself. General purpose names are (relatively) fine for general purpose programs. The Description isn't suitable for a real package, it should at the very least refer to uboot and lacie. Whichever keyword doesn't get added to the package name needs to be in the short description. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpTpcyZLT9cp.pgp Description: PGP signature
Bug#692159: ITP: pybit -- integrated cross-platform buildd toolkit using queued messages
Package: wnpp Severity: wishlist Owner: Neil Williams * Package name: pybit Version : 0.1.0-1 Upstream Authors: Nick Davidson , Simon Haswell , Neil Williams , Nick Bane , James Bennet * URL : https://github.com/nicholasdavidson/pybit * License : GPL2+ Programming Lang: Python Description : cross-platform buildd toolkit based on message queues pyBit uses AMQP to create a distributed, cross-platform buildd toolkit to build packages using a collection of buildds, direct from various VCS clients. pyBit is intended to support rapidly evolving software collections and can support multiple VCS frontends and multiple build backends. Cross building is expected to be supported for some backends. The initial backend uses dpkg for Debian. pyBit includes support for cancelling selected builds and using multiple buildd clients per architecture, per platform and per suite. Hooks are in development for subversion and git, other VCS hooks can be added. A RESTful web API provides live build reports and can generate build jobs for specific packages using particular VCS branches on selected architectures to support re-building packages at any point in the development process. Build history is stored using postgresql. Initial packages: pybit-svn - svn post-commit hook pybit-client - buildd client (uses sbuild for Debian) pybit-web - RESTful web API and report engine pybit-common - common python code for each package. Current dependencies: rabbitmq-server, python-requests, python-psycopg2 (>= 2.4.2-1~), python-amqplib, python-debian, python-jsonpickle. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121102192010.30232.93291.reportbug@sylvester.codehelp
Bug#688046: ITP: out -- utility for producing UTF-8 output to standard streams and terminal.
On Tue, 18 Sep 2012 11:00:46 +0100 "James" wrote: > Package: wnpp > Severity: wishlist > Owner: James Hunt > > * Package name: out Terrible choice of name - utf8-out ? > Command-line tool that can produce UTF-8 (Unicode) strings in various ways and > direct them to standard output, standard error or direct to the terminal > without the need for shell support. Strings can be repeated, delayed, > randomly-generated, written to arbitrary file descriptors, interspersed with > other characters and generated using ranges. Printf(1)-style escape > sequences are supported along with extended escape sequences. > > This utility sits somewhere between echo(1) and printf(1) in > functionality with a dash of seq(1) thrown in. If that's true, why hasn't this been included into shells already? Struggling to see a use-case for it, TBH, which doesn't help with an alternative name and may indicate that the long description doesn't really describe why it would be useful. Is this just for test suites? What needs this utility? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpOU9fMZuvWL.pgp Description: PGP signature
Bug#687001: ITP: optional-dev -- fake (empty) dev package
On Sat, 8 Sep 2012 22:01:17 +1000 Dmitry Smirnov wrote: > On Sat, 8 Sep 2012 19:37:33 Holger Levsen wrote: > > "optional depends" - what?? Thats self contradictory. If a depends it's > > really optional, it's not a depends, thus that package is buggy and should > > not be fixed by introducing a nonsense package, but by removing this > > depends. > > Imagine a software that builds without a certain -dev package. When present > this package may be used to activate an additional (optional) feature. Builds need to be reproducible so that when there needs to be an NMU it does not rebuild with different options merely because something extra has been installed. DEB_BUILD_OPTIONS exists for that support. Conditional builds are a bad idea. Specify the functionality for each arch and ensure that a later build does not change the functionality. This is where auto-detection in ./configure is also a bad idea - packages should ensure that dependencies which are auto detected are always available where supported via Build-Depends and [$arch], even using Build-Conflicts if necessary. > When building for as many architectures as we have, situation when some > dependencies are missing (or can't exist) on some architectures is not rare. So specify that using the existing !$arch support. > However we still want to build our packages with all features possible. ... but not surprise everyone when a simple binNMU for some other reason results in a change of dependencies. > The latter will make maintenance easier and may also be helpful for > backporting or even for distributions who borrow our packages but may not > have > all their build-dependencies. Maintenance is not easier if builds at a later date give a completely different package. "Optional build-dependencies" are best supported via DEB_BUILD_OPTIONS so that if the same options are always given, the build always prepares the same package whatever else is installed on the system in question. That is the only way to ensure that someone can safely do an NMU on the package months after the last maintainer upload. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpeLbtnNB9CK.pgp Description: PGP signature
Bug#686664: ITP: dochelp -- utility to browse doc-base registered documents
On Tue, 04 Sep 2012 14:06:51 +0200 Mehdi Dogguy wrote: > Package: wnpp > Severity: wishlist > Owner: Mehdi Dogguy > > * Package name: dochelp > Version : 0.1 > Upstream Author : Mehdi Dogguy > * URL : http://git.debian.org/?p=users/mehdi/dochelp.git > * License : GPL-3+ > Programming Lang: OCaml, Javascript > Description : utility to browse doc-base registered documents > > This package contains an utility to browse documentation installed on > a Debian system. The utility has a command-line interface and can be > used to search, open and display information of doc-base registered > documents. It also generates an HTML catalog of the available documents > each time a package registers a new one. > > Note that the project URL is temporary. The final one (that will appear > in the package) should be http://dochelp.debian.net. How does this differ from dwww and devhelp? Is it related to manpages.debian.net? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpP0CWlWeYad.pgp Description: PGP signature
Bug#686222: O: ted -- lightweight .DOC editor
On Thu, 30 Aug 2012 01:28:39 -0500 Ztatik Light wrote: > Subject: ITP: ted -- lightweight .DOC editor There is also another package requesting the name ted - #605503. The package should be renamed to something more unique. Your message didn't successfully change the title of the bug - please see bugs.debian.org for details on how to do that *if* it is your intention to do all the Debian packaging work for this package. > Package: wnpp > Version: 2.22; reported 2012-01-04 > Severity: wishlist > > * Package name : ted > Version : 2.22 > Upstream Author : Mark de Does > * URL : http://nllgg.nl/Ted/ > * License : GPL > Description : lightweight .DOC editor > > This was included in previous versions of Debian, but removed, *I believe*, > for the reason that it was thought to be unmaintained... http://packages.qa.debian.org/t/ted.html #502776 gives the reasons for removal. The previous maintainer requested removal. > Please remove "ted": > > * Unmaintained upstream. > > * DSFG problems - the upstream maintainer has added additional restrictions >on top of the GPL which are extremely unlikely to be resolved. The full >details are in #501638. This bug is lenny RC. > > * GTK frontend missing due to inability to build. The problems described in #501638 would mean that the package would not be allowed back into Debian unless fixed. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp45HHlX6I81.pgp Description: PGP signature
Bug#685042: ITP: libpam-ssh -- Authenticate using SSH keys
On Thu, 16 Aug 2012 03:01:33 +0200 Jerome Benoit wrote: > Package: wnpp > Severity: wishlist > Owner: Jerome Benoit > > * Package name: libpam-ssh > Version : 1.97 > Upstream Author : Akorty Rosenauer > * URL : http://pam-ssh.sourceforge.net/ > * License : BSD > Programming Lang: C > Description : Authenticate using SSH keys > > This PAM module provides single sign-on behavior for SSH. > The user types an SSH passphrase when logging in and is > authenticated if the passphrase successfully decrypts the > user's SSH private key. In the PAM session phase, an ssh-agent > process is started and keys are added. For the entire session, > the user can SSH to other hosts that accept key authentication > without typing any passwords. Is this about using removable media to store the SSH private key to login to machines which only have the public key? That would be useful (but isn't that covered by existing PAM support?) Is this some form of hot-desking support? If not, why is this better than a user having a different password for login and for the SSH key? Why tie login to one of my SSH private keys? The homepage doesn't make this clear, it sounds like the module just maps the user login via a graphical desktop manager to a particular SSH key the private key for which has to live on the system behind the login anyway. What's the point? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpQWPIsobSOV.pgp Description: PGP signature
Bug#682496: ITP: melange -- Melange Widget System for the Cream Desktop Environment
On Mon, 23 Jul 2012 13:31:09 +0200 Mike Gabriel wrote: > Package: wnpp > Severity: wishlist > Owner: Mike Gabriel > > * Package name: melange What, if any, is the relationship between this and melange used for the Google Summer of Code? http://code.google.com/p/soc/ Maybe cream-melange for clarity? > Version : 0.4.9 > Upstream Author : Sebastian Billaudelle > * URL : http://cream-project.org > * License : LGPL-2.1+ > Programming Lang: Python > Description : Melange Widget System for the Cream Desktop Environment > > The Melange widget system provides an easy to use API for creating widgets > for the Cream Desktop Environment. Creating Melange widgets is very simple. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpR5Ozr4QH2h.pgp Description: PGP signature
