Printing System Development Project
The "Printing" project is the development project
for packages which provide the base functionality
of the printing system.
The main intent of the "Printing" project is
to provide the newest kind of base printing software for
upcoming openSUSE and SUSE Linux Enterprise versions
and at the same time with same priority to provide the
same newest base printing software also for as many
released openSUSE and SUSE Linux Enterprise versions
as far as possible with reasonable effort.
Base printing software packages are in particular
print spooler software like CUPS,
printing filters like cups-filters,
printer drivers like HPLIP or Gutenprint,
printer driver related software like Ghostscript,
plain PPD files packages like OpenPrintingPPDs,
and other software which directly
belongs to the base printing system
like special backends for CUPS.
In contrast software which does not directly
belong to the base printing system like
user frontends (e.g. printer setup tools,
printing dialog GUIs, or other printing
related GUIs) or applications with a major
focus on printing (e.g. LaTeX or Scribus)
do usually not belong to the "Printing" project.
Of course only really free software can be
accepted in the "Printing" project.
In particular printer driver software which
is not 100% free software cannot be accepted
regardless how nice it would be when this
or that awkward printer model would work.
We will not risk any legal issue for openSUSE
and SUSE Linux Enterprise and our users and
contributors when software where the legal state
is not clear would be accepted.
An obvious precondition for any software is
that it is by default reasonably secure.
In particular for software that is run as root
(e.g. a setup tool or a special CUPS backend)
a security audit is usually required.
The "Printing" development project may contain
new software or work-in-progress changes of
existing software that might neither be in
a stable state nor fit well into currently
Have this in mind if you think about to install
packages from the "Printing" project into your
currently running system.
Do not use "Factory" if your system is not "Factory".
Use the matching packages for your particular system.
The packages in the "Printing" project are without
any guarantee or warranty and without any support.
As an extreme example, this means if your
complete computer center crashes because
of those packages, it is only your problem.
On the other hand this does not mean that those
packages are known to be terrible broken but
they are not thoroughly tested so that any
unexpected issue can happen.
In the end all software in the "Printing" project
are only applications which means that your system
should not "explode" when you upgrade with packages
from the "Printing" project (provided you use the
matching packages for your particular system).
If a new version does not work it should usually
help to downgrade (and to reconfigure as needed)
to get it working again.
When there are issues with the packages in the
"Printing" project we appreciate issue reports.
In this case see "How to Report a Printing Issue" at
In general see
In particular see
Therein in particular see the section
"How to submit a fix to a package"
If you like to contribute major changes
for a package in the "Printing" project
first and foremost get in contact with the
maintainers of the particular package or
the maintainers of the "Printing" project.
This avoids that you do major work on your own
which might not be accepted by the package
The openSUSE Build Service (OBS) web pages
show maintainers of a particular package and
the maintainers of the "Printing" project.
The RPM changelog shows e-mail addresses of
those who had worked on an installed package:
"rpm -q --changelog package_name"
How to contribute a bugfix or a version upgrade
for a package in the "Printing" project:
Branch from Printing/package_name so that you get
Do your changes in
For each change describe the change and provide
a reason why the change was done in the RPM changelog.
For example describe what does not work without the change
or what additional functionality is provided by the change.
Such a reason could be an URL to a bug report or
an URL to an upstream issue report.
When there is no URL you need to explain the change and
its reason in a way so that others who do not yet know
about it can understand what the issue is about.
For each change where external references exist
(like openSUSE bug reports or upstream issues)
provide URLs for all external references so that
others who do not yet know about the issues can get
all available details and background information.
still builds sucessfully for all build targets
where Printing/package_name builds sucessfully.
Download the built RPMs from
and install/update them on your own system by
using the plain 'rpm -U' command to verify that
they "just install" without any issues.
Verify on your system that the RPMs from
work for you.
Primarily verify that you do not notice any regression.
Any tiny manual additional adaption that you need
to make it work is considered to be a regression.
Of course you cannot test everything.
But you must verify that at least for you it "just works".
Maintain backward compatibility:
Verify that the RPMs from
work at least on the latest stable openSUSE release
which is currently openSUSE Leap 42.1 (based on SLES12).
I.e. you must test it at least on openSUSE Leap 42.1.
It is useless if it only works on openSUSE Tumbleweed.
See above for the main intent of the "Printing" project.
Finally you can do the OBS submitrequest from
The better your description of your change and its reason
is in the RPM changelog the more likely it gets accepted
by the maintainers of Printing/package_name.
In general submit early and submit often.
Do not mix up several independent separated issues
in one big all-in-one OBS submitrequest because
a submitrequest cannot be partially accepted.
When one of several independent changes in one big
submitrequest is not accepted by the maintainers of
Printing/package_name then the whole submitrequest
must be rejected (declined).
On the other hand do not split several changes that
belong to each other into several submitrequests.
For example submit a package version upgrade
together with all additional changes that are
required to make the new version "just work"
in one single submitrequest.