python-raydriver 0.2.0-1

Package Information

Description	Rust-native machine drivers for Rayforge raydriver provides machine-control drivers implemented in Rust and exposed to Python through PyO3. It currently includes a GRBL serial driver with flow control, status polling, command queuing, job streaming, recovery, cancellation, settings, work-coordinate access, and probing support. This package provides the Python 3 module and the raydriver command-line program.
Maintainer	Debian Python Team <team+python@tracker.debian.org>
Changed By	Michele Cane <michele.cane@proton.me>
Sponsor	jcfp@debian.org
Distribution	unstable
Architecture	any
VCS	git: https://salsa.debian.org/python-team/packages/python-raydriver.git (browse)
Closes	#1150266
Tracker	https://tracker.debian.org/pkg/python-raydriver
Uploaded	3 hours ago

New Package Report

.changes◂

Changed-By	Michele Cane <michele.cane@proton.me>
Architecture	source amd64
Distribution	unstable
Date	Thu, 05 Nov 2026 07:55:16 +0000
Source	python-raydriver
Version	0.2.0-1

Changelog◂

python-raydriver (0.2.0-1) unstable; urgency=medium
 .
   * Initial Debian packaging. (Closes: #1150266)

.dsc◂

Section	python
Priority	optional
Component	main
Package-List	python3-raydriver deb python optional arch=any

debian/copyright◂

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: raydriver
Upstream-Contact: https://github.com/barebaric/raydriver/issues
Source: https://github.com/barebaric/raydriver

Files: *
Copyright: 2026 Barebaric
License: MIT

Files: debian/*
Copyright: 2026 Michele Cane <michele.cane@proton.me>
License: MIT

License: MIT
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
 in the Software without restriction, including without limitation the rights
 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 copies of the Software, and to permit persons to whom the Software is
 furnished to do so, subject to the following conditions:
 .
 The above copyright notice and this permission notice shall be included in all
 copies or substantial portions of the Software.
 .
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.

DFSG Assistant LLM REVIEW 0 blocker, 2 important, 1 minor

This is an LLM based review using a Debian Inference based workflow. It was not written by a member of the DFSG team and has not been checked by one. It is not a decision on the package: it may be wrong, and it may have missed things.

Reviewed 1 hour ago.

Report◂

DFSG NEW review for python-raydriver version 0.2.0-1

Summary

Licensing is DFSG-compliant and debian/copyright is accurate: Yes
Packaging is of good quality: No
Issues: 0 blocker, 2 important, 1 minor
debian/watch: version 5
debian/copyright: machine-readable
Scan before the review: nothing found

Licensing

debian/copyright is DEP-5 (Format 1.0) with Files: * (2026 Barebaric, MIT), debian/* (2026 Michele Cane, MIT) and a stand-alone License: MIT that carries the full MIT text, matching the top-level LICENSE. A whole-tree search (hidden files included, .pc/ skipped) for copyright notices and for licence wording found nothing in any other file: no per-file headers, no vendored third-party sources, no non-free terms, no binaries, images or fonts. Every file is therefore covered by the MIT grant, and MIT is compatible with everything the package links. The only loose end is provenance: the code calls itself a port of Rayforge's driver, whose licence and holders cannot be checked offline (see Not confirmed).

Packaging

The build wiring is careful and modern: compat 14, pybuild with the PEP517 plugin driving maturin, the dh-cargo wrapper used the way its own documentation prescribes (python3:native, cargo:native, buildflags exported, DEB_CARGO_CRATE, prepare-debian), autopkgtests for import, the test suite and the CLI, and every Build-Depends verified to exist in unstable. Two faults remain, both in cleaning: debian/clean's two directory entries lack the trailing slash, which makes dh_clean abort debian/rules clean, and cargo's target/ is never removed, so clean does not undo the build (Policy 4.9). A third, minor, point is the amount of stray material shipped in the tarball, which the packaging works around in two places.

Issues

important packaging 1. debian/clean lists debian/cargo_home and debian/cargo_registry without a trailing slash, so dh_clean aborts debian/rules clean ◂

Files: debian/clean:2-3, debian/rules:21
Basis: checked, in the package or with a reference tool
Evidence:

debian/clean:
```
Cargo.lock.saved
debian/cargo_home
debian/cargo_registry
```
/usr/bin/dh_clean sorts the entries by trailing slash (push(@requested_clean_files, grep { !m@/$@ } @clean);) and then refuses the file list if any of it is a directory: my @dir_in_clean_files = grep { ! -l && -d } @requested_clean_files; ... error("If the removals of these directories were intentional, ensure it ends with a trailing slash."). Both paths are created as directories by cargo prepare-debian (os.makedirs(registry_path, exist_ok=True), os.makedirs(cargo_home, exist_ok=True) in /usr/share/cargo/bin/cargo), which debian/rules:21 runs before the build.
Problem: After any build the two directories exist, so dh_clean treats them as files to delete, finds directories instead and dies. debian/rules clean then fails, taking with it gbp buildpackage's post-build clean and any dpkg-buildpackage -S/-sa on a tree that was built, so the tree cannot be cleaned or made into a source package.
Fix: Give the two directory entries their trailing slash (debian/cargo_home/, debian/cargo_registry/) and add target/ at the same time.

important packaging 2. cargo's target/ build directory is never removed, so debian/rules clean leaves the compiled binaries in the tree ◂

Files: debian/clean:1-3, debian/rules:17-35
Basis: inferred from what was read, not seen directly
Evidence: pybuild builds the wheel in the source root: {interpreter} -m build --skip-dependency-check --no-isolation --wheel --outdir ... (dhpython/build/plugin_pyproject.py, build_wheel), and the dh-cargo wrapper adds --target $(DEB_HOST_RUST_TYPE) and writes a config.toml with [profile.release] debug = true, so cargo's default target directory target/<triple>/release/ is created below the top level. pybuild's clean removes only .cache .coverage .hypothesis .pdm-build .pytest_cache (dhpython/init.py:85-92) and build; debian/clean names only Cargo.lock.saved, debian/cargo_home, debian/cargo_registry, and debian/rules has no rm -rf target.
Problem: Policy 4.9 requires the clean target to undo the effects of build and binary. target/ holds the whole release build (rlibs of every crate, the cdylib, debug info), so a source upload made from a tree that was also built packs all of it into the .debian.tar.xz, and a later build runs against a stale tree.
Fix: Add target/ to debian/clean, or remove it in an execute_before_dh_clean hook.

minor packaging 3. The tarball ships stray files (Cargo.toml.bak of version 0.0.0, PKG-INFO, an empty freeze-dump.txt, env.sh with a /root path) and debian/rules works around two of them ◂

Files: Cargo.toml.bak:3, PKG-INFO:1-8, env.sh:3, freeze-dump.txt, debian/rules:30-35
Basis: inferred from what was read, not seen directly
Evidence: Cargo.toml.bak says version = "0.0.0"; PKG-INFO is sdist metadata (Metadata-Version: 2.4, Name: raydriver); env.sh is export PATH=/root/projects/rayforge/.pixi/envs/default/bin:$PATH plus conda host tools; freeze-dump.txt is empty and is the file tests/conftest.py:24 hands to faulthandler. debian/rules then shields the .bak from dh_clean's *.bak sweep (dh_clean -X Cargo.toml.bak) and deletes a freeze-dump.txt that the test step leaves in the installed tree (-name freeze-dump.txt -type f -delete).
Problem: These are build and test by-products and a machine-local script, not source. They cost nothing at runtime, but the two workarounds keep matching by name, so if upstream ever ships a real Cargo.toml.bak or a file called freeze-dump.txt the rules silently preserve or delete it.
Fix: Repack the tarball without them (Files-Excluded in debian/copyright) and drop the two workarounds, or ask upstream to remove them from the sdist.

Verified ◂

debian/copyright is DEP-5 with the exact Format URL, three paragraphs (Files: * 2026 Barebaric MIT; debian/* 2026 Michele Cane MIT; stand-alone License: MIT) and no Files-Excluded; the stand-alone text is the MIT text of the top-level LICENSE, and MIT is not in /usr/share/common-licenses, so shipping it is required and done.
A case-insensitive search of the whole tree, hidden files included and gitignore: false, .pc/ skipped, for Copyright, (C), ©, SPDX-License-Identifier, Licensed under, Permission is hereby granted, GNU General|Lesser|Affero, Apache License, Mozilla Public, public domain, All rights reserved, CC and non-commercial/no-modification wording matched only LICENSE and debian/copyright; no other file carries its own copyright or licence notice.
The prescan reported that every holder it found is already named in debian/copyright; the only holder in the tree is Barebaric (LICENSE, PKG-INFO, debian/copyright) and the only other is the packager for debian/*.
No embedded third-party sources: there is no vendor/ directory and no debian/cargo-checksum.json; Cargo.lock only names the crates that are linked from the archive, whose permissive licences (MIT/Apache-2.0/Zlib) do not make Built-Using necessary under Policy 7.8.
The *.pyi files are generated and their generator is in the tree: src/bin/stub_gen.rs, make stubs (cargo run --bin stub_gen) and pyo3-stub-gen in Cargo.toml; python/raydriver/**/py.typed are empty markers.
freeze-dump.txt (0 bytes, top level) is the dump target of the test watchdog in tests/conftest.py:24, not a data file; the copy the rules delete is the one pybuild's test step leaves in its build directory, which pybuild then installs (dhpython/build/plugin_pyproject.py unpacks the wheel into build_dir, runs pytest there, then installs that directory).
Every file in the tree is text (Rust, Python, TOML, YAML, markdown, a manpage); there are no images, fonts, sounds or other opaque binaries to judge.
All Build-Depends exist in unstable: dh-sequence-single-binary is provided by debhelper 14.5, pybuild-plugin-pyproject (7.20261030) depends on python3-installer, python3-maturin is 1.16.0, librust-pyo3-stub-gen-0.23+default-dev is provided by librust-pyo3-stub-gen-dev 0.23.0-1.
Standards-Version: 4.7.4 against Policy 4.7.4.1 — current enough, not an issue.
The dh-cargo wrapper is used as its own documentation prescribes: the wrapper is a Python script and python3:native is in Build-Depends, cargo:native provides it, and export CFLAGS CXXFLAGS CPPFLAGS LDFLAGS, DEB_HOST_RUST_TYPE, DEB_HOST_GNU_TYPE, CARGO_HOME=debian/cargo_home and DEB_CARGO_CRATE are all set; cargo prepare-debian writes the registry source replacement and puts LDFLAGS (relro/bindnow) into rustflags.
debhelper compat 14 with dh $@ --buildsystem=pybuild: no Depends field is needed in debian/control for the relationship substvars, dh_python3 emits python3:any, and dh_auto_test is skipped under nocheck without a check in the rules.
Autopkgtests: import (superficial), pytest (copies tests/ and pyproject.toml, runs the suite for every py3versions -s) and cli (raydriver --help, raydriver status --emulator --seconds 0.1, no hardware); their Depends match what they use.
The DEP-3 patch has Description, Author, Forwarded and Last-Update headers and only relaxes two crate version ranges; series lists it alone; .pc/ confirmed applied and was not read.
Read in full: debian/changelog, control, rules, clean, copyright, gbp.conf, python3-raydriver.docs, python3-raydriver.manpages, manpages/raydriver.1, source/format, upstream/metadata, salsa-ci.yml, patches/, tests/. debian/watch was not reviewed, as instructed.
uscan found upstream releases with debian/watch; a newer upstream version is available (upstream 1.0.0, packaged 0.2.0), which is not a fault of the package.

Not confirmed ◂

Provenance of the ported driver: src/grbl/session.rs:5 says "This is a faithful port of Rayforge's GrblSerialDriver", README.md:6 says the crate "provides a full port of Rayforge's advanced GRBL serial driver", and AGENTS.md:47-49 requires byte-for-byte behavioural parity with rayforge/machine/driver/grbl/grbl_serial.py. Nothing in the tarball states Rayforge's licence or its copyright holders, and they could not be looked up offline. Both projects are the same author's, so the MIT grant is probably his to give; but if Rayforge is copyleft and has other contributors, the Files: * MIT claim and the single holder would both be wrong. A Comment: on the Files: * paragraph recording the port and its origin would settle it.
The package could not be built or the test suite run here; the clean findings rest on dh_clean's and pybuild's own sources, not on a build log.

Proposed changes ◂

None.

Uploader's response to the LLM review

The uploader was emailed about the review 1 hour ago.

Back to Dashboard | View all reviews for this package