Re: Bug#1073496: ITP: requests-mock -- Python module to stub HTTP requests in testing code
On Sun, Jun 16, 2024 at 05:20:37PM +0200, Bastian Blank wrote: > On Sun, Jun 16, 2024 at 03:43:38PM +0100, Julian Gilbey wrote: > > * Package name: requests-mock > > Version : 1.12.1 > > Upstream Author : Jamie Lennox > > * URL : https://github.com/jamielennox/requests-mock > > * License : Apache-2.0 > > Programming Lang: Python > > Description : Python module to stub HTTP requests in testing code > > This module creates a custom adapter that allows one to predefine responses > > when certain URIs are called when using the `requests` module. > > Is this something different then the already exising > python-requests-mock? Oh, oops - I somehow missed that. Closing this ITP then. Julian
Bug#1073496: ITP: requests-mock -- Python module to stub HTTP requests in testing code
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: requests-mock Version : 1.12.1 Upstream Author : Jamie Lennox * URL : https://github.com/jamielennox/requests-mock * License : Apache-2.0 Programming Lang: Python Description : Python module to stub HTTP requests in testing code This module creates a custom adapter that allows one to predefine responses when certain URIs are called when using the `requests` module. This package is a (recursive) dependency of the new version of jupyter-notebook (including its testsuite and docs). It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/requests-mock
Bug#1073495: ITP: pathable -- Python module to traverse and access resources like paths
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pathable Version : 0.4.3 Upstream Author : Copyright: Artur Maciag * URL : https://github.com/p1c2u/pathable * License : Apache-2.0 Programming Lang: Python Description : Python module to traverse and access resources like paths This module provides a class DictPath to turn a dictionary into a path-like structure, allowing one to traverse them in a similar way to using pathlib. This package is a (recursive) dependency of the new version of jupyter-notebook (including its testsuite and docs). It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/pathable
Bug#1073494: ITP: openapi-schema-validator -- Validate schema against the OpenAPI Schema Specifications
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: openapi-schema-validator Version : 0.6.2 Upstream Author : Artur Maciag * URL : https://github.com/python-openapi/openapi-schema-validator * License : BSD-3-clause Programming Lang: Python Description : Validate schema against the OpenAPI Schema Specifications This Python module validates schema against the OpenAPI Schema Specification version 3.0 or 3.1. This package is a (recursive) dependency of the new version of jupyter-notebook (including its testsuite and docs). It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/pathable
Bug#1073493: ITP: openapi-core -- Client- and server-side support for OpenAPI specification
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: openapi-core Version : 0.19.1 Upstream Author : Artur Maciag * URL : https://github.com/python-openapi/openapi-core * License : BSD-3-clause Programming Lang: Python Description : Client- and server-side support for OpenAPI specification This Python library adds client-side and server-side support for the OpenAPI v3.0 and v3.1 specification. It offers: . * validation and unmarshalling of request and response data (including webhooks) * integration with popular libraries (Requests and Werkzeug) and frameworks (Django, Falcon, Flask, Starlette) * customization with media type deserializers and format unmarshallers * security data providers (API keys, Cookie, Basic and Bearer HTTP authentications) This package is a (recursive) dependency of the new version of jupyter-notebook (including its testsuite and docs). It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/openapi-core
Bug#1073492: ITP: jsonschema-path -- Python module for object-oriented JSONSchema
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: jsonschema-path Version : 0.3.2 Upstream Author : Artur Maciag * URL : https://github.com/p1c2u/jsonschema-path * License : Apache-2.0 Programming Lang: Python Description : Python module for object-oriented JSONSchema This module provides a class SchemaPath to turn JSON Schema into path-like structures, allowing one to traverse them in a similar way to using pathlib. This package is a (recursive) dependency of the new version of jupyter-notebook (including its testsuite and docs). It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/jsonschema-path
Bug#1073491: ITP: autodoc-traits -- Sphinx extension to document classes with Traitlets-based config
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: autodoc-traits Version : 1.2.2 Upstream Author : Copyright: Project Jupyter Contributors, all rights reserved * URL : https://github.com/jupyterhub/autodoc-traits * License : BSD-3-clause Programming Lang: Python Description : Sphinx extension to document classes with Traitlets-based config This is a Sphinx extension that builds on sphinx.ext.autodoc to better document classes with Traitlets-based configuration. It provides Sphinx directives `autoconfigurable` (use with classes) and `autotrait` (use with the traitlets based configuration options), yielding documentation that takes account of Traitlets. This package is a (recursive) dependency of the new version of jupyter-notebook (including its testsuite and docs). It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/autodoc-traits
Bug#1073490: ITP: aioitertools -- Python itertools, builtins and more for AsyncIO
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: aioitertools Version : 0.11.0 Upstream Author : Amethyst Reese * URL : https://github.com/omnilib/aioitertools * License : Expat Programming Lang: Python Description : Python itertools, builtins and more for AsyncIO This Python module shadows the standard library whenever possible to provide asynchronous versions of itertools, builtins and other familiar functions. It's fully compatible with standard iterators and async iterators alike, providing a single unified, familiar interface for interacting with iterable objects. This package is a (recursive) dependency of the new version of jupyter-notebook (including its testsuite and docs). It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/aioitertools
Bug#1070452: ITP: pytest-lazy-fixtures -- pytest plugin to use fixtures in @pytest.mark.parametrize
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org, 1063...@bugs.debian.org * Package name: pytest-lazy-fixtures Version : 1.0.7 Upstream Contact: Petrov Anton * URL : https://github.com/dev-petrov/pytest-lazy-fixtures * License : Expat Programming Lang: Python Description : pytest plugin to use fixtures in @pytest.mark.parametrize This plugin was inspired by pytest-lazy-fixture; that plugin is incompatible with pytest 8.x, so this can be used as a replacement. . Improvements that have been made in this project: . * You can use fixtures in any data structures * You can access the attributes of fixtures * You can use functions in fixtures This will allow those packages using pytest-lazy-fixture (which is now unusable in debian/testing) in their tests to migrate to this maintained alternative. (See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063957) It will be maintained within the Debian Python Team, and I will be listed as an Uploader.
Bug#1068557: ITP: sphinxcontrib-openapi -- Sphinx extension to generate API docs from OpenAPI spec
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: sphinxcontrib-openapi Version : 0.8.4 Upstream Author : Ihor Kalnytskyi * URL : https://github.com/sphinx-contrib/openapi * License : BSD-2-clause Programming Lang: Python Description : Sphinx extension to generate API docs from OpenAPI spec This extension generates API documentation for reStructuredText documentation using the Sphinx system. It also depends on `sphinxcontrib.httpdomain` that provides an HTTP domain for describing RESTful HTTP APIs. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/sphinxcontrib-openapi
Bug#1068556: ITP: sphinxcontrib-emojicodes -- Sphinx extension to use emoji codes in Sphinx documentation
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: sphinxcontrib-emojicodes Version : 0.3.1 Upstream Author : Copyright: The Sphinx Emoji Codes contributors * URL : https://github.com/sphinx-contrib/emojicodes * License : BSD-3-clause Programming Lang: Python Description : Sphinx extension to use emoji codes in Sphinx documentation This extension allows one to write things like |:smile:| in Sphinx documentation. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/sphinxcontrib-emojicodes
Bug#1068555: ITP: rfc3986-validator -- RFC 3986 validator (Python library)
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: rfc3986-validator Version : 0.1.1 Upstream Author : Nicolas Aimetti * URL : https://github.com/naimetti/rfc3986-validator * License : Expat Programming Lang: Python Description : RFC 3986 validator (Python library) This package provides a validator for URIs to determine whether they conform to the Internet Engineering Task Force (IETF) specification (RFC 3986). This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/rfc3986-validator
Bug#1068554: ITP: rfc3339-validator -- RFC 3339 validator (Python library)
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: rfc3339-validator Version : 0.1.4 Upstream Author : Nicolas Aimetti * URL : https://github.com/naimetti/rfc3339-validator * License : Expat Programming Lang: Python Description : RFC 3339 validator (Python library) This package provides a validator for date-time strings to determine whether they conform to the Internet Engineering Task Force (IETF) Internet Date/Time Format (RFC 3339). This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/rfc3339-validator
Bug#1068553: ITP: python-overrides -- Python decorator to verify that expected overrides are maintained
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-overrides Version : 7.7.0 Upstream Author : Copyright: Mikko Korpela * URL : https://github.com/mkorpela/overrides * License : Apache-2.0 Programming Lang: Python Description : Python decorator to verify that expected overrides are maintained Provides a decorator @override that verifies that a method that should override an inherited method actually does it. Python has no standard mechanism by which to guarantee that (1) a method that previously overrode an inherited method continues to do so, and (2) a method that previously did not override an inherited will not override now. This package allows this to be addressed in an automated manner. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/python-overrides
Bug#1068552: ITP: python-isoduration -- Operations with ISO 8601 durations (Python 3 package)
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-isoduration Version : 20.11.0+git20211126.ae0bd61 Upstream Author : Víctor Muñoz * URL : https://github.com/bolsote/isoduration * License : ISC Programming Lang: Python Description : Operations with ISO 8601 durations (Python 3 package) ISO 8601 supports time durations in string format, for example "P3Y6M4DT12H30M5S" represents a duration of 3 years, 6 months, 4 days, 12 hours, 30 minutes, and 5 seconds. This package supports working with such durations, addressing the shortcomings of the isodate package. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/python-isoduration
Bug#1068551: ITP: python-fqdn -- Python library to validate fully qualified domain names (FQDNs)
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-fqdn Version : 1.5.1 Upstream Author : ypcrts * URL : https://github.com/ypcrts/fqdn * License : MPL-2.0 Programming Lang: Python Description : Python library to validate fully qualified domain names (FQDNs) This package validates FQDNs conforming to the Internet Engineering Task Force (IETF) specification (RFC 1123 in particular). The design intent is to validate that a string would be traditionally acceptable as a public Internet hostname to RFC-conforming software. Configuration options can be used to obtain more relaxed checks. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/python-fqdn
Bug#1068550: ITP: pytest-mypy-testing -- Plugin to test mypy output with pytest
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pytest-mypy-testing Version : 0.1.3 Upstream Author : Copyright: David Fritzsche * URL : https://github.com/davidfritzsche/pytest-mypy-testing * License : CC0-1.0 Programming Lang: Python Description : Plugin to test mypy output with pytest This plugin provides a way to test that mypy produces a given output. As mypy can be told to display the type of an expression, this allows one to check mypy's type interference. This package is a test-time dependency of the new version of traitlets; the current version in unstable has the relevant tests ignored at present, but it would be good to be able to include these tests in the autopkgtest suite. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/pytest-mypy-testing
Bug#1068548: ITP: picobox -- Opinionated Python dependency injection framework
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: picobox Version : 4.0.0 Upstream Author : Ihor Kalnytskyi * URL : https://github.com/ikalnytskyi/picobox * License : Expat Programming Lang: Python Description : Opinionated Python dependency injection framework Picobox is designed to be clean, pragmatic and with Python in mind. No complex graphs, no implicit injections, no type bindings - just picoboxes and explicit demands. . It is a small, thread-safe, pure Python library with no dependencies. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/picobox
Bug#1068549: ITP: pytest-console-scripts -- Pytest plugin for running Python scripts from within tests
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pytest-console-scripts Version : 1.4.1 Upstream Author : Vasily Kuznetsov * URL : https://github.com/kvas-it/pytest-console-scripts * License : Expat Programming Lang: Python Description : Pytest plugin for running Python scripts from within tests This plugin is quite similar to `subprocess.run()`, but it also has an in-process mode, where the scripts are executed by the interpreter that's running `pytest` (using some amount of sandboxing). . In-process mode significantly reduces the run time of the test suites that run many external scripts. This is speeds up development. In a CI environment subprocess mode can be used to make sure the scripts also work (and behave the same) when run by a fresh interpreter. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/pytest-console-scripts
Bug#1068547: ITP: jupyter-server-terminals -- Jupyter server extension providing support for terminals
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: jupyter-server-terminals Version : 0.5.3 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyter-server/jupyter_server_terminals * License : BSD-3-clause Programming Lang: Python Description : Jupyter server extension providing support for terminals This package allows Jupyter servers to interface to terminals via Tornado websockets. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/jupyter-server-terminals
Bug#1068546: ITP: async-asgi-testclient -- Python async client for testing ASGI web applications
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: async-asgi-testclient Version : 1.4.11 Upstream Author : Jordi Masip * URL : https://github.com/vinissimus/async-asgi-testclient * License : Expat Programming Lang: Python Description : Python async client for testing ASGI web applications This library is used for testing ASGI (Asynchronous Server Gateway Interface) applications. It is designed to be a common testing library for such applications that does not depend on the specific web framework being used. . It works by calling the ASGI app directly rather than via a web server. This package is a (recursive) dependency of the new version of jupyter-server. (More precisely, it is a test-time dependency of a currently unreleased version of picobox.) It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/async-asgi-testclient
Re: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
Hi Diane, On Sat, Mar 30, 2024 at 08:59:39PM -0700, Diane Trout wrote: > Hi Julian, > > On Sat, 2024-03-30 at 20:22 +0000, Julian Gilbey wrote: > > Lovely to hear from you, and oh wow, that's amazing, thank you! > > > > I can't speak for anyone else, but I suggest that pushing your > > updates > > to the science-team package would be very sensible; it would be silly > > for someone else to have to redo your work. > > > > What more is needed for it to be ready for unstable? > > > The things I think are kind of broken are: > > We've got 7.0.0 and upstreams current version is 15.0.2. Yes, that does seem a little less than ideal! > the pyarrow 7.0.0 tests fail because it depends on a python test > library that breaks with pytest 8.0. Either I need to disable the > python tests or upgrade to a newer version. It may well be that newer versions would work with pytest 8.x. I don't think it's worth spending time trying to patch such a relatively old version. > My upgrade didn't go smoothly because uscan found also upstreams debian > watch file which is too loose and matches some other tar balls on their > distribution site. > > (Though I don't know why uscan keeps looking for watch files after > finding one in debian/watch) Oh dear. uscan(1) does say: Unless --watchfile is given, uscan looks recursively for valid source trees starting from the current directory (see the below section "Directory name checking" for details). and then: For each valid source tree found, typically the following happens: [...] so yes, it will look at more than one location. > And you were probably right in that arrow needs to be a team, because I > have no idea how to get other the other languages interfaces packaged. I suggest that without anyone else volunteering to do those other language interfaces (perhaps it's not a pressing need for people working with language X), I wonder whether it's worth just packaging the Python (and presumably C++) interfaces for now, and then if others want to join the effort to support language X later on, a new version of the Debian package can be uploaded with a new binary package for language X. It does mean more trips through the NEW queue if and when that happens, but given that no-one's shown interest in language X for the last several years, this is unlikely to be much of an issue. Version 7.0 provided support (it seems) for: GLib (seems that a draft framework for building this is already in the Debian package, and it can then be used in lots of languages), C++ (this is the core libraries), C# (not of interest to us), Go, Java, JavaScript, Julia, Matlab (not of interest to us), Python, R, Ruby. > Oh and I probably need to get the pyarrow installed somewhere, since it > was stopping at the tests I hadn't run into dh_missing errors yet. Oh. Would pybuild do that automatically (perhaps specifying PYBUILD_PACKAGE)? Best wishes, Julian
Some t64 libraries already in testing; I'm confused
My very limited understanding of this major transition was that the t64 libraries are being held in unstable until (almost) everything is ready, at which point there will be a coordinated migration into testing. But I've now been asked to upgrade something on my testing machine which pulls in a t64 library. Has something slipped through the net, or is this intentional? Looking through testing, I see the following t64 libraries present: libaio1t64 libfyba0t64 libglibmm-2.68-1t64 libnetcdf19t64 libudns0t64 libczmq4t64 (virtual package; libczmq4 provides this) Best wishes, Julian
Re: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
Hi Diane, On Fri, Mar 29, 2024 at 11:49:07AM -0700, Diane Trout wrote: > On Mon, 2024-03-25 at 18:17 +0000, Julian Gilbey wrote: > > > > > > So this is a plea for anyone looking for something really helpful to > > do: it would be great to have a group of developers finally package > > this! There was some initial work done (see the RFP bug report for > > details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021), > > but that is fairly old now. As Apache Arrow supports numerous > > languages, it may well benefit from having a group of developers with > > different areas of expertise to build it. (Or perhaps it would make > > more sense to split the upstream source into a collection of > > different > > Debian source packages for the different supported languages. I > > don't > > know.) Unfortunately I don't have the capacity to devote any time to > > it myself. > > > > Thanks in advance for anyone who can step forward for this! > > I've been maintain dask and anndata and saw that apache arrow was > getting increasingly popular. > > I took the current science-team preliminary packaging 7.0.0 packaging > and managed to get it to build through a combination of patches and > turning off features. > > I even mostly managed to get pyarrow to build. (Though some tests fail > due to pytest lazy-fixture being abandoned). > > I pushed my current work in progress to. > > https://salsa.debian.org/diane/arrow.git > > Was anyone else planning on working on it or should I push my updates > to the science-team package? Lovely to hear from you, and oh wow, that's amazing, thank you! I can't speak for anyone else, but I suggest that pushing your updates to the science-team package would be very sensible; it would be silly for someone else to have to redo your work. What more is needed for it to be ready for unstable? Best wishes, Julian
Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
Hi all, [NB: sent to d-science, d-python, d-devel and the RFP bug; reply-to set to d-science and the RFP bug only] An update on Apache Arrow, and in particular the Python library PyArrow. For those who don't know: Apache Arrow is a development platform for in-memory analytics. It contains a set of technologies that enable big data systems to process and move data fast. It specifies a standardized language-independent columnar memory format for flat and hierarchical data, organized for efficient analytic operations on modern hardware. The project is developing a multi-language collection of libraries for solving systems problems related to in-memory analytical data processing. This includes such topics as: * Zero-copy shared memory and RPC-based data movement * Reading and writing file formats (like CSV, Apache ORC, and Apache Parquet) * In-memory analytics and query processing (from: https://arrow.apache.org/docs/index.html) Pandas has announced that Pandas 3.x will depend on PyArrow in a critical way (it will back the "string" datatype), and it is due to be released imminently. So this is a plea for anyone looking for something really helpful to do: it would be great to have a group of developers finally package this! There was some initial work done (see the RFP bug report for details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021), but that is fairly old now. As Apache Arrow supports numerous languages, it may well benefit from having a group of developers with different areas of expertise to build it. (Or perhaps it would make more sense to split the upstream source into a collection of different Debian source packages for the different supported languages. I don't know.) Unfortunately I don't have the capacity to devote any time to it myself. Thanks in advance for anyone who can step forward for this! Best wishes, Julian
Bug#1067248: ITP: pytest-jupyter -- Pytest plugins for Jupyter libraries and extensions
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pytest-jupyter Version : 0.9.1 * URL : https://github.com/jupyter-server/pytest-jupyter * License : BSD-3-clause and Expat Programming Lang: Python Description : Pytest plugins for Jupyter libraries and extensions This set of pytest plugins are used for testing Jupyter. It includes an echo kernel to speed up testing. It uses pytest-tornasync internally for async test suite running, and may not be compatible with pytest-asyncio. This package is a new requirement for the package tests for jupyter-client and jupyter-server (newer versions of these packages that have not yet been packaged). It will be maintained within the Debian Python Team.
Bug#1064473: ITP: taskflow -- Parallel and Heterogeneous Task Programming System for C++
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: taskflow Version : 3.6.0+git20240218.9616467 Upstream Contact: Dr. Tsung-Wei Huang * URL : https://taskflow.github.io/ * License : Expat Programming Lang: C++ Description : Parallel and Heterogeneous Task Programming System for C++ Taskflow helps you quickly write parallel and heterogeneous task programs with high performance and simultaneous high productivity. It is faster, more expressive, with fewer lines of code, and easier for drop-in integration than many of existing task programming libraries. It is provided as a collecion of C++ header files, using C++17. This package is a dependency of rapidfuzz, which is a C++ and Python library for rapid string distance calculations. In turn, rapidfuzz is a dependency of newer versions of other Python packages. It is also a great package in itself, providing a library that can be used to great effect, as described in several papers and conference presentations. I don't think it fits within the Debian Python Team's remit, yet it is needed by them. So my proposal is to have myself as maintainer for now but for the Debian Python Team to be listed as an Uploader.
Bug#1059855: ITP: node-sortable-tablesort -- Tiny plain JavaScript table sorter
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: node-sortable-tablesort Version : 3.1.0 Upstream Author : Jonas Earendel * URL : https://github.com/tofsjonas/sortable * License : Unlicense Programming Lang: JavaScript Description : Tiny plain JavaScript table sorter A JavaScript library for making tables sortable with minimal effort: just add class="sortable" to the table header. There are a small number of other features, such as making a specific field non-sortable. Node.js is an event-based server-side JavaScript engine. This package has recently been vendored into dask.distributed, so is being uploaded to become a build-time dependency of dask.distributed (rather than vendoring it within that package). I am a member of the Debian JavaScript maintainers team, and it will be maintained within that team.
Bug#1042443: ITP: pathos -- Framework for heterogeneous parallel computing
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team * Package name: pathos Version : 0.3.1 Upstream Contact: Mike McKerns * URL : https://github.com/uqfoundation/pathos * License : BSD-3-clause Programming Lang: Python Description : Framework for heterogeneous parallel computing Pathos provides a consistent high-level interface for configuring and launching parallel computations across heterogeneous resources. It provides configurable launchers for parallel and distributed computing, where each launcher contains the syntactic logic to configure and launch jobs in an execution environment. Examples of launchers include: "pyina", a queue-less MPI-based launcher; "pathos", an ssh-based launcher; "multiprocess", a multi-process launcher. . It provides a consistent interface for parallel and/or distributed versions of "map" and "apply" for each launcher; the guiding design principle is that "map" and "apply" should be drop-in replacements in otherwise serial code, reducing the time to conver a code to parallel, but also enabling a single code-base to be maintained instead of requiring serial, parallel and distributed versions of code. . The "pathos" framework consists of several interoperating packages: * "dill": serialize all of Python (python3-dill) * "pox": utilities for filesystem exploration and automated builds (python3-pox) * "klepto": persistent caching to memory, disk, or database (python3-klepto) * "multiprocess": better multiprocessing and multithreading in Python (python3-multiprocess) * "ppft": distributed and parallel Python (python3-ppft) * "pyina": MPI parallel "map" and cluster scheduling (python3-pyina) * "pathos": graph management and execution in heterogeneous computing (python3-pathos) This is a package I've started using; it provides a very effective framework for parallel computing, allowing for constructs that the standard Python library does not support. I will maintain it within the Debian Python Team.
Bug#1042444: ITP: klepto -- Persistent caching to memory, disk or database
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team * Package name: klepto Version : 0.2.4 Upstream Contact: Mike McKerns * URL : https://github.com/uqfoundation/klepto * License : BSD-3-clause Programming Lang: Python Description : Persistent caching to memory, disk or database klepto extends Python's lru_cache to utilise different keymaps and alternate caching algorithms. This package also has archiving capabilities for longer-term storage. It uses a simple dictionary-style interface for all caches and archives, and all caches can be applied to any Python function as a decorator. . klepto is intended to be used for distributed and parallel computing, where the keymaps serialize the stored objects, and the caches and archives are intended to be read/write accessible from different threads and processes. . klepto is part of pathos, a Python framework for heterogeneous computing. This is a plugin for the pathos package, which I am ITP'ing. I will maintain it within the Debian Python Team.
Bug#1042442: ITP: mystic -- Constrained nonlinear optimization
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team * Package name: mystic Version : 0.4.1 Upstream Contact: Mike McKerns * URL : https://github.com/uqfoundation/mystic * License : BSD-3-clause Programming Lang: Python Description : Constrained nonlinear optimization The mystic framework provides a collection of optimization algorithms and tools that allows the user to more robustly (and easily) solve hard optimization problems for machine learning, uncertainty quantification and AI. mystic gives the user fine-grained power to both monitor and steer optimizations as the fit processes are running. Users can customize optimizer stop conditions, where both compound and user-provided conditions may be used. Optimizers can save state, can be reconfigured dynamically, and can be restarted from a saved solver or from a results file. All solvers can also leverage parallel computing, either within each iteration or as an ensemble of solvers. . mystic provides a stock set of configurable, controllable solvers with: * a common interface * a control handler with: pause, continue, exit, and callback * ease in selecting initial population conditions: guess, random, etc * ease in checkpointing and restarting from a log or saved state * the ability to leverage parallel & distributed computing * the ability to apply a selection of logging and/or verbose monitors * the ability to configure solver-independent termination conditions * the ability to impose custom and user-defined penalties and constraints . mystic is part of pathos, a Python framework for heterogeneous computing. It is part of the pathos framework which I am packaging. Nonlinear optimisation is a core task for ML/AI, and use of this pathos plugin is demonstrated in several examples in the pathos package. I will maintain it within the Debian Python Team.
Bug#1042441: ITP: pox -- Utilities for filesystem exploration and automated builds
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team * Package name: pox Version : 0.3.3 Upstream Contact: Mike McKerns * URL : https://github.com/uqfoundation/pox * License : BSD-3-clause Programming Lang: Python Description : Utilities for filesystem exploration and automated builds This package is particular useful when exploring a filesystem on a remote host, where queries such as "what is the root of the filesystem?", "what is the user's name?", and "what login shell is preferred?" become essential in allowing a remote user to function as if they were logged in locally. . pox is part of pathos, a Python framework for heterogeneous computing. This is a dependency of pathos, which I am packaging. I will maintain it within the Debian Python Team.
Bug#1042440: ITP: pyina -- MPI parallel map and cluster scheduling
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team * Package name: pyina Version : 0.2.8 Upstream Contact: Mike McKerns * URL : https://github.com/uqfoundation/pyina * License : BSD-3-clause Programming Lang: Python Description : MPI parallel map and cluster scheduling The pyina package provides several basic tools to make MPI-based parallel computing more accessible to the end user. The goal of pyina is to allow the user to extend their own code to MPI-based parallel computing with minimal refactoring. . pyina provides a highly configurable parallel map interface to running MPI jobs, with: . * a map interface that extends the Python map standard * the ability to submit batch jobs to a selection of schedulers * the ability to customize node and process launch configurations * the ability to launch parallel MPI jobs with standard Python * ease in selecting different strategies for processing a work list . pyina is part of pathos, a Python framework for heterogeneous computing. This is a core plugin for the pathos system, which I am packaging. I cannot test it myself, though, as I don't have an MPI setup, but I am packaging it for those who use pathos and do have such a system. I will maintain it within the Debian Python Team.
Bug#1042439: ITP: ppft -- Distributed and parallel Python
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team * Package name: ppft Version : 1.7.6.7+dfsg Upstream Contact: Mike McKerns * URL : https://github.com/uqfoundation/ppft * License : BSD-3-clause Programming Lang: Python Description : Distributed and parallel Python ppft is a friendly fork of Parallel Python. It provides: . * parallel execution of Python code on SMP and clusters * easy-to-understand job-based parallelization * automatic detection of the number of effective processors * dynamic processor allocation (at runtime) * low overhead for jobs with the same function (through transparent caching) * dynamic load balancing (jobs are distributed at runtime) * fault-tolerance (if a node fails, tasks are rescheduled on the others) * auto-discovery of computational resources * dynamic allocation of computational resources * SHA based authentication for network connections * enhanced serialization, using dill.source . ppft is part of pathos, a Python framework for heterogeneous computing. It is a dependency of pathos, which is a useful framework that I've started using. I will maintain it within the Debian Python Team.
Bug#1026800: ITP: node-webfont -- Generate icon fonts from SVG icons
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, pkg-javascript-de...@lists.alioth.debian.org * Package name: node-webfont Version : 11.4.0 Upstream Contact: https://github.com/itgalaxy/webfont/issues * URL : https://github.com/itgalaxy/webfont * License : Expat Programming Lang: Javascript (Node.js) Description : Generate icon fonts from SVG icons Webfont converts sets of SVG files into an icon font, in any of the formats: woff2, woff, eot, ttf and svg. These can then be used in a browser. It has both a Node.js interface and a simple command-line interface (webfont). This package is needed to build a DFSG version of the Material Design Icons font (in the fonts-materialdesignicons-webfont package). It will be maintained within the Debian Javascript Maintainers team, with me taking the lead on it. The package will includes a number of Javascript dependencies that are not currently packaged; they will all be Provided by the package. They are as follows: * node-is-eot (= 1.0.0) * node-is-svg (= 4.3.2) * node-is-ttf (= 0.2.2) * node-is-woff (= 1.0.3) * node-is-woff2 (= 1.0.0) * node-neatequal (= 1.0.0) * node-svg-pathdata (= 6.0.3) * node-svgicons2svgfont (= 12.0.0) * node-ttf2eot (= 3.1.0) * node-ttf2woff (= 3.0.0) * node-varstream (= 0.3.2) * node-wawoff2 (= 2.0.1)
Bug#1023796: ITP: pylint-venv -- Pylint hook to use same pylint with different virtual envs
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pylint-venv Version : 2.3.0 Upstream Author : Jan Gosmann , Federico Jaramillo * URL : https://github.com/jgosmann/pylint-venv * License : MIT (Expat) Programming Lang: Python Description : Pylint hook to use same pylint with different virtualenvs Pylint does not respect the currently activated virtualenv if it is not installed in every virtual environment individually. This module provides a Pylint init-hook to use the same Pylint installation with different virtual environments. This package is a new dependency of spyder (version 5.4.0) which I'm currently preparing to upload. It is a single short Python module (about 90 lines excluding initial comments). It will be maintained within the Debian Python team, with me as the primary maintainer.
Bug#1019436: ITP: jarowinkler -- fast approximate string matching using Jaro(-Winkler) similarity
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: jarowinkler Version : 1.2.1 Upstream Author : Max Bachmann * URL : https://github.com/maxbachmann/JaroWinkler * License : MIT Programming Lang: Python Description : Fast approximate string matching using Jaro(-Winkler) similarity JaroWinkler is a Python library to calculate the Jaro and Jaro-Winkler similarity. It is easy to use, is much faster than other comparable libraries, and is designed to integrate seemingless with RapidFuzz. There is also a C++ library contained within this package, managed as a separate GitHub subrepository. This is jarowinkler-cpp, and I am not sure whether to bundle this as a single package or whether to package this independently. This is a dependency of python3-rapidfuzz, which is a new dependency of the latest upstream release of python3-textdistance. This package will be maintained within the Python Packaging Team.
Bug#1019435: ITP: rapidfuzz -- rapid fuzzy string matching
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: rapidfuzz Version : 2.6.1 Upstream Author : Max Bachmann * URL : https://github.com/maxbachmann/RapidFuzz * License : MIT Programming Lang: Python Description : rapid fuzzy string matching RapidFuzz is a fast string matching library for Python and C++, which uses the string similarity calculations from [FuzzyWuzzy](https://github.com/seatgeek/fuzzywuzzy). However there are a couple of aspects that set RapidFuzz apart from FuzzyWuzzy: 1) It is MIT licensed so it can be used whichever License you might want to choose for your project, while you're forced to adopt the GPL license when using FuzzyWuzzy 2) It provides many string_metrics like hamming or jaro_winkler, which are not included in FuzzyWuzzy 3) It is mostly written in C++ and on top of this comes with a lot of Algorithmic improvements to make string matching even faster, while still providing the same results. For detailed benchmarks check the [documentation](https://maxbachmann.github.io/RapidFuzz/fuzz.html) 4) Fixes multiple bugs in the `partial_ratio` implementation This is a dependency of the latest upstream release of python3-textdistance. There are also two C++ libraries contained within this package, managed as separate GitHub subrepositories. One is rapidfuzz-cpp, and I am not sure whether to bundle this as a single package or whether to package this independently. The other is taskflow (https://github.com/taskflow/taskflow)), a C++ header-only package; I think this should probably be packaged separately. This package will be maintained within the Python Packaging Team.
Bug#1019431: ITP: rapidfuzz-capi -- C-API of the Python RapidFuzz package
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: rapidfuzz-capi Version : 1.0.5 Upstream Author : Max Bachmann * URL : https://github.com/maxbachmann/rapidfuzz_capi * License : MIT Programming Lang: Python Description : C-API of the Python RapidFuzz package, used to build rapidfuzz This package provides the C API of RapidFuzz. It can be used inside `pyproject.toml` to compile an extension module extending RapidFuzz. Providing this C API in a separate package simplifies the build process. . This package is only needed for building packages such as python3-rapidfuzz and python3-jarowinkler; it is not needed at runtime. This is a dependency of python3-rapidfuzz and python3-jarowinkler, string-matching packages which are new (recursive) dependencies of the latest upstream release of python3-textdistance. This package will be maintained within the Python Packaging Team.
Re: Bug#1013425: ITP: wnpp -- Python Airspeed is a powerful templating engine compatible with Velocity for Java
On Thu, Jun 23, 2022 at 02:00:21PM +0200, Felix Moessbauer wrote: > Package: wnpp > Severity: wishlist > Owner: Felix Moessbauer > X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org > > * Package name: wnpp > Version : 0.5.19 > [...] > * URL : https://github.com/purcell/airspeed > [...] > Description : Airspeed is a powerful and easy-to-use templating engine > for Python that aims for a high level of compatibility with the popular > Velocity library for Java. Hi Felix, I'm not sure why you'd want to call this package "wnpp" rather than "airspeed" or "python-airspeed". Please could you change the title of this wnpp! Best wishes, Julian
Help in setting up lxc for autopkgtest - autopkgtest-build-lxc fails
Following Simon's suggestion, I decided to try setting up lxc to use autopkgtest-lxc, mimicking the ci.debian.org setup. I haven't managed to do so yet, and have run into lots of problems. I'd really appreciate some advice on what to try, and them we can record advice somewhere on the Debian wiki. Following the advice in autopkgtest-build-lxc(1), that user containers will not work with many or even most autopkgtests, I ran it as route. Step 1: Install the lxc and autopkgtest packages That went smoothly. (lxc version 1:4.0.11-1, autopkgtest version 5.21) Step 2: Run the command "autopkgtest-build-lxc debian sid" I got various warning messages, and this essentially failed... lxc-create: autopkgtest-sid: storage/btrfs.c: btrfs_create: 938 Inappropriate ioctl for device - Failed to create btrfs subvolume "/var/lib/lxc/autopkgtest-sid/rootfs" lxc-create: autopkgtest-sid: storage/zfs.c: zfs_create: 735 Failed to create zfs dataset "zfs:lxc/autopkgtest-sid": lxc-create: autopkgtest-sid: utils.c: run_command_internal: 1588 lxc-create: autopkgtest-sid: storage/lvm.c: do_lvm_create: 165 Failed to create logical volume "autopkgtest-sid": Volume group "lxc" not found Cannot process volume group lxc lxc-create: autopkgtest-sid: storage/lvm.c: lvm_create: 623 Error creating new logical volume "lvm:/dev/lxc/autopkgtest-sid" of size "1073741824 bytes" debootstrap is /usr/sbin/debootstrap Checking cache download in /var/cache/lxc/debian/rootfs-sid-amd64 ... Downloading debian minimal ... I: Target architecture can be executed I: Retrieving InRelease [downloading and installing base system] I: Base system installed successfully. Download complete. Copying rootfs to /var/lib/lxc/autopkgtest-sid/rootfs...ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. Generating locales (this might take a while)... ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. en_GB.UTF-8ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. [... lots more libeatmydata.so warnings, interspersed with other information messages ...] ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. lxc-start: autopkgtest-sid: lxccontainer.c: wait_on_daemonized_start: 867 Received container state "ABORTING" instead of "RUNNING" lxc-start: autopkgtest-sid: tools/lxc_start.c: main: 306 The container failed to start lxc-start: autopkgtest-sid: tools/lxc_start.c: main: 309 To get more details, run the container in foreground mode lxc-start: autopkgtest-sid: tools/lxc_start.c: main: 311 Additional information can be obtained by setting the --logfile and --logpriority options Something weird is going on here, but autopkgtest-build-lxc doesn't seem to allow a --logfile option. I attempted to start it manually, using the command lxc-start -n autopkgtest-sid --logfile /tmp/lxc.log --logpriority INFO and got the following errors in the log file: lxc-start autopkgtest-sid 20220429124743.756 WARN cgfsng - cgroups/cgfsng.c:get_hierarchy:142 - There is no useable devices controller lxc-start autopkgtest-sid 20220429124743.756 ERRORcgfsng - cgroups/cgfsng.c:cg_legacy_set_data:2675 - No such file or directory - Failed to setup limits for the "devices" controller. The controller seems to be unused by "cgfsng" cgroup driver or not enabled on the cgroup hierarchy lxc-start autopkgtest-sid 20220429124743.756 ERRORcgfsng - cgroups/cgfsng.c:cgfsng_setup_limits_legacy:2742 - No such file or directory - Failed to set "devices.deny" to "a" lxc-start autopkgtest-sid 20220429124743.756 ERRORstart - start.c:lxc_spawn:1890 - Failed to setup legacy device cgroup controller limits lxc-start autopkgtest-sid 20220429124743.756 ERRORlxccontainer - lxccontainer.c:wait_on_daemonized_start:867 - Received container state "ABORTING" instead of "RUNNING" [...] I found something like this reported at this GitHub issue against lxc: https://github.com/lxc/lxc/issues/2268 so I followed the advice there and ran the commands: mount -o remount,rw /sys/fs/cgroup mkdir /sys/fs/cgroup/devices mount -t cgroup devices -o devices /sys/fs/cgroup/devices mount -o remount,ro /sys/fs/cgroup But that seems to be really bad, as now systemd-logind.service seems to have broken and cannot be restarted, so I don't recommend doing that! I've restarted my system and started again. The above solution is very bad at least partly because /sys/fs/cgroup is type cgroup2. But I still can't start the LXC container, which makes running autopkgtest impossible. Is this a bug in lxc or in autopkgtest-build-lxc or somewhere else? Any suggestions would be much appreciated! Julian
Re: autopkgtest/sbuild environment variables: LC_ALL, HOME, XDG_RUNTIME_DIR etc
On Thu, Apr 28, 2022 at 02:32:49PM +0100, Simon McVittie wrote: > > That's interesting; I don't find any code that sets HOME in > > autopkgtest. > > The purpose of autopkgtest is to run the tests in a realistic environment > that resembles a real Debian desktop or server, but it doesn't know much > about how the testbed system is set up, so it relies on the virtualization > backend or the testbed itself to set HOME appropriately. Ideally, it > should be logging into a fully-working Debian system (perhaps under qemu > or lxc, or even on real hardware via ssh) and running tests there. > > As I said on #986665, this seems like either a bug in > autopkgtest-virt-schroot, or misconfiguration in how you and Laurent > are configuring it (the schroot profile that you're telling it to use). I've thought a little bit more about this, and I realise that the devil is in the detail, in particular the phrase "a realistic environment that resembles a real Debian desktop or server". A realistic environment is likely to have lots of random packages and services available. It would make some sense, therefore, to be more explicit about what is expected in this environment by default. Here's a very small list to begin with: 1. All essential packages are installed. 2. HOME points to a readable and writeable directory. [What is in this directory? Should it be cleaned before every use?] 3. XDG_RUNTIME_DIR points to ... / maybe this should be: libpam-systemd is installed? 4. Locale LC_ALL ... should be set up in a meaningful way. 5. ... more points? ... This will help developers to set up sensible environments. I now know I have been writing autopkgtest scripts that don't assume this and therefore don't properly replicate a typical desktop environment. But without these assumptions made explicit, it will be hard to guess what can be assumed and what can't be. Best wishes, Julian
Re: autopkgtest/sbuild environment variables: LC_ALL, HOME, XDG_RUNTIME_DIR etc
On Thu, Apr 28, 2022 at 02:32:49PM +0100, Simon McVittie wrote: > On Thu, 28 Apr 2022 at 14:02:46 +0100, Julian Gilbey wrote: > > On Thu, Apr 28, 2022 at 10:16:30AM +0100, Simon McVittie wrote: > > > According to the autopkgtest spec[1], > > > > > > Tests can expect that the $HOME environment variable to be set to > > > a directory that exists and is writeable by the user running the test. > > > > That's interesting; I don't find any code that sets HOME in > > autopkgtest. > > The purpose of autopkgtest is to run the tests in a realistic environment > that resembles a real Debian desktop or server, but it doesn't know much > about how the testbed system is set up, so it relies on the virtualization > backend or the testbed itself to set HOME appropriately. Ideally, it > should be logging into a fully-working Debian system (perhaps under qemu > or lxc, or even on real hardware via ssh) and running tests there. > > As I said on #986665, this seems like either a bug in > autopkgtest-virt-schroot, or misconfiguration in how you and Laurent > are configuring it (the schroot profile that you're telling it to use). > [...] I see; this makes more sense now. So can I suggest that sbuild-setup(7) explains this a bit more and discusses setting up a meaningful HOME directory? And perhaps has the things necessary for a meaningful XDG_RUNTIME_DIR set up by default as well? > > (Incidentally, given that > > typically XDG_RUNTIME_DIR is in the ephemeral /run filesystem, writing > > to it would not violate policy 4.9.) > > Policy §4.9 says that "Required targets must not attempt to write outside > of the unpacked source package tree", then makes a few exceptions for > locations like /tmp. /run is not one of those locations, so writing to > /run is not allowed. Ah, I didn't read it carefully enough; you are right. > > I wonder whether autopkgtest > > could consider setting up a temporary directory for this purpose like > > dh_auto_test does, rather than using the heavy machinery of > > libpam-systemd? > > No, I don't think it should. The purpose of autopkgtest is to run the > [...] Understood. Julian
Re: autopkgtest/sbuild environment variables: LC_ALL, HOME, XDG_RUNTIME_DIR etc
Thanks Paul and Simon for your very thoughtful and helpful replies! Comments on excerpted text below. On Thu, Apr 28, 2022 at 10:16:30AM +0100, Simon McVittie wrote: > On Thu, 28 Apr 2022 at 08:33:02 +0100, Julian Gilbey wrote: > > When I run autopkgtest using sbuild on my own machine, I sometimes get > > warnings or breakages because certain environment variables are either > > unset or have "broken" values, whereas I see that on ci.debian.net and > > the buildds, the builds run without problem. > > What autopkgtest backend are you using? (autopkgtest-virt-schroot? > autopkgtest-virt-qemu? ...) There are several, and their behaviour can be > very different, depending on the level of isolation they provide. I had been using the schroot backend. I hadn't realised that schroot is abandoned upstream, though it seems to work quite nicely. I haven't looked at lxc or qemu, though they sound like interesting alternatives. (Happy to receive recommendations for what would be simplest for an individual developer's machine!) > Having a concrete example of the command-line and configuration you use, > and a package that has warnings or breakage in this configuration, would > be useful. I was trying to apply a patch to pymca to fix bug#1010258; see version 5.7.1+dfsg-2 of the package. When building the package with sbuild, using the command line: gbp buildpackage --git-builder=sbuild -d unstable -A --source-only-changes the tests during package build time were fine, but the autopkgtest failed. I fixed the autopkgtest by specifying: LC_ALL=C HOME="$AUTOPKGTEST_TMP" xvfb-run ... This makes perfect sense given what you wrote later. > ci.debian.net currently uses autopkgtest-virt-lxc via the debci package. Ah, that would explain at least some of the difference with what I am seeing. > > HOME (pointing to where?) > > sbuild > -- > > There is no guarantee about $HOME while a Debian package is being built. > Policy §4.9 [0] says it is a bug for the build process of a package to > write into the real $HOME. It may well be that these autopkgtests don't write to home but attempt to access it to read from it. But I don't know. > debhelper compat levels >= 13 set a temporary $HOME for the duration > of the build, to make it easier for packages to comply with the Policy > §4.9 requirement. That would explain why the package build part worked smoothly. > autopkgtest > --- > > According to the autopkgtest spec[1], > > Tests can expect that the $HOME environment variable to be set to > a directory that exists and is writeable by the user running the test. That's interesting; I don't find any code that sets HOME in autopkgtest. And I just found this bug report, which points out that this doesn't actually happen: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986665 Now I understand that better, it seems that changing the autopkgtest spec to say something more like the following, if it's true: The HOME environment variable is inherited from the calling process. It is up to the container manager to ensure that this directory exists and is writeable by the user running the test. > Depending on backend, that directory might be your real home directory, > or it might be a transient/expendable home directory that it is OK for > the test to damage. It would probably be good to have a restriction[2] > that has the effect of guaranteeing that an expendable home directory > is used, as it is in autopkgtest-virt-qemu. That sounds like a really good idea! > > LC_ALL (or something similar; what is its setting?) > > LC_ALL is not normally set on "real" Debian systems. Usually, only $LANG > and $LANGUAGE are set, even on a full desktop system (for example my GNOME > desktop has LANG=en_GB.utf8 and LANGUAGE=en_GB:en, but no LC_ALL). > > LC_ALL is intended to be the "big hammer" that overrides everything else. Yes, indeed. But for some reason, pymca tries to set the locale at some point in the tests. Setting LC_ALL=C, though it is a big hammer, certainly helped! I haven't tried using a more restricted thing like LANG. > > and XDG_RUNTIME_DIR > > [...] > > sbuild does whatever schroot does. If I remember correctly, schroot > currently inherits XDG_RUNTIME_DIR from the host system, [...] It doesn't appear to do so (at least not by default). > debhelper compat levels >= 13 set a temporary $XDG_RUNTIME_DIR for the > duration of `dh_auto_test`, and unset it at all other times, to make it > easier for packages to comply with the Policy §4.9 requirement. Ah, that would explain why the tests work during build time but give warning messages with autopkgtest! (Incidentally, given that typically XDG_RUN
autopkgtest/sbuild environment variables: LC_ALL, HOME, XDG_RUNTIME_DIR etc
When I run autopkgtest using sbuild on my own machine, I sometimes get warnings or breakages because certain environment variables are either unset or have "broken" values, whereas I see that on ci.debian.net and the buildds, the builds run without problem. So clearly there are certain environment variables that are being set on these Debian machines that are not documented (or at least not anywhere that I could find). The particular environment variables that I have so far stumbled upon are HOME (pointing to where?), LC_ALL (or something similar; what is its setting?) and XDG_RUNTIME_DIR; there are probably others I am unaware of. It would be really useful to be able to set up my local sbuild environment in the same way as the Debian machines (buildd and ci.debian.net) for testing purposes. If anyone can shed some light on this, I'd be very grateful! And then perhaps this information could be added to sbuild-setup(7). Thanks! Julian
Bug#1005701: ITP: python-untangle -- Convert XML to a Python object
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-untangle Version : 1.1.1+git20200807.fb916a9 Upstream Author : Christian Stefanescu * URL : https://github.com/stchris/untangle * License : MIT Programming Lang: Python Description : Convert XML to a Python object Untangle has a very simple API for converting XML to a Python object: you just call the "parse" function on either a string, a filename or a URL. This package is used in the tests for pydevd, which I am currently working on packaging (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933070). It will be maintained within the Debian Python Team. Best wishes, Julian
Bug#1005267: ITP: python-bytecode -- Python module to generate, modify and optimize Python bytecode
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-bytecode Version : 0.13.0 Upstream Author : Victor Stinner and Matthieu C. Dartiailh * URL : https://github.com/MatthieuDartiailh/bytecode * License : MIT Programming Lang: Python Description : Python module to generate, modify and optimize Python bytecode The bytecode module can be used to write Python bytecode directly and then convert it into executable Python statements. It also provides a pure Python implementation of the Peephole Optimizer introduced in CPython 3.6. This Python module was vendored by the pydevd developers, and having a standalone version of the module will avoid having the embedded module in pydevd. (And pydevd turns out to be a recursive dependency of Spyder) The Debian version of this package will therefore require the pydevd patch; this enhances the bytecode functionality if it is used (via an optional argument) but has no effect otherwise. It will be maintained within the Debian Python Team.
Bug#1001627: ITP: pytest-order -- A pytest plugin to order test execution
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team * Package name: pytest-order Version : 1.1.0 Upstream Author : Frank Tobia * URL : https://github.com/pytest-dev/pytest-order * License : MIT Programming Lang: Python Description : A pytest plugin to order test execution pytest-order is a pytest plugin that allows you to customize the order in which your tests are run. It uses the marker order that defines when a specific test shall run, either by using an ordinal number, or by specifying the relationship to other tests. This package is required to run the tests supplied with the Spyder package (at build-time and for autopkgtest). It will be maintained within the Debian Python Team, with me as the Uploader. Best wishes, Julian
Bug#1000940: ITP: python-scss -- Python binding for libsass
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-sass Version : 2.3 Upstream Author : Sergey Kirillov * URL : https://github.com/pistolero/python-scss * License : Apache 2.0 Programming Lang: Python Description : Python binding for libsass This Python package provides a Python binding for libsass, providing the single method compile_string() to compile Sass strings to CSS. This package is a dependency of qtsass, which is itself a (recursive) dependency of the new version of Spyder. It will be maintained within the Python Packaging Team. Best wishes, Julian
Bug#1000903: ITP: qtsass -- Python package to bridge the gap between SASS and Qt-CSS
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: qtsass Version : 0.3.0+git20200324.06f1519 Upstream Author : Spyder Project Contributors * URL : https://github.com/spyder-ide/qtsass * License : MIT Programming Lang: Python Description : Python package to bridge the gap between SASS and Qt-CSS SASS brings countless amazing features to CSS. Besides being used in web development, CSS is also the way to stylize Qt-based desktop applications. However, Qt's CSS has a few variations that prevent the direct use of SASS compiler. The purpose of this tool is to fill the gap between SASS and Qt-CSS by handling those variations. The goal of QtSASS is to be able to generate a Qt-CSS stylesheet based on a 100% valid SASS file. This package is a (recursive) dependency of the new version of Spyder. It will be maintained within the Debian Python Team. Best wishes, Julian
Bug#1000809: ITP: qstylizer -- Python package to help with the construction of PyQt/PySide stylesheets
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: qstylizer Version : 0.2.1 Upstream Author : Brett Lambright * URL : https://github.com/blambright/qstylizer * License : MIT Programming Lang: Python Description : Python package to help with the construction of PyQt/PySide stylesheets This package allows for both the construction of new stylesheets and the easy modification of existing ones. This package is a dependency of the new version of Spyder (python3-spyder). It will be maintained within the Debian Python Team.
Re: Huh?? sbuild fails and pbuilder succeeds in building a Fortran-containing Python package
On Thu, Feb 11, 2021 at 12:15:38AM +0100, Johannes Schauer Marin Rodrigues wrote: > Hi, > > Quoting Julian Gilbey (2021-02-10 22:51:39) > > I wonder if anyone has an idea about this thorny problem. I'm trying > > to create a package and thought I'd got something wrong, but have > > found the same behaviour happens with the "amp" package (version > > 0.6.1-1) and the "spherepack" package (version 3.3~a1-4), which > > suggests to me that the problem lies outside of the package itself. > > But I have very little idea how to track this bug down. > > > > [...] > > > > They are so different, yet supposedly using essentially identical > > build environments. (They are also both using sid repositories.) > > > > If you have any idea why I might be seeing this behaviour, and what I > > might be able to do about it, that would be fantastic! > > I would actually not be surprised if we find reproducibility problems between > packages built on pbuilder versus packages build with sbuild. For example > sbuild sets HOME=/sbuild-nonexistent which will make packages FTBFS that try > to > put anything in $HOME. This is not the problem here, though. If I wrap the > call > to dh in debian/rules in strace -p I get: > > [...] > [pid 609] openat(AT_FDCWD, "/dev/shm/o5kYxf", O_RDWR|O_CREAT|O_EXCL, 0600) > = -1 EACCES (Permission denied) > [...] > [pid 609] write(2, "error: [Errno 13] Permission den"..., 36error: [Errno > 13] Permission denied Hi Josch, Wow, thanks! I tried putting the strace call around the whole build, but that didn't work. > A workaround for this problem is indeed to add > > --chroot-setup-commands="chmod 777 /dev/shm" > > to your sbuild invocation. A cursory glance into the pbuilder codebase reveals > that pbuilder will mount a tmpfs into /dev/shm: > > https://sources.debian.org/src/pbuilder/0.231/pbuilder-modules/?hl=417#L417 > > For sbuild, whether this is done, this depends on your chroot backend. The > package builds fine on the buildds though, so I guess they have a schroot > setup > that sets /dev/shm up correctly? OK, so I'll submit this as a bug report / feature request to sbuild. Many thanks for tracking down the cause of this! Best wishes, Julian
Huh?? sbuild fails and pbuilder succeeds in building a Fortran-containing Python package
I wonder if anyone has an idea about this thorny problem. I'm trying to create a package and thought I'd got something wrong, but have found the same behaviour happens with the "amp" package (version 0.6.1-1) and the "spherepack" package (version 3.3~a1-4), which suggests to me that the problem lies outside of the package itself. But I have very little idea how to track this bug down. If I run sbuild: sbuild -s -A -d unstable spherepack_3.3~a1-4.dsc then the build starts OK, but when it comes to compiling the C sources (or maybe it's actually the Fortran sources - I don't know), I get the following: [...] building 'spherepack' extension compiling C sources C compiler: x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -ffile-prefix-map=/build/python3.9-euU3fN/python3.9-3.9.1=. -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC creating build/temp.linux-x86_64-3.9/build creating build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9 creating build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9/Src creating build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9/build creating build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9/build/src.linux-x86_64-3.9 creating build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9/build/src.linux-x86_64-3.9/Src compile options: '-Ibuild/src.linux-x86_64-3.9/build/src.linux-x86_64-3.9/Src -I/usr/lib/python3/dist-packages/numpy/core/include -I/usr/include/python3.9 -c' error: [Errno 13] Permission denied An identical "Permission denied" error happens with the "amp" package as well, and also with the new package that I'm working on. However, with pbuilder: pbuilder build spherepack_3.3~a1-4.dsc I get a successful build, and the similar part of the output reads: [...] building 'spherepack' extension compiling C sources C compiler: x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -ffile-prefix-map=/build/python3.9-euU3fN/python3.9-3.9.1=. -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2 -ffile-prefix-map=/build/spherepack-3.3~a1=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC compile options: '-Ibuild/src.linux-x86_64-3.9/build/src.linux-x86_64-3.9/Src -I/usr/lib/python3/dist-packages/numpy/core/include -I/usr/include/python3.9 -c' x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -g -fwrapv -O2 -Wl,-z,relro -g -O2 -ffile-prefix-map=/build/spherepack-3.3~a1=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9/Src/spherepackmodule.o build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9/build/src.linux-x86_64-3.9/Src/fortranobject.o -L/build/spherepack-3.3~a1/Src -lsphere -o build/lib.linux-x86_64-3.9/spherepack.cpython-39-x86_64-linux-gnu.so running install_lib [...] They are so different, yet supposedly using essentially identical build environments. (They are also both using sid repositories.) If you have any idea why I might be seeing this behaviour, and what I might be able to do about it, that would be fantastic! Thanks! Julian
Bug#979204: ITP: textdistance -- Python library for calculating distances between sequences
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: textdistance Version : 4.2.0 Upstream Author : orsinium * URL : https://github.com/life4/textdistance * License : MIT Programming Lang: Python Description : Library for calculating distances between sequences This Python library can calculate the distance between sequences or strings using over 30 algorithms. It is a pure Python implementation, but can make use of other libraries (listed as Suggests, some of which have compiled extensions) for increased speed. This package is a dependency of the new Spyder 4.x series, hence the need to package it. This package will be maintained within the Debian Python Team.
Bug#979203: ITP: pyls-spyder -- Spyder plugin for the Python Language Server
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pyls-spyder Version : 0.3.0 Upstream Author : Spyder Project Contributors / Spyder IDE * URL : https://github.com/spyder-ide/pyls-spyder * License : MIT Programming Lang: Python Description : Spyder plugin for the Python Language Server This package provides a plugin required by Spyder. This package is a dependency of the new Spyder 4.x series, hence the need to package it. This package will be maintained within the Debian Python Team.
Bug#979202: ITP: pyls-black -- Black plugin for the Python Language Server
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pyls-black Version : 0.4.6 Upstream Author : Rupert Bedford * URL : https://github.com/rupert/pyls-black * License : MIT Programming Lang: Python Description : Black plugin for the Python Language Server This package provides a plugin to support the Black formatter in editors that support the Python Language Server. . It is recommended by the author to not have python3-yapf or python3-autopep8 installed when using this plugin, as that might lead to unexpected results. This package is a dependency of the new Spyder 4.x series, hence the need to package it. This package will be maintained within the Debian Python Team.
Bug#979201: ITP: abydos -- Python NLP/IR library of phonetic algorithms, string distances and more
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: abydos Version : 0.5.0+git20200210.9ec3824 Upstream Author : Christopher C. Little * URL : https://github.com/chrislit/abydos * License : GPL-3+; one file has different parts which are identified as GPL-3+, BSD-3-clause and freely-redistributable Programming Lang: Python Description : NLP/IR library of phonetic algorithms, string distances and more Abydos is a Python library containing about 40 phonetic algorithms, 35 string distance measures & metrics, 10 stemmers, and 10 string fingerprinters. . Some of the algorithms require installation of the suggested packages. This package is a (recursive) dependency of the new Spyder 4.x series, hence the need to package it. This package will be maintained within the Debian Python Team.
Bug#979200: ITP: three-merge -- Perform a 3-way merge between strings at a character level (Python library)
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: three-merge Version : 0.1.1 Upstream Author : Spyder IDE * URL : https://github.com/spyder-ide/three-merge * License : MIT Programming Lang: Python Description : Perform a 3-way merge between strings at a character level This library is based on the diff-match-patch library. This library performs merges at a character level, as opposed to most VCS systems, which opt for a line-based approach. This package is a dependency of the new Spyder 4.x series, hence the need to package it. This package will be maintained within the Debian Python Team.
Bug#979199: ITP: py-stringmatching -- Library of string tokenizers and similarity measures
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: py-stringmatching Version : 0.4.2+git20201204.6a7fb57 Upstream Author : anhaidgroup, py_stringmatching Team * URL : https://github.com/anhaidgroup/py_stringmatching * License : BSD-3-clause Programming Lang: Python Description : Library of string tokenizers and similarity measures This project seeks to build a Python software package that consists of a comprehensive and scalable set of string tokenizers (such as alphabetical tokenizers, whitespace tokenizers) and string similarity measures (such as edit distance, Jaccard, TF/IDF). This package is a (recursive) dependency of the new Spyder 4.x series, hence the need to package it. This package will be maintained within the Debian Python Team.
Bug#979198: ITP: pyxdameraulevenshtein -- Fast Damerau-Levenshtein (DL) edit distance implementation
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pyxdameraulevenshtein Version : 1.6.1 Upstream Author : Geoffrey Fairchild * URL : https://github.com/gfairchild/pyxDamerauLevenshtein * License : BSD-3-clause Programming Lang: Python (and Cython) Description : Fast Damerau-Levenshtein (DL) edit distance implementation This Python library for computing the Damerau-Levenshtein (DL) edit distance for sequences has been developed using Cython for speed. This package is a (recursive) dependency of the new Spyder 4.x series, hence the need to package it. This package will be maintained within the Debian Python Team.
Bug#979197: ITP: distance -- Python library for comparing sequences
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: distance Version : 0+git20131122.ad7f9dc Upstream Author : Michaël Meyer * URL : https://github.com/doukremt/distance * License : GPL-3+, public-domain, BSD-1-clause Programming Lang: Python (with a disabled C library) Description : Python library for comparing sequences This package provides helpers for computing similarities between arbitrary sequences. Included metrics are Levenshtein, Hamming, Jaccard, and Sorensen distance, plus some bonuses. The distance computations are implemented in pure Python. This package is needed as a build dependency for python3-textdistance, which is a much more comprehensive Python package for calculating the distance between sequences. This package is a (recursive) dependency of the new Spyder 4.x series, hence the need to package it. There is an included C library which is optional but broken and so has been disabled. This package will be maintained within the Debian Python Team.
Bug#979196: ITP: paq -- Python library for the paq9a compression algorithm
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: paq Version : 0.1.1+git20170722.9c5d493 Upstream Author : Jingchao Hu * URL : https://github.com/observerss/paq * License : MIT, GPL-3+ (different files with different licenses) Programming Lang: Python (with a C extension) Description : Python library for the paq9a compression algorithm This Python library supports compression and decompression using the paq9a algorithm. This package is a (recursive) dependency of the new Spyder 4.x series, hence the need to package it. This package will be maintained within the Debian Python Team.
Bug#979195: ITP: pylzss -- Python library for the LZSS compression algorithm
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pylzss Version : 0+git20200722.871ef5a Upstream Author : Guillaume Tucker * URL : https://github.com/yyogo/pylzss * License : LGPL-3+, MIT, Free-Use (different files are under different licenses). The Free-Use license is reproduced below. Programming Lang: Python (with C extension) Description : Python library for the LZSS compression algorithm This Python library supports compression and decompression using the LZSS algorithm. The Free-Use license reads: Use, distribute, and modify this program freely. Please send me your improved versions. This package is a (recursive) dependency of the new Spyder 4.x series, hence the need to package it. This package will be maintained within the Debian Python Team.
Bug#979194: ITP: syllabipy -- Collection of universal syllabification algorithms (Python library)
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: syllabipy Version : 0.2 Upstream Author : Alex Estes and Christopher Hench * URL : https://github.com/henchc/syllabipy * License : MIT Programming Lang: Python Description : Collection of universal syllabification algorithms This package provides two syllabification algorithms: SonoriPy and LegaliPy. There will be no further updates to this package: SonoriPy has been incorporated into the NLTK library (python3-nltk) and that should be used in preference to this package. Both algorithms have also been incorporated into the Talisman NLP library for JavaScript. This package is a (recursive) dependency of the new Spyder 4.x series, hence the need to package it. This package will be maintained within the Debian Python Team.
Bug#968823: ITP: maturin -- ITP: maturin - Build and publish crates with pyo3, rust-cpython and cffi bindings as well as rust binaries as python packages
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: maturin Version : 0.8.3 Upstream Author : Konstin * URL : https://github.com/pyo3/maturin * License : MIT OR Apache-2.0 Programming Lang: Rust and Python Description : ITP: maturin - Build and publish crates with pyo3, rust-cpython and cffi bindings as well as rust binaries as python packages This project is meant as a zero configuration replacement for setuptools-rust and milksnake. It supports building wheels for python 3.5+ on windows, linux, mac and freebsd, can upload them to pypi and has basic pypy support. This will be maintained within the Rust Packaging Team. It is a build-dependency for recent versions of Anki.
Re: Apt-secure and upgrading to bullseye
On Wed, Jul 10, 2019 at 02:30:24PM +0200, David Kalnischkies wrote: > Hi, > > On Wed, Jul 10, 2019 at 12:31:51PM +0100, Julian Gilbey wrote: > > Hooray, buster's released! Congrats to all! > > Indeed! ☺ > > > E: Repository 'http://ftp.uk.debian.org/debian testing InRelease' changed > > its 'Codename' value from 'buster' to 'bullseye' > > N: This must be accepted explicitly before updates for this repository can > > be applied. See apt-secure(8) manpage for details. > > There are various reports about that against apt/aptitude, so I am not > feeling like adding lots of duplicated content now, but the gist is: > > Either use "apt update" (it will ask an interactive question) or > "apt-get update --allow-releaseinfo-change" (see apt-get manpage) or > [least preferred option] set the config option > Acquire::AllowReleaseInfoChange for basically any apt-based client. Thanks to everyone for suggestions; I discovered "apt update" through a Google search. But I realised later that this is going to bite all users when they come to upgrade from buster. Perhaps some aptitude and apt-get patches can go into a stable (buster) point release, so that fewer users are hurt by this in 2-3 years' time? It is quite a showstopper! Best wishes, Julian
Re: Apt-secure and upgrading to bullseye
On Wed, Jul 10, 2019 at 12:31:51PM +0100, Julian Gilbey wrote: > Hooray, buster's released! Congrats to all! > > So I tried upgrading my machine to bullseye today, and > aptitude/apt-get update don't like this, giving me errors such as: > > E: Repository 'http://ftp.uk.debian.org/debian testing InRelease' changed its > 'Codename' value from 'buster' to 'bullseye' > N: This must be accepted explicitly before updates for this repository can be > applied. See apt-secure(8) manpage for details. > > So I read apt-secure(8), which gives no indication of how to "accept > this explicitly", and neither do any of the linked wiki pages. > > Any suggestions? > > (And obviously something needs changing so that people aren't stung > when bullseye is released.) Ah, turns out it's a known bug with aptitude. The solution is to run "apt update", which interactively asks what to do with these changes. Best wishes, Julian
Apt-secure and upgrading to bullseye
Hooray, buster's released! Congrats to all! So I tried upgrading my machine to bullseye today, and aptitude/apt-get update don't like this, giving me errors such as: E: Repository 'http://ftp.uk.debian.org/debian testing InRelease' changed its 'Codename' value from 'buster' to 'bullseye' N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details. So I read apt-secure(8), which gives no indication of how to "accept this explicitly", and neither do any of the linked wiki pages. Any suggestions? (And obviously something needs changing so that people aren't stung when bullseye is released.) Best wishes, Julian
Bug#852362: ITP: send2trash -- Python module for sending file to trash natively
Package: wnpp Severity: wishlist Owner: Julian Gilbey * Package name: send2trash Version : 1.3.0 Upstream Author : Hardcoded Software * URL : http://github.com/hsoft/send2trash * License : BSD Programming Lang: Python Description : Python module for sending file to trash natively This module sends a file to the trash using either the Glib system for handling a desktop trash file or its own home-grown system if python-gi is not installed. It is a very simple module; it works on Python 2 and 3, and will be needed by the new version of Anki (2.1.0-alpha), as this module is no longer bundled within the Anki distribution.
Bug#842111: ITP: jigsaw-generator -- Mathematical jigsaw creation software
Package: wnpp Severity: wishlist Owner: Julian Gilbey * Package name: jigsaw-generator Version : 0.2.1 Upstream Author : Julian Gilbey * URL : https://github.com/juliangilbey/jigsaw-generator.git * License : GPL Programming Lang: Python Description : Mathematical jigsaw creation software This software is designed to create Tarsia Formulator type mathematical jigsaws using LaTeX. The puzzle data is stored in a YAML file, and the software turns it into a printable jigsaw. This software makes it reasonably straightforward to create multiple jigsaw-style puzzles. I am the upstream author; I presented it at a TUG Conference a couple of years ago, but have not yet packaged it for Debian. It is now mature enough to release. There is no Linux package like it that I am aware of.
Re: systemd now appears to be only possible init system in testing
On Wed, Jul 23, 2014 at 12:51:16AM +0200, Svante Signell wrote: > Forward this to the debian CTTE, please! Thanks for the suggestion, Svante! I've just reread https://www.debian.org/devel/tech-ctte and it does not yet seem appropriate for the CTTE; there has not yet been any discussion with the relevant package maintainers. A bit more searching (reading the relevant changelogs) has shown that bugs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752939 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754984 contain a lot more information about this issue. It seems that once cgmanager 0.27 is allowed into unstable from NEW, a new version of systemd-shim will be able to be uploaded, which will allow libpam-systemd to coexist with sysvinit once again. It's just a shame that various migrations to testing were allowed before this had been resolved :-( Anyway, I would still love to know how to write a systemd script which pauses to accept input from the keyboard before continuing. Julian > On Tue, 2014-07-22 at 22:54 +0100, Julian Gilbey wrote: > > I just tried updating testing on my system. I currently use > > sysvinit-core (reasons below), but aptitude is telling me that I > > should remove this in favour of systemd-sysv. Hmm, why is that? > > Well, because the new version of libpam-systemd, 208-6, now depends on > > systemd-sysv rather than systemd-sysv | systemd-shim. OK, so I'll > > remove libpam-systemd. Ooops - that looks pretty disastrous, as so > > much depends on it, so that's not an option: gdm3, gnome-bluetooth, > > network-manager, policykit-1, udisks2. > > > > So I would presume that for many or most Debian systems, systemd is > > now required, and no other /sbin/init providers will work. I'm > > unclear whether this was a deliberate policy decision or an unintended > > consequence of various package requirements. > > > > For me, this is a killer, as I still do not know how to solve the > > problem I asked a while back on debian-user > > (https://lists.debian.org/debian-user/2014/04/msg01286.html): in > > summary, I need to unlock an encrypted filesystem during boot time by > > asking for a password to feed into encfs. But I cannot figure out how > > to do this under systemd. > > > > Answers to this question would also be much appreciated! > > > >Julian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140722230804.ga30...@d-and-j.net
systemd now appears to be only possible init system in testing
I just tried updating testing on my system. I currently use sysvinit-core (reasons below), but aptitude is telling me that I should remove this in favour of systemd-sysv. Hmm, why is that? Well, because the new version of libpam-systemd, 208-6, now depends on systemd-sysv rather than systemd-sysv | systemd-shim. OK, so I'll remove libpam-systemd. Ooops - that looks pretty disastrous, as so much depends on it, so that's not an option: gdm3, gnome-bluetooth, network-manager, policykit-1, udisks2. So I would presume that for many or most Debian systems, systemd is now required, and no other /sbin/init providers will work. I'm unclear whether this was a deliberate policy decision or an unintended consequence of various package requirements. For me, this is a killer, as I still do not know how to solve the problem I asked a while back on debian-user (https://lists.debian.org/debian-user/2014/04/msg01286.html): in summary, I need to unlock an encrypted filesystem during boot time by asking for a password to feed into encfs. But I cannot figure out how to do this under systemd. Answers to this question would also be much appreciated! Julian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140722215455.ga28...@d-and-j.net
Re: Update on R 3.0.0 migration (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Sun, Apr 07, 2013 at 11:17:31AM +0200, Philip Rinn wrote:
> On 07.04.2013 03:07, Julian Gilbey wrote:
> > Ah, thanks Chris, I wasn't aware of that! But then it seems to me
> > that the correct lines should be:
> >
> > Build-Depends: ..., r-base-dev, ...
> > [...]
> > Depends: ..., ${R:Depends}, ...
> >
> > as the source package is *not* dependent upon the R version, only the
> > binary package resulting from it; this will aid any backporters, for
> > example.
> No, you have to Build-Depend on the minimal R version your package needs.
> A (probably bad) example: sactterelot3d needs R >= 2.7.0 so my Build-Depends
> is:
>
> Build-Depends: debhelper (>= 9), cdbs, r-base-dev (>= 2.7.0)
Yes, indeed. My bad. But it does *not* need to depend on r-base-dev
(>= 3.0.0) unless the package actually requires 3.0.0 functionality.
Uploading erm 0.14-0-6 with the correct build-time dependencies;
raschsampler has no specified R version dependency, so leaving that
one unspecified.
Julian
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130407120102.gb25...@d-and-j.net
Re: Update on R 3.0.0 migration (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Sat, Apr 06, 2013 at 07:48:20PM -0500, Dirk Eddelbuettel wrote:
> | If you're using cdbs and r-cran.mk in debian/rules, you can add
> | Depends: ${R:Depends} to debian/control to pick up the current binary
> | dependency. I've migrated almost all of my packages over and it makes
> | life easier.
>
> Right. "What Chris said." This is something Andreas and Charles have pushed
> for and which most of the 150+ r-cran-packages now use. One example from one
> of my 100-ish r-cran-* packages:
Ah, cool!
>Build-Depends: debhelper (>= 7), r-base-dev (>= 3.0.0), cdbs
>[...]
>Depends: ${shlibs:Depends}, ${R:Depends}
>
> The Build-Depends: edit is manual.
>
> The one in Depends: no longer is. That is useful.
Ah, thanks Chris, I wasn't aware of that! But then it seems to me
that the correct lines should be:
Build-Depends: ..., r-base-dev, ...
[...]
Depends: ..., ${R:Depends}, ...
as the source package is *not* dependent upon the R version, only the
binary package resulting from it; this will aid any backporters, for
example.
Julian
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130407010724.ga24...@d-and-j.net
Re: Update on R 3.0.0 migration (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Fri, Apr 05, 2013 at 09:04:41PM -0500, Dirk Eddelbuettel wrote:
> First off, let me apologize. I clearly did this the wrong way and should have
> contacted -release and -devel beforehand. My bad -- I'm sorry for extra work
> this created for the release managers and maintainer, particularly at this
> time.
>
> R 3.0.0 was released on April 3 as scheduled. As usual, I built a package the
> morning of, and all build daemons are current. (There was also an unrelated
> bug which is why were at 3.0.0-2.) The release team kindly put a block on
> it, so it will make it into testing. Good.
> [...]
> So 127 packages are already taken care of. On the other hand, we still have
> ~50 packages needing work:
> [...]
>
> R> print(todo[ order(todo[,2]), ], row.names=FALSE)
>pkg maint
> r-cran-erm j...@debian.org
>r-cran-raschsampler j...@debian.org
I uploaded these to unstable on Friday lunchtime, and they were
accepted into unstable on Friday afternoon; I'm unclear why they are
still in your list? Did I do something wrong?
Oh yes, I clearly did. Even though I built it in a chroot with
r-base-dev 3.0.0-2 installed, I forgot to update the Depends lines in
the control files.
So something doesn't make sense somewhere: if my package doesn't care
which version of R it's building against, but R itself cares, then
surely there should be some way of querying r-base-dev during the
build process to enquire which version is required? It is almost
certainly too late to do anything about this for wheezy, but it would
be good to think about doing something for wheezy+1. Ideally, this
would be by creating a misc substvar so that instead of having to
specify the version of r-base-core in the Depends: field, it could be
specified just as ${misc:Depends} and then filled in automatically.
Anyway, I'm rebuilding them now with the dependencies updated to
3.0.0-2.
Julian
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130406205527.gb32...@d-and-j.net
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Sun, Mar 31, 2013 at 11:45:15AM -0500, Dirk Eddelbuettel wrote: > > A new major release R 3.0.0 will come out on Wednesday April 3rd, as usual > according the the release plan and announcements [1]. > > It contains major internal changes [2] and requires rebuilds of all R > packages. As I usually do, I started packaging pre-releases and rc > candidates [3] based on March 24, 27 and 30 snapshots. > > Michael Rutter, who tirelessly backports (most of) my Debian R packages to > Ubuntu, has also made builds of these R packages [4]. > > As for unstable, we have an issue as essentially all reverse-dependencies > that are R packages will need to be rebuilt [5]. On testing, I get for > 158 packages from `apt-cache rdepends r-base-core | grep -c r-cran-`. I am a little unclear what is required; is a binary rebuild sufficient, or is some change in the source code necessary? If the former, would it not be better just to ask the buildd administrators for a binary rebuild as opposed to having a new source version just for this? Julian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130405075352.gc6...@d-and-j.net
Bug#544402: ITP: r-cran-erm -- GNU R package for extended Rasch modelling
Package: wnpp Severity: wishlist Owner: Julian Gilbey Package name: r-cran-erm Version : 0.10-2 Upstream Author : Patrick Mair and Reinhold Hatzinger URL : http://r-forge.r-project.org/projects/erm/ License : GPL-2 Programming Lang: R and C Description : GNU R package for extended Rasch modelling eRm fits Rasch models (RM), linear logistic test models (LLTM), rating scale model (RSM), linear rating scale models (LRSM), partial credit models (PCM), and linear partial credit models (LPCM). Missing values are allowed in the data matrix. Additional features are the ML estimation of the person parameters, Andersen's LR-test, item-specific Wald test, itemfit and personfit statistics including infit and outfit measures, various ICC and related plots, automated stepwise item elimination, simulation module for various binary data matrices. An eRm platform is provided at R-forge (see URL). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Who uses @packages.d.o mail?
On Fri, May 22, 2009 at 10:30:03PM +0100, Stephen Gran wrote: > Hello all, > > So I've looked through a few weeks of mail logs to packages.debian.org, > and it looks like it collects some useful mail from automated scripts > on various debian.org machines (primarily ries), and about 1000 spams a > day from elsewhere. I haven't done an exhaustive survey, but it seems > pretty clear so far that the domain does not get any significant amount > of legitimate mail from machines other than the debian.org hosts. I occasionally do use this route, although I could email the package maintainers directly. Would it be possible to allow mail from arbitrary hosts as long as it has some special header, say "X-Debian-Pkg: foo" where foo matches the package being mailed? However, I wouldn't personally have a problem with it being blocked completely from non-Debian machines. Julian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: arch-all-package shown with two versions on p.d.o (was: Bug#427859: lmodern fails to configure on upgrade, dpkg error)
On Sun, Jun 10, 2007 at 02:17:49PM +0200, Frank Küster wrote: > Hi all, > > Florent noticed that for tex-common, two versions are listed as being > available in testing although the package is Arch: all: > > Florent Rougon <[EMAIL PROTECTED]> wrote: > > > BTW, I don't understand why both 1.0.1 and 1.7 are listed for > > testing at: > > > > http://packages.debian.org/cgi-bin/search_packages.pl?keywords=tex-common&searchon=names&subword=1&version=all&release=all > > > > Any idea? > > I have none, is anyone able to help? Is this a problem in the script > that generates packages.debian.org's information, or elsewhere? rmadison only lists 1.7. Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#417261: dch: please use dates in UTC
On Mon, Apr 02, 2007 at 01:37:23PM +0200, Robert Millan wrote: > > This is a nice idea. I think it should also be discussed on > > debian-devel and debian-policy. > > CCing -devel. For -policy I think it is too early (usualy, common practice is > stablished before Policy enforces it). > > Also adding CC to analogous bug in dh-make, so that it can catch followups > from -devel. And debian-el too. Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#411591: RFA: devscripts -- Scripts to make the life of a Debian Package maintainer easier
On Tue, Feb 20, 2007 at 01:20:54PM +0100, Martin Zobel-Helas wrote: > Hi, > > > > > I request an adopter for the devscripts package. I have had very > > little time over recent months (years, even), and this package really > > demands far more active maintenance than I am able to give it. > > I would be willing to addopt that package, but team maintainance would > be very much appreciated. > > As i side note: i spoke to Christoph Berg (myon), and he would also be > willing to help. Fabulous! Team maintenance is almost certainly the way to go. Stephano has also expressed interest, and wisely suggested that in a couple of days, we figure out who's expressed interest, and how best to migrate to this new team. Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#411591: RFA: devscripts -- Scripts to make the life of a Debian Package maintainer easier
Package: wnpp Severity: normal I request an adopter for the devscripts package. I have had very little time over recent months (years, even), and this package really demands far more active maintenance than I am able to give it. There are generally relatively few bugs but lots and lots of wishlist requests. With the prominence of the package, it is really important that whoever takes it on is willing to do a significant amount of new coding in bash and Perl, the two main languages used in the package. If you are interested, please check out the BTS page (http://bugs.debian.org/devscripts) to get some idea of the number and range of current requests for features: some of these are quick, some would require some major (re)coding. The package is currently developed via an SVN repository on alioth, and consists of numerous mostly-unrelated scripts, so could be easily be managed by a small group of maintainers. Thanks in advance! Julian And in case you don't know already, the package description currently reads: Contains the following scripts, dependencies/recommendations shown in brackets afterwards: . - annotate-output: run a command and prepend time and stream (O for stdout, E for stderr) for every line of output - archpath: print tla/Bazaar package names [tla | bazaar] - bts: a command-line tool for manipulating the BTS [www-browser, libwww-perl, mailx | mailutils] - checkbashisms: check whether a /bin/sh script contains any common bash-specific contructs - cvs-debi, cvs-debc: to call debi and debc from the CVS working directory after running cvs-debuild or cvs-buildpackage [cvs-buildpackage] - cvs-debrelease: to call debrelease from the CVS working directory after running cvs-debuild or cvs-buildpackage [cvs-buildpackage, dupload | dput, ssh] - cvs-debuild: run cvs-buildpackage using debuild (see below) as the package building program [cvs-buildpackage, fakeroot, lintian | linda, gnupg] - dd-list: given a list of packages, pretty-print it ordered by maintainer - debc: display the contents of just-built .debs - debchange/dch: automagically add entries to debian/changelog files [wget] - debclean: purge a Debian source tree [fakeroot] - debcommit: commit changes to cvs or svn, basing commit message on changelog [cvs | subversion] - debdiff: compare two versions of a Debian package to check for added and removed files [wdiff, patchutils] - debi: install a just-built package - debpkg: dpkg wrapper to be able to manage/test packages without su - debrelease: wrapper around dupload or dput [dupload | dput, ssh] - debsign, debrsign: sign a .changes/.dsc pair without needing any of the rest of the package to be present; can sign the pair remotely or fetch the pair from a remote machine for signing [gnupg, debian-keyring, ssh] - debuild: wrapper to build a package without having to su or worry about how to invoke dpkg to build using fakeroot. Also deals with common environment problems, umask etc. [fakeroot, lintian | linda, gnupg] - deb-reversion: increases a binary package version number and repacks the archive - dget: downloads Debian source and binary packages [wget] - dpkg-depcheck, dpkg-genbuilddeps: determine the packages used during the build of a Debian package; useful for determining the Build-Depends control field needed [build-essential, strace] - dscverify: verify the integrity of a Debian package from the .changes or .dsc files [gnupg, debian-keyring, libdigest-md5-perl] - grep-excuses: grep the update_excuses.html file for your packages [wget] - mass-bug: mass-file bug reports [mailx | mailutils] - mergechanges: merge .changes files from a package built on different architectures - nmudiff: mail a diff of the current package against the previous version to the BTS to assist in tracking NMUs [patchutils, mutt] - plotchangelog: view a nice plot of the data in a changelog file [libtimedate-perl, gnuplot] - pts-subscribe: subscribe to the PTS for a limited period of time [mailx | mailutils, at] - rc-alert: list installed packages which have release-critical bugs [wget] - rmadison: remotely query the Debian archive database about packages [wget] - svnpath: print svn repository paths [subversion] - tagpending: shell script which runs from a Debian source tree and tags bugs that are to be closed in the latest changelog as pending. [wget] - uscan: scan upstream sites for new releases of packages [libwww-perl] - uupdate: integrate upstream changes into a source package [patch] - whodepends: check which maintainers' packages depend on a package - who-uploads [gnupg, debian-keyring, wget]: determine the most recent uploaders of a package to the Debian archive - wnpp-alert: list installed packages which are orphaned or up for adoption [wget] . Also included are a set of example mail filters for filtering mail fr
Re: Etch system frequently hanging - help to diagnose origin needed
On Mon, Jan 22, 2007 at 11:00:21AM +0100, Eduard Bloch wrote: > #include > * Julian Gilbey [Mon, Jan 22 2007, 09:32:00AM]: > > I have a randomly recurring problem on my etch system which should be > > diagnosed if possible - there's almost certainly a grave bug > > somewhere. > > > > My computer keeps crashing in a weird way. > > > > I am running GNOME. I'm attaching the current output of ps aux; it > > would have been very similar when the system crashed. > > http://www.google.de/search?q=forget+mail+attachement&ie=utf-8&oe=utf-8&rls=org.debian:en-US:unofficial&client=firefox-a I accidentally hit "send" before finishing the message or attaching the output. I sent another message with more info and output attached. Thanks! Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Etch system frequently hanging - help to diagnose origin needed
Oops - I sent this before completing it. Let's try again. On Mon, Jan 22, 2007 at 09:32:00AM +0000, Julian Gilbey wrote: > I have a randomly recurring problem on my etch system which should be > diagnosed if possible - there's almost certainly a grave bug > somewhere. > > My computer keeps crashing in a weird way. > > I am running GNOME. I'm attaching the current output of ps aux; it > would have been very similar when the system crashed. What happened was that the screen froze and neither the keyboard nor mouse responded to anything. Rhythmbox continued playing for about another 30 seconds, and then it too stopped. I could not ssh into the box from an external machine either - the ssh command just hung. I left the computer on for about another 10 minutes, during which time cron wrote a cron job into /var/log/messages. Then I did a reset using the reset button (which resulted in a message from shutdown in the same log file). There was not other message in any other log file from that time period. This type of crash has happened several times in the last few weeks, and I have no idea how to track it down. Help please! Julian USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.1 1940 640 ?Ss 08:53 0:00 init [2] root 2 0.0 0.0 0 0 ?S08:53 0:00 [migration/0] root 3 0.0 0.0 0 0 ?SN 08:53 0:00 [ksoftirqd/0] root 4 0.0 0.0 0 0 ?S< 08:53 0:00 [events/0] root 5 0.0 0.0 0 0 ?S< 08:53 0:00 [khelper] root 6 0.0 0.0 0 0 ?S< 08:53 0:00 [kthread] root 9 0.0 0.0 0 0 ?S< 08:53 0:00 [kblockd/0] root10 0.0 0.0 0 0 ?S< 08:53 0:00 [kacpid] root74 0.0 0.0 0 0 ?S< 08:53 0:00 [kseriod] root 114 0.0 0.0 0 0 ?S08:53 0:00 [pdflush] root 115 0.0 0.0 0 0 ?S08:53 0:00 [pdflush] root 116 0.0 0.0 0 0 ?S< 08:53 0:00 [kswapd0] root 117 0.0 0.0 0 0 ?S< 08:53 0:00 [aio/0] root 329 0.0 0.0 0 0 ?S< 08:53 0:00 [kjournald] root 443 0.0 0.1 2492 924 ?S
Etch system frequently hanging - help to diagnose origin needed
I have a randomly recurring problem on my etch system which should be diagnosed if possible - there's almost certainly a grave bug somewhere. My computer keeps crashing in a weird way. I am running GNOME. I'm attaching the current output of ps aux; it would have been very similar when the system crashed. Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
madison not working correctly on merkel
I've noticed (and I'm not the only one) that the package database as access by madison on merkel is no longer up-to-date. Does anyone know why? Could someone rectify this situation, please? Thanks! Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Gnome crashing/freezing on testing machine
Hi all! I'm running an up-to-date testing machine. In the last week or so, GNOME has crashed several times, freezing the screen. While I can just about log in remotely (even that then hangs on several occasions), I can't even kill the GNOME process (kill -9 failed on several processes running under GNOME). That's really weird, and I've never seen this sort of behaviour before. Does anyone have any idea what might be causing it, or how I could diagnose this problem? I'm sure there's a grave bug somewhere here, but I haven't a clue where. I can provide lots more info if that is of use. Thanks, Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: behaviour of "bts show" command with new BTS default behaviour
On Thu, Nov 16, 2006 at 09:27:59AM -0300, Damián Viano wrote: > > I fixed bug#396232 in devscripts version 2.9.24. But when I went to > > http://bugs.debian.org/devscripts, it listed this bug among the open > > bugs. Why? Because m68k or some other arch had not yet autobuilt > > version 2.9.24 and was still on 2.9.22. However, the > > non-version-tracking page showed this bug as fixed. > > Yes, this is IMHO a little drawback, but doesn't seem terrible to me, > and I also consider good that maintainers are aware that the bugs are > not yet close on all archs. > > There has been comments whether the default unstable view should take > into consideration only release-archs or not, that's another topic but > might be related if you are mostly annoyed by non-release candidate > archs. I'm not so much annoyed by any particular arch, but if I want to see which bug I should work on next, I'm annoyed when bugs I've already fixed reappear in the "Normal bugs" list. In a separate email I've suggested that it would be good to have a separate category for "Pending autobuilding" or something for such bugs. Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: behaviour of "bts show" command with new BTS default behaviour
On Sun, Nov 12, 2006 at 03:50:46AM -0800, Don Armstrong wrote: > On Sun, 12 Nov 2006, Kurt Roeckx wrote: > > When using "bts show package" or going to > > "http://bugs.debian.org/package"; we get that behaviour, and I find > > both of them annoying. > > I switched the default to appending dist=untable because it actually > tells you which bugs affect unstable; it's far more informative than > merely categorizing based on whether a bug has been closed. If you > know you want something else, you really should be using the precise > url that you want. What I would then really like in this case is for the BTS to have a category on the list of package bugs called "Pending autobuilding" or something like that when asked for dist=unstable with no version number. This would be for the situation where the bug is fixed by version 1.1-4, but some architectures are still on version 1.1-3. (As a parallel, if I mark a bug as "pending", it disappears from the list of normal bugs and it is moved into a separate category. This is really helpful for knowing at a glance what is going on.) That, it seems to me, would be the best solution for most of the issues raised here. It does not seem possible to easily do this at the moment. Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: behaviour of "bts show" command with new BTS default behaviour
On Thu, Nov 16, 2006 at 12:56:32AM -0500, Theodore Tso wrote: > On Sun, Nov 12, 2006 at 01:02:06AM +0000, Julian Gilbey wrote: > > > > Thinking of changing the default behaviour of the devscripts "bts show" > > (aka "bts bugs") command, and want to ask for opinions before I do so. > > > > The BTS behaviour of http://bugs.debian.org/ has recently > > changed. It used to resolve to: > > > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg= > > > > which listed all open and closed bugs in the package, without any > > version tracking being taking into consideration in the listings. > > > > It now resolves to: > > > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=;dist=unstable > > > > which lists the status of all bugs in that package in respect to the > > version(s) of the package currently in unstable. > > I prefer the new behaviour, myself. If it must be changed, can it be > configurable via some kind of .btsrc file? Given the second half of your post, please let me clarify the new behaviour for you. I fixed bug#396232 in devscripts version 2.9.24. But when I went to http://bugs.debian.org/devscripts, it listed this bug among the open bugs. Why? Because m68k or some other arch had not yet autobuilt version 2.9.24 and was still on 2.9.22. However, the non-version-tracking page showed this bug as fixed. I'm not sure I'd like to make it configurable, as that could lead to much confusion and error. It is not particularly difficult to type 'dist=unstable' after the package name if that is truly what you want (which, I believe, is not likely to be the case for many maintainers). > Also, can we please have this functionality for "bts cache"? It takes > a *long* time to download a huge whackload of bugs, many/most of which > are already fixed in unstable, and so don't matter to me at all. Do you mean bug#340259? If you have a patch, please send it to that bug. Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: behaviour of "bts show" command with new BTS default behaviour
On Sun, Nov 12, 2006 at 01:15:21PM -0200, Henrique de Moraes Holschuh wrote: > On Sun, 12 Nov 2006, Julian Gilbey wrote: > > http://bugs.debian.org/397925). So the only thing within my ability > > is to change the devscripts bts command so that it behaves in the way > > it used to before the BTS change. > > Could you make it configurable? I like the "show unstable bugs" behaviour > far more for my DD work... but I can easily see how a "show stable bugs" > behaviour would make more sense for the packages goint into Etch now... Current bts can do this: bts show dist=unstable bts show dist=testing The only question is about the default behaviour of bts show . Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: behaviour of "bts show" command with new BTS default behaviour
On Sun, Nov 12, 2006 at 12:19:30PM +0100, Kurt Roeckx wrote: > On Sun, Nov 12, 2006 at 01:02:06AM +0000, Julian Gilbey wrote: > > Hi all! > > > > Thinking of changing the default behaviour of the devscripts "bts show" > > (aka "bts bugs") command, and want to ask for opinions before I do so. > [...] > > It now resolves to: > > > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=;dist=unstable > > When using "bts show package" or going to > "http://bugs.debian.org/package"; we get that behaviour, and I find both > of them annoying. > [...] > > I think the default of the bts when going to > http://bugs.debian.org/package should change back to the old behaviour, > and you shouldn't change the bts command. To clarify: I have no control over the BTS itself, and Don Armstrong rejected my request for the default http://bugs.debian.org/package behaviour to revert to its old behaviour (see http://bugs.debian.org/397925). So the only thing within my ability is to change the devscripts bts command so that it behaves in the way it used to before the BTS change. Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: behaviour of "bts show" command with new BTS default behaviour
Hi all! Thinking of changing the default behaviour of the devscripts "bts show" (aka "bts bugs") command, and want to ask for opinions before I do so. The BTS behaviour of http://bugs.debian.org/ has recently changed. It used to resolve to: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg= which listed all open and closed bugs in the package, without any version tracking being taking into consideration in the listings. It now resolves to: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=;dist=unstable which lists the status of all bugs in that package in respect to the version(s) of the package currently in unstable. I was confused by this, because bugs which I had just closed through an upload were still shown as open, because the autobuilders hadn't yet built the newest version on all architectures. But it does not show bugs only relating to experimental or stable versions. I would like to change the default behaviour of the bts show command, when used as "bts show " or "bts show " to behave as it used to do, by manually rewriting the URL to the earlier form before downloading. Before I make this change, I'd like feedback, please; if it's unpopular, I won't do it. Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why isn't gnome in testing?
On Thu, Jun 15, 2006 at 10:18:57AM +0200, Andreas Barth wrote: > * Julian Gilbey ([EMAIL PROTECTED]) [060614 10:54]: > > On Thu, May 11, 2006 at 10:32:36PM +0200, Andreas Barth wrote: > > > * Julian Gilbey ([EMAIL PROTECTED]) [060511 22:17]: > > > > Does anyone know why the binary package gnome is no longer in testing? > > > > The source package meta-gnome2 is there > > > > > > Seems like an accident currently. We're researching the matter. > > > > > > Cheers, > > > Andi > > > > It's still not in testing. > > fixed. > > Cheers, > Andi Yay, great thanks! Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why isn't gnome in testing?
On Thu, May 11, 2006 at 10:32:36PM +0200, Andreas Barth wrote: > * Julian Gilbey ([EMAIL PROTECTED]) [060511 22:17]: > > Does anyone know why the binary package gnome is no longer in testing? > > The source package meta-gnome2 is there > > Seems like an accident currently. We're researching the matter. > > Cheers, > Andi It's still not in testing. Bemused, Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why isn't gnome in testing?
On Thu, May 11, 2006 at 10:32:36PM +0200, Andreas Barth wrote: > * Julian Gilbey ([EMAIL PROTECTED]) [060511 22:17]: > > Does anyone know why the binary package gnome is no longer in testing? > > The source package meta-gnome2 is there > > Seems like an accident currently. We're researching the matter. > > Cheers, > Andi Cheers! Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Why isn't gnome in testing?
Does anyone know why the binary package gnome is no longer in testing? The source package meta-gnome2 is there Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Marking BTS spam
Just saw this thread mentioned on DWN. Do you know about "bts reportspam NN" or "bts spamreport NN" in the devscripts package? Might do just what you want :) Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
devscripts help: new script name?
I'm looking at bug#202866 (http://bugs.debian.org/202866), which proposes a small script for subscribing to the PTS for a package for a limited length of time. I'm somewhat at a loss what to call the script: my ideas are: pts-subscribe- but this might be misleading nmutrack - but that's not what this really does pts-timed-subscribe - messy but might work pts-limited-subscribe- confusing Anyone got any better ideas? Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336481: ITP: epix -- create mathematically accurate graphics with a C++-like syntax
Package: wnpp Severity: wishlist Owner: Julian Gilbey <[EMAIL PROTECTED]> * Package name: epix Version : 1.0.6 Upstream Author : Andrew D. Hwang <[EMAIL PROTECTED]> * URL : http://math.holycross.edu/~ahwang/current/ePiX.html * License : GPL Description : create mathematically accurate graphics with a C++-like syntax ePiX (pronounced like "epic" with a soft "k", cf. "TeX") is a collection of batch-oriented utilities for *nix, creates mathematically accurate line figures, plots, and movies using easy-to-learn syntax. LaTeX and dvips comprise the typographical rendering engine, while ImageMagick is used to create bitmapped images and animations. The user interface resembles that of LaTeX: You prepare a short scene description in a text editor, then "compile" the input file into a picture. Default output formats are eepic (a plain text enhancement to the LaTeX picture environment), eps, pdf, png, and mng. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
