Core-Dev Application: Till Kamppeter

[Till Kamppeter]

Stefan Potyra wrote:
> you describe this as a difficult packaging task. What in particular do you 
> consider difficult here?
>

Problem of these packages was that they were not available as source code.

There were binary tarballs and for some packages even only binary RPM 
and DEB packages. Extracting the file system tree from the DEbian 
packages required a lot of manual correction of permissions.

Brother did not take into account that they can have customers who 
connect more than one of their printers to the same machine. One could 
not install two Brother driver packages onto the same machine as there 
were equal files which were in all Brother packages. Here files had to 
be compared, -common packages be created and symbolic links be added.

Brother published around 100 pairs of LPD and CUPS binary packages (one 
pair for each printer model), in the Ubuntu packaging this was reduced 
to maintainable 7 pairs.

Brother's packages install into /usr/local, with paths hardcoded into 
binary-only executables. These had to be patched so that the Ubuntu 
packages install into /usr.

Brother's packages contain world-writable files in the system area 
(/usr/...). They got moved to /var/...

Brother's original packages are i386-only, I brought in the idea to 
generate binary packages for both i386 and amd64, the amd64 version with 
dependency on ia32-libs.

It is really much more packaging-friendly if manufacturers publish 
properly free drivers or at least follow my design guidelines (where I 
have added several items after the work with the Brother packages):

https://www.linux-foundation.org/en/OpenPrinting/WritingAndPackagingPrinterDrivers

Brother developers, please have a look at HPLIP. Thanks.

> Also, I'm curious: Who gave the second ACK for the new package as required by 
> MOTU policy for these packages?
> 

It was Martin Pitt (pitti).

> Finally, the initially uploaded versions had severe packaging issues. What 
> measures will you take, to avoid uploading packages with severe issues in the 
> future?

We were shortly before feature freeze. We got in the first installable 
packages really one day before. And as I wanted to acknowledge the great 
work of these two volunteers (it is REALLY difficult to get volunteers 
working on printing stuff) I simply have taken in these packages and 
thought we will get them polished and correctly working in the bug 
fixing period after the freeze.

If there had not been a freeze, I had done the polishing and bug fixing 
work with them on their Launchpad PPAs (from where the users can also 
access the packages for testing) and passed them to multiverse only now, 
where the packages install cleanly and users report that their Brother 
printers actually set up via Plug'n'Print and reproduce the user's 
documents on paper, like HP printers do.

I would recommend to every contributor to use the Launchpad PPA to test 
server-site building of packages on various architectures, apt-get 
installation, automated updates, testing the packages by users who have 
reported the lack of these packages ...

I have also rebuilt and installed the packages and reported problems 
which the contributors quickly fixed. I only did not test actual 
printing, as Brother never gave me a test printer.

The hurry to get the packages into Multiverse before the freeze worked 
out. Now Hardy users are able to print with Brother's printers, and with 
much less hassle than they had with Brother's original packages. 
Especially also 64-bit users are also able to use the drivers.

    Till