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]