Welcome to the only talk of this time span
I am glad that I am the only one talking
and I hope I will somewhat interesting [laughs]
That's a very good honour to be the only one talking
I just wanted to do a status report of the Debian Printing team
because it's been quite a long time, I've been working on this part of Debian
and I've tried to attract people into helping me for printing in the last years
and it hasn't really worked.
So I'll just do another attempt and see what that gives
and hopefully give you some insight on how the whole thing works
A little introduction about me;
I'm a Swiss guy, I was basically grown up with computers
If you followed my talk from last year,
I showed you some of the Swiss computers back then
and some Motorola 68k Swiss-specific stuff that I was basically born with.
I am currently working at Liip, CH.
It's a Swiss company that has websites
and I'm working there as an eLearning specialist,
webapp backender and sysadmin.
Whatever that means.
Towards Debian, I've been translating things
at the Ubuntu site since 2005,
maintaining packages since 2009.
I've been a developer since 2011
and I've been maintaining some packages since then.
That's not the most interesting part of the talk
so let's go forward.
This session's intent is to present the state of the Debian printing stack,
its evolution until today, the leftover work
and also how I got trapped into maintaining that part of Debian.
I mean, I don't have a particular interest in printers
but, yeah.
How you can help!
So let's dive into the past
If you have questions, just raise your hand and interrupt me
Don't feel shy
It started in June 2010, I adopted foomatic-filters
because it was severely outdated
There was no upload for a year, missing 5 new upstream releases
We were lagging severely behind Ubuntu
and the maintainer was quasi-MIA
Typical case for adopting a package some months before the freeze.
I was kind of looking for things to help the freeze out
and this was broken on my machine,
that's were the trap was working me first.
It just made it into Squeeze because I did the upload
3 hours after the freeze was suprise announced at the DebConf then
So I managed to get it through, somehow.
But that was the only package I was maintaining there for Squeeze
Then in July, I sent this Request For Comments
for forming a printing task force
to various mailing lists
the cups maintainers list, et cetera
to see if it was possible to gather some people
around maintaining the whole printing stack under a team umbrella
because before that it was just sets of packages
maintained by individuals on their own side of debian
This thing was kind of working
but as soon as people went MIA
or just had other interests then the packages were rotting.
Then I started integrating the Ubuntu delta into Debian
because Ubuntu apparently had more need than Debian
to have a working printing infrastructure then.
and they had been fixing this stuff on their site.
It's interesting to take a look at the Ubuntu delta
in the first place, why there was one.
One argument for that is that the updates were not proposed
back to Debian at all
No patches to enter to the bug tracker
no other was than just looking at the packages in Ubuntu
and seeing there were updates there
so I should maybe take the patches back
but there was no upward communication.
On the other hand, the packages were not getting
any or much attention in Debian, either.
No one was actually taking a look at this diff
and making sure that things were working.
It was working for some parts but there were many bugs still.
But it's still free software
so patches were sitting there
you had a nice link from the PTS to get one big patch
you could apply to the Debian package
and you could just integrate that.
The patches were available.
It was not that bad.
The work started at the beginning of the Wheezy cycle
around 2010 or 2011
by basically adopting new packages
and polishing the Ubuntu changes
like taking one change at a time
making one clean commit out of that
and uploading releases one after another
integrating new upstream releases
and all good, no?
Well, not exactly
because the dependency stack was at that time a little complicated, so to say.
because every package was liking against its dependencies
and some of the drivers had been promoted to the print server task.
So the print server task was pulling like, hplip and gutenprint
but not other drivers for some reason
and it was pulling cups
and cups was pulling poppler
and then, yes, that basically.
You can go on the wiki page to revise history
but basically that was what was there when I was cleaning up the stack.
I started discussing the thing on the list
and we were like 2 or 3 and many people were agreeing with the thing
but I was not many for doing the thing [laughs]
So I started cleaning up the dust
renaming the drivers,
now all printer drivers are namespaced somehow
they all start with the same binary name
reworking the dependency tree
making sure you have a printer-driver-all that just recommends all available
drivers that the print task can depend on.
So, by default you get all available free software drivers
just in case you might want to install a printer.
There is this pyppd,
that is a compressor that would take the pdd files
and turn them into an xz compressed python script
that will uncompress itself into pdds
that basically allow disk space reduction of 80%
That was written during a Google Summer of Code
and I just wrote the dh wrapper around that to automate that for the printing
packages
so if you put the ppd files in the right place
and run that tool, it will just do the compression
and replacement and removing in the right place.
We have moved all of the packages to git
because some of them were in no VCS
some of them were in SVN
I don't we had any in CVS
but moving to git was a good thing
in collab-maint by then because I didn't have the interest in making a proper
team namespace
I wondered if it was easier just to put everything there
and what might happen is that someone would be interested in putting patches.
That didn't happen.
We hijacked the debian-printing list,
because no one was using that
and it was totally logical to use that
as a maintainer list, to have everything in the same place.
and cleaning out dependencies, apparently that was twice on the slide.
During that time, we managed to package all known free software drivers.
There were some laying around that were not packaged,
some that were a little complicated to package.
I tried to search through OpenPrinting and whatever
and find some others that were not packaged
that were maybe supporting one or two printers.
I wondered, it was probably good to have them in Debian anyway
could be useful to one or two users.
Consolidated the foomatic packaging
and caught back on upstream versions.
I think in wheezy we had most of that.
But there's still cups.
cups is like the thing you don't really want to touch when you do printing
because that is the complicated part,
everything else is just drivers, filters and small programs
It's easy when you start packaging,
small things in different languages
It's funny.
But cups is a little frightening.
So I wondered, cups is one big thing
and it has an Apple upstream,
it's not really the thing you want to touch.
cups is not really known for the super whatever free software friendly.
The wheezy freeze was upcoming and cups hadn't seen uploads for a year
so I started fixing one thing after another
and I started uploading NMUs
I ended up doing 16 NMUs in a row
Not every NMU got the freeze exception request
but almost all of them
So for each of the NMUs, there was a discussion
with the release team all of the changes that would enter wheezy.
Yeah, that.
In 2013, cups was especially made complicated
by the fact there was no public VCS.
There used to be an SVN but it was down for some reason.
There also used to be a public bug tracker,
but it was down for some reason.
The few contacts I had with Apple
was just over private mails
because they had no mailing lists,
or it was closed or it was down.
So not exactly the upstream you are very fine working with
It's just a black-hole, you get a new tarball
No changes, you get a Changelog, but you don't get the individual changes
and of course the package back then had no test suite working, no autopkgtest
So, yeah, that.
But finally after doing 16 NMUs, I thought to myself,
Yeah, what does that mean? The real maintainer would not get back to
uploading that for the stable release so I might as well just update
and we'll see what happens.
So apparently the trap worked.
I ended up with one more big package, that's cups.
So where do we stand now?
If you run sid, you probably have most packages
that are in there are the most recent upstream version.
In the last year, we moved from collab-maint to printing
because it's now easier because now I'm a DD
so I could easily create a new alioth group
and we thought it's also easier to see who was actually still in the team.
We sent out the mail to various persons that had contributed and asked them to
request the membership in alioth
The ones that are just MIA don't request and they're not members
So that the list on alioth is somewhat relevant
We kind of managed to maintain the bug flow at a reasonable level.
I started, there was like 400 bugs and now we are around 300
but that means also that the new bugs are addressed within a reasonable delay,
somehow.
So now, the FLOSS drivers are in Debian
There was a new one, I think 3 months ago,
some guy did a driver for 2 or 3 Brother printers
that just works currently.
So we packaged that and it's in Debian.
Also the Ubuntu diff is kept minimal
we've integrated some of the Ubuntu specific changes
into the Debian packaging just to avoid have them creating a new diff
or maintaining a diff over time.
We could do that easily with dpkg-vendor for example
The package is the same,
just at build-time it will do different things
So for example, the default pdf page is different
and the two pages are in the Debian package
but when you build it on Ubuntu you get the Ubuntu page.
It has the advantage that the Ubuntu
employees don't have to maintain that patch over time
We manage to get the diff to zero, sometimes
Sometimes, you just see a peak in Ubuntu
because they want to be to faster than the music
and they do their stuff.
That's the bugs for all printing packages
it's not that bad.
I had to do actual work, for my work
in July and August it rose a little.
For cups, as you might have noticed if you're googling it now
we've gone from 1.5.3 in Squeeze
to 1.7.5, now in Jessie.
So it's two minor upstream releases
with quite a lot of changes
and I think we packaged all intermediate versions
and it's not bold to say that Wheezy will release with a minor version of 1.7
I mean Jessie, yes. Thank you.
I'm getting old!
We've enabled the full testsuite
so lots of patches within the testsuite
but not for disabling things, mostly for ignoring things in the error logs
because cups' testsuite will count the number of errors in its error log
so you have to take things out so that the count always matches
autopkgtest is basically printing to /dev/null
but we test that this continues to work when other parts of the archive change
so printing to /dev/null works
Good news!
We've patched in the systemd socket activation and activity timeout
The socket activation was originally from Lennart
and then changed by Gentoo to not have that mandatory,
because Gentoo also has sysvinit
where Red Hat just has systemd so they don't have an option at runtime
to either activate or deactive the socket activation
So it's a mix of the Red Hat patch and the Gentoo patch
plus cleaning, of course.
The activity timeout was from Ubuntu
Basically now in sid if you run systemd, or upstart
after 30 seconds of not doing anything the cups server will shutdown itself
and doesn't do anything and when you print something or access the web
interface over the 6631 port, it just launches itself in a part of second
and prints and then after 30 seconds shuts down again.
As for upstream, we have regular good and constructive contact
with upstream.
They have again a public VCS, bugs repository
so we can actually communicate on the public place
and have the various changes also as individual units
so it's quite easier then.
As for the constructive contacts,
I also have good private emails with Mike
Michael Sweet from Apple
about this GnuTLS vs OpenSSL discussion
we had in debian-devel some months ago
because GnuTLS introduced some incompatibilities
So I thought we could just build against OpenSSL
No problem, cups has the GPL 2 exception
and it was rightly pointed out that every package
that uses libcups2 also needs the GPL 2 exception for OpenSSL.
So it wasn't really possible.
So we had that discussion and actually
upstream was interested in finding a solution
eventually patching in another SSL library
if that would help the Linux distributors
It was kind of surprising to me that Apple would be doing that
but they were! I must say, so that's good.
Now we dropped the OpenSSL and it just builds the latest GnuTLS version
The Linux Foundation still needs to maintain several things
that got dropped from cups
That is one drawback of having cups owned by Apple is that
they basically dropped everything that was not interesting for them.
So they want to just make sure you can print on Apple certified printers
and the rest is left up the community.
So the Linux Foundation took over the cups filters
and the cups broadcasting management,
so you can announcement between cups servers
to get the queues in your local queue, et cetera
So that's taken over by the Linux Foundation
I'm thankful they do that job
I'm happy I don't have to do it myself
because it probably wouldn't work
and Till Kamppeter is working with them making that happen,
so I'm glad he does and thank you.
We also have some people helping,
I would like to thank Brian Potkin in particular
for being precise, tireless and helpful
I don't know if he is at DebConf
but he's been participating on the list quite a lot
for tracking down some bugs
reporting some useful bugs
preparing some patches also.
That's been useful.
You might have seen from the list of packages
we also have packages that I don't maintain myself
but that are also in the Debian Printing team;
we have Jonas for ghostscript and IJS,
c2050 by Marco,
cups-bjnp by Joe,
min12xxw by Stefan
and tea4cups by Mike.
Those packages don't move very often,
but when they do we have updates.
So it's good.
In other parts of the stack, we still have hplip
that is maintained indepedently by Mark Purcell.
That also gets updated regularly so it's fine.
and cups-pdf by Martin-Ăric
which is apparently working too.
So thanks!
For the future; scoping the problem,
non-free plague and some incoming challenges.
The problem of printing is that it's still a must-be of our world.
When you discuss with people some people say cups is really shit,
we could just drop that from the default installation.
Well you know, people still print
The non-paper world is probably in the advertisement
but it's not there at all.
Printing when it works is boring,
it just has to work.
But when it doesn't, it's really annoying.
So it's that type of technical challenge that
you will only get complaints when it doesn't
and when it does everyone is happy, no bugs, nothing, it just works.
And that's fine.
On the other hand, printing is damn complex.
Printer manufacturers come up with new protocols every 3 months basically.
They can even change printing protocols
within the same product suite, for some reason.
You get different IPP versions, PCL support
different memory requirements
now you can directly feed PDFs to printers
but the printers will sometimes fail
because the internal PDF rendering will fail for some reason
so you have to circumvent that in the printer drivers
You also have different sending protocols,
AirPrint, the Google cloud print is coming,
we have now IPP over USB for some printers
It's like an ever changing landscape for printing
It's a thing we've been doing for years
and it's still changing for some reason.
It's complex also because it takes any format as input;
you can print images, Word documents, PDFs, PostScript
and you have to make sure that's transformed to whatever
the printer is ready to get.
Sometimes that's PostScript, sometimes that's PDF,
sometimes it's a raw whatever, sometimes it's a bitstream.
So we have complex chains
and one of the biggest problems is that when a user has a problem,
the probability is 1 that you don't have the printer.
I mean, I have one printer at home
I test it when I do new uploads
and I just print the test page and that works
but when a guy has a problem on a printer, I don't have it.
So it's quite hard to reproduce.
There's still IP in the drivers
We have full manufacturer suites that have no acceptable FLOSS support.
I'll do some fingerpointing now.
I hope this is not video-taped.
Oh shit.
We've had this project from Debian France
they were basically offering books for people
that would be happy to contribute to something
and I mentored two guys to take a look at what Brother is doing with the drivers
I invite you to go there, the documentation is quite extensive
and they tried to see how we could package that even in non-free
just to consolidate the thing and have a somewhat clean dump of files
even in non-free so that we could install that
instead of downloading a 2002 .deb, that has no debsums
But the web page layout changed in the middle of the project.
They just revamped the website.
So we had a crawler that would get the various drivers and it just changed
completely, in the middle of the project.
For some printers you have two different versions
Either for SI or imperial units.
Because, I don't know, the printers has different physical size
or I don't know.
You have C-shell all over the place,
I don't think we have any valid C-shell interpreter yet in Debian
For many drivers, there is no co-installation possible
because they used the same named files with different contents
in the same place
So you need a different file with the same name, the same place
for two different printers.
So basically you can even print to one or the other
but not to two at the same time.
It still uses printcap, that's been deprecated
since at least Etch, I didn't check
but something very old.
There are a lot of bugs all over the place
it's loads and loads of shell code that would unpack
parts of PPD files to generate files to put in other places,
download things from the Internet...
A whole load of crap, frankly.
But we should not only finger point at Brother
at Samsung they are doing exactly the same, or worse
I didn't take a look at that precisely
but the Brother project was quite frightening
and I don't think we will ever do something useful there.
I don't know if that's, I don't know.
[??]: I seem to remember a Samsung printer driver installer
from some years back
that would require applications printing
to run as root
setuid flag on certain applications so it might be used for printing.
[Didier]: I'm not surprised.
That's the dark corner we don't to see.
There are free drivers that work quite well
and there are a whole lot of things in the dark corner
that, you don't want to buy these printers
because there's no way to make them work reasonably
unless you download a some very very rare old Debian package,
fix the debsums inside and something like that.
For Jessie, new things:
ghostscript moved to AGPL,
that makes some people very happy.
so what we'll probably do is upload the latest non-AGPL version
and have that in Jessie
and we'll probably see what happens then
because we release soon and it's quite a complex problem
we won't have time to fix that before.
So, we'll move some versions up
but not to the latest upstream version.
Apparently we're the only ones to care,
all the other distributions have uploaded the AGPL version and it's there.
CUPS 2.0 is around the corner,
we hope it will get there by the end of the year.
It introduces upstream systemd support,
TLS certificate validation,
maybe it's time for us to do that!
They moved to OpenSSL support
and many OSX enhancements,
whatever that is useful for us.
Expect 2.0~beta1 in experimental in the next weeks/months,
we'll see.
So what you can do.
Frankly, I'm getting bored by all that.
It's been years now, I've been maintaining the printing stack.
Not exactly alone, but for some parts quite alone.
It's true to say that I've got quite a lot of
collaboration with Ubuntu to make that work.
There are many things that I just have to
patch back into Debian and it just works
but it's sometimes a little boring to do that all alone.
I'm glad others are helping in the team
but for the most part, particularly cups,
it's not that easy.
But it's not too complicated, believe me.
Trust me!
One point is, I'm very bad at motivating people
or documenting the processes.
For example the Teams page on the wiki,
I probably edited it twice, once in 2010
and once last year for the printing BoF
and it's still sitting there with not many updates
So someone motivated by processes documentation should jump on the ship
and do some stuff there.
This talk was an attempt at motivating people, at least
So we'll see if that works.
On the long-term;
what we need is move drivers writers bascially
because there are tons of printers that come out
that don't get full support and that people use, basically
and the problem is not making sure everyone can buy the printer they want
people will have printers they have there and they want that to work
and it doesn't.
So we need people to actually write drivers for printers.
We need more bug triagers,
that they become wanna-maintainers, hopefully.
and less bugs, pretty please.
We can achieve less bugs two ways;
by fixing more bugs or by introducing less bugs.
So maybe we should do the two.
That's all from my little Debian Printing stack status.
If you have questions, I am happy to try to answer them.
Otherwise, I think we can all move to dinner!
[Wookey]: I'm a bit interested in printing
because we have lots of corporate printing
which doesn't work because it's all run for Windows people.
So the poor Linux people are thoroughly ignored
and in fact if we print to the printers, they tend to crash!
Which is a bit sad
and people complain that the printers are very unreliable
and actually it's us [laughs]
There's a fifty percent chance of things exploding
But what I haven't been able to find is
where do people that have to worry about corporate installations hang out?
I couldn't find anywhere to ask questions
because our IT people go:
"We don't know how it's supposed to work in Linux-world,
we have no fucking idea.
Please tell us what to do and we'll do that"
and I don't know anything about printing,
or who to ask, or where to go.
Is there a place?
There must be lots of people who have big installations
and there must be some people who understand how this works
[Didier]: The debian-printing list is not that much use
it gets the automated mails from the maintainers mails
so we could drop that if people started to use that.
That would be one option, I think you should look into
OpenPrinting and if no list exists there
they should probably create one.
I think they have one, they have summits
and they have meetings for whatever printing related-
[Wookey]: Somewhere on the OpenPrinting site,
would be a good place then?
[Didier]: Yes, I think.
[??]: Hi, I was just wondering if you would comment on-
What's your perspective on backports things like that.
So once we go stable, how do you see supporting the printing stack
for 2 years/5 years, however long stable's going to be out there.
[Didier]: There are two answers for that;
one is, there's quite a lot of security work to do for stable already
and we had a, I think, privilege escalation in stable.
So we had to revamped the whole configuration system in stable, for cups,
during the wheezy cycle.
So that kind of takes the time that would be allocated for backports.
The other answer is, patches welcome!
So I didn't do backports for wheezy yet,
just because I had enough on my plate for sid.
But I would happily help anyone wanting to prepare backports
I think it shouldn't be too hard.
cups is probably buildable right away.
[??]: So that's cups, how about drivers?
[Didier]: Same.
If anyone's interested I could just help making sure it happens.
It's unlikely I would do it myself.
[??]: Thank you.
[Ben]: Do new drivers typically depend on a new version of cups?
[Didier]: Usually not, because they build against libcups2
but libcups2 is kind of ABI stable, since years
So it shouldn't be too much.
[Ben]: So the missing hardware support, is as I understand it
always considered an important bug
and worthy of a stable update.
So that means that if you wanted to, you could update drivers,
add new drivers, in stable.
For hardware enablement.
[Didier]: That's interesting, yeah.
[Ben]: I also had a question about drivers, which is
typically when I plug into a new printer,
I get a list of possible drivers
possibly limited to the exact model, or not.
But there always seems to be more than one option per model.
I assume that because there are multiple collections of drivers
in the package.
How, as a user, supposed to decide which of those to use?
[Didier]: Trial and attempt? [laughs]
I mean, for some printers you get a recommended version
from foomatic that has this parenthesis recommended thing.
You should just pick that one.
I think we also mostly have multiple drivers per printer
because sometimes for a single printer,
depending on where in the world it was
it would work better or worse with different printer drivers.
The one database that we use for that is foomaticdb
That is maintained on the OpenPrinting website
Where exactly you should report bugs isn't exactly clear,
also for me, so I should clarify that.
[Ben]: I've never selected a driver and found that it didn't work
So as far as I'm concerned you're doing fine there.
It's simply because, having been presented with a choice,
I don't know what the difference would be.
[Didier]: Was that on the cups web interface?
[Ben]: Yes.
[Didier]: I think there the selection isn't very smart
but when I think that you use python-cups or one of the
GNOME or KDE frontends,
you have a little less options, I think.
But that's more frontend work, than whatever cups related
but I don't have a better answer, now. [laughs]
Any other questions?
[Wookey]: Kind of following on from what Ben said
I'd been under the impression that those were different ways of talking to the
printer
because there are always 17 ways of talking to any given printer
So I kind of thought that those were all different flavours
But again, it's extremely unclear.
Do I want foomatic-thingy or hplip-thingy or somethingelse-thingy?
I just say, you try one and usually it works
and you go, "I can sit here and try all 17
but I don't know whether that's good."
And sometimes there's the interface to printer you have to specify
so our fancy printer in the office has 81 different ways of talking to it
and you go, "I don't want to try all those!"
The 4 I've tried all make it crash!
[Didier]: Just need one that works!
[Wookey]: Exactly.
There seems to be a very small number of people that understand this stuff
There's Till and maybe 3 other people somewhere.
[Didier]: Yeah.
[Wookey]: Right.
[Didier]: We should talk more to Till! [laughs]
He's making most of that work on the Ubuntu site.
I think, as a Canonical employee.
[Wookey]: I vaguely gathered that the cups browsing thing has disappeared
upstream
So we're keeping it in a Debian and Ubuntu, while we can.
Is that right?
[Didier]: Yes.
Basically using a zeroconf/avahi thing.
[Wookey]: That's how Apple want it to work
but especially in a big office, that doesn't work at all
because you're on different network segments
[Didier]: One thing that was dropped and that hasn't been reintroduced
on OpenPrinting, is the LDAP support.
It used to be in cups, that's now removed.
It was used in big corporations that had
like, an LDAP list of printers.
Instead of listening to the noise of all printers
announcing themselves on a network.
And we regularly get users asking,
the latest one was,
"The browsing daemon has 10% CPU,
is that because I have 100 printers at my office?"
Well, yes! [laughs]
I don't have the capacity of recoding that anyway
If a big corporation wants to get LDAP support,
they should make LDAP support!
[Wookey]: Fix it, yeah.
[Didier]: But I'm open to integrating that as a Debian patch
if that helps, but can't really fix that myself.
[Wookey]: If I had any time I would like to help you with printing.
But I have too many hats already, so I'm not promising anything!
[Didier]: Yeah, thank you.
[Wookey]: Mostly so I could actually print stuff,
without having to run Windows in a VM.
Which in practice is how I printed my stuff to get here!
[Didier]: Yeah, it's bad.
Actually, one thing that geeks like us should know
is how to pick the correct printer when you buy one
[Wookey]: Yeah, my home printers all work fine.
The cups browsing works, stuff prints,
it's all lovely.
It's when you go to work that the whole things a disaster
[Didier]: Yah.
[??]: Which manufacturers should we prefer?
[laughter]
[Didier]: I'm not paid by any of these, but HP printers mostly work fine
Either through hplip or other things.
That's baseline, I would say.
Others work too! [laughs]
If anyone has contacts at Brother,
tell them to contact me and we'll manage something
and recommend some good practices for modern printing
if you know, because that's not an acceptable way
of providing Linux support, I think.
Anyway, other questions?
Everyone's hungry.
Good, thank you very much.
[applause]