Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial support for IPP / driverless printing #2332

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft

Conversation

deeplow
Copy link
Contributor

@deeplow deeplow commented Dec 13, 2024

Changes export logic (in sd-devices) to be able to detect IPP printers without breaking compatibility with the old system.

To achieve this, ipp-usb is used in combination with Avahi. The former detects IPP-compatible printers and creates a local IPP server. Avahi allows for the discovery of these printing servers such that print dialogs can display print information.

Contrary to the legacy printer support, for driverless printing, no print queue is setup with lpadmin. Printers are automatically discovered.

Status

Work in progress

Description

Fixes #2088 #2156.

TODO:

  • Find a way to have avahi enabled (preset as enabled is not cutting it)
  • add print dialog code (and get PyGObject wheels to build) (used system packages in venv instead)
  • handle exceptions
  • add tests

Test Plan

  • add cups and avahi to sd-devices Qubes services

Checklist

If these changes modify code paths involving cryptography, the opening of files in VMs or network (via the RPC service) traffic, Qubes testing in the staging environment is required. For fine tuning of the graphical user interface, testing in any environment in Qubes is required. Please check as applicable:

  • I have tested these changes in the appropriate Qubes environment
  • I do not have an appropriate Qubes OS workstation set up (the reviewer will need to test these changes)
  • These changes should not need testing in Qubes

If these changes add or remove files other than client code, the AppArmor profile may need to be updated. Please check as applicable:

  • I have updated the AppArmor profile
  • No update to the AppArmor profile is required for these changes
  • I don't know and would appreciate guidance

If these changes modify the database schema, you should include a database migration. Please check as applicable:

  • I have written a migration and upgraded a test database based on main and confirmed that the migration is self-contained and applies cleanly
  • I have written a migration but have not upgraded a test database based on main and would like the reviewer to do so
  • I need help writing a database migration
  • No database schema changes are needed

Changes export logic (in sd-devices) to be able to detect IPP
printers without breaking compatibility with the old system.

To achive this, ipp-usb is used in combination with Avahi.
The former detects IPP-compatible printers and creates a local IPP
server. Avahi allows for the discovery of these printing servers
such that print dialogs can display print information.

Contrary to the legacy printer support, for driverless printing,
no print queue is setup with `lpadmin`. Printers are automatically
discovered.
Note: system-wide dependencies made available from
securedrop-export venv due to the need to access python3-gi.
Otherwise it would require too many build dependencies and complexity.
Given that python3-gi is already required by some Qubes components,
it does not add too many new dependencies.
@deeplow
Copy link
Contributor Author

deeplow commented Jan 13, 2025

Progress update

I have now added the GTK dialog itself. As you can see it gets information from the printer before it shows the options. It's a bit of downside of driverless printing when the printer was not previously added. The user has to wait a tiny bit until the printer configurations are obtained. There are ways around that (i.e. adding a print queue), but that requires state, which we're avoiding in disposables. (we decided that here)

20652


Next steps

I have updated the TODO list on the first post

@deeplow
Copy link
Contributor Author

deeplow commented Jan 13, 2025

@legoktm regarding the following comment:

# In production these two are installed using a system package
# so match those versions exactly
pygobject = [
{version = "=3.42.2", python = ">=3.11"}, # bookworm
]
pycairo = [
{version = "=1.20.1", python = ">=3.11"}, # bookworm
]

How critical is is that we keep this in sync? Should some sort of CI warning to update this when the debian packages have been updated? How is it handled for Qt in securedrop-client?

Also, do we need it in the root pyproject.toml? It's causing problems in the CI / safety (could be because it's asking for a later version).

@legoktm
Copy link
Member

legoktm commented Jan 13, 2025

How critical is is that we keep this in sync? Should some sort of CI warning to update this when the debian packages have been updated? How is it handled for Qt in securedrop-client?

Relatively important, mostly so that our local operation and tests are using the same version that the package is. Realistically the version should only change when we switch Debian versions (e.g. bookworm -> trixie), so we can handle it then. It would be pretty rare for a version bump to come out once a version has already been made stable.

Also, do we need it in the root pyproject.toml?

No, just in export's. The only things in the root pyproject.toml should be the various CI tools we run across the whole project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Print: Find alternative to PPD
2 participants