Re: printer driver for Epson AcuLaser C1100
Hello Didier,
thanks for your answer!
I cc'd debian-printing@lists.debian.org as you suggested :-)
On 02.01.2014 16:51, Didier 'OdyX' Raboud wrote:
> Hi Carsten,
>
> Le dimanche, 29 décembre 2013, 11.19:26 Carsten Schoenert a écrit :
>> over the X-Mas days I have done a little bit finetuning on the Wheezy
>> installation of my fathers PC.
>> As my father owns a Epson AcuLaser C1100 ,and yes of course my father
>> needs printing from the linux desktop :-) , I have to integrate the
>> printer into cups.
>> I have done this a while ago on a another Wheezy PC and it is some
>> kind of "self PAIN" because the originally filter is a precompiled
>> 32bit binary and only works with a 32bit libstdc++5.
>> But thanks to Multilib it works also on a 64bit amd64 platform.
>
> I've done my little bit of research through openprinting.org and
> epson.com . Is that the printer you are referring to [0] ?
>
> [0]
> http://www.epson.fr/fr/fr/viewcon/corporatesite/products/mainunits/overview/1400
Basically yes, but without the network option. It's a C1100 not a
C1100n. But make no difference in the end.
> I'm not exactly aware of the different Epson Laser printer series, but I
> have found that the "Epson ActionLaser 1100" as described in the
> foomatic-db source package has a quite close name. The recommended
> driver for it is "ljet3" and it is free software. Can you try to print
> to this printer with the ljet3 driver (that is: selecting "Epson
> ActionLaser 1100 Foomatic/ljet3 (recommended) (en)" as driver in the
> cups configuration?
Unfortunately this is a complete different printer, the Epson
ActionLaser 1100 is a almost 20 years old non color laser printer with
internal LaserjetIII emulation, that's the reason the ljet3 driver works
with this printer. :)
http://files.support.epson.com/pdf/al1100/al1100pg.pdf
The AcuLaser C1100 is a GDI color laser printer so the driver have to
done all the work. :/
>> But I'm unhappy to redo the whole work on everey PC. So I decided to
>> package the filter and the ppd file. I did not write an ITP yet.
>> I was searching the wiki and found
>> https://wiki.debian.org/Teams/Printing/RethinkingTheStack
>> I have tried to respect the things written on the wiki page.
>
> Nice. That reminds me that the wiki section would need a refresh, which
> I failed to take time for yet.
>
>> Currently I got a package that works for me. But I believe there some
>> things I have forgotten, like package versions or licensing. ;)
>
> See below.
>
>> As we meet us at the Debconf in Switzerland while you helped Matthias
>> Schmitz I choose to write this email to you. And as far as I can see
>> you have done a lot of work in the printing group so I hope you are
>> interested in the package finally and put it under the umbrella of
>> the printing team.
>
> I am interested in making the printing experience on Debian as smooth as
> possible, given the necessarily limited time that I can give into it.
>
> I must state though that I'm never enthusiastic to work on non-free
> packages, which this one is, see below.
Comprehensible. :-)
>> The driver itself is simple. Three files are needed for a working cups
>> integration.
>> 1. The core is the (precompiled) binary /usr/bin/alc1100.
>
> Although the compiled file itself is licensed under the EPSON AVASYS
> PUBLIC LICENSE (./EAPL.en.txt), which doesn't appear from a first glance
> to be DFSG-free (because of its point 5, see below). The fact that
> alc1100 can't be recompiled makes the whole package only suitable for
> non-free.
>
>> 2. alc1100 is called by the wrapper script /usr/bin/pstoalc1100.sh
>
> As per [Debian policy §10.4], this executable should not carry its
> implementation language extension and be named pstoalc1100 . That said,
> it also doesn't respect TMPDIR and is subject to [symlink race] through
> the use of predictable temporary filenames (it should use mktemp
> instead). It uses WORKFLAG as a lock in /tmp (that would be made
> unncessary by the above measure) and certainly has other flaws.
I know, a horrible piece of shell script. But that's manageable in some
kind.
> [Debian policy §10.4] http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts
> [symlink race] http://en.wikipedia.org/wiki/Symlink_race
>
>> One requirement, alc1100 needs the libstdc++5 32bit.
>
> As far as I could see, you don't need to explicitely specify it as
> dh_shlibdeps will automatically add the correctly-versionned dependency.
O.k. I will look at this.
> I'm also not absolutely sure your package needs to be arch:i386; it
> seems to compile and run fine when compiled on arch:amd64; that might
> worth trying with your printer.
It works on amd64 (and probably other platforms), as long as the
libstdc++5 from i386 is installed.
>> You will found my current work on Github.
>> http://github.com/tijuca/printer-driver-alc1100
>
> Nice, thanks.
>
>> If you interested in the package there are some question that come to
>> my mind.
>>
>> * Where should the ppd file placed?
>
> If there is only one, it should be placed under the /usr/share/ppd
> hierarchy (not anymore under /usr/share/cups/model/ ). For more than one
> (or for a big one), dh_pyppd (see the pyppd package) is the correct tool
> to use, it will mostly "do the right thing" and put a compressed
> package-of-ppds in the correct place.
So it would be placed in /usr/share/ppd/printer-driver-alc1100/ as I can
see for hplip as example?
>> * Are the dependencies correct to get the package simple installed on
>> amd64 with a added i368 architecture. Will the libstdc++5
>> automatically installed?
>
> Yes. As mentionned above, the dependency will be automatically written
> by dh_shlibdeps and therefore be in the binary package's CONTROL file.
>
>> * Are there some dependencies missed for the binary package? The
>> wrapper sript needs bash and in this there a some tools used.
>
> From the .spec-file's [requirements] I see at least ghostscript,
> psutils, gawk and bc missing (glibc is pulled automatically, sed and
> grep are essential).
>
> [requirements] https://github.com/tijuca/printer-driver-alc1100/blob/debian/experimental/Epson-ALC1100-filter.spec#L36-L42
Ah yes, that's needed by the pstoalc1100.sh script, anywise forgotten.
>> * The README-alc1100-CUPS says explicitly the MIT license is used for
>> all files, in EAPL.en.txt is the EPSON AVASYS PUBLIC LICENSE
>> mentioned. This allows a reverse engineering of the alc1100.
>
> No, it doesn't:
> "You may neither reverse engineer, reverse compile, reverse assemble nor
> otherwise attempt to analyse those parts of the Program that were
> provided to you in executable or object code only."
O.k. maybe I have read this in a another context, but that's the reason
closed source isn't very nice.
>> This is a little bit confusing.
>
> I agree. From the README-alc1100-CUPS file (which I think refers to the
> shell scripts), apparently alc1100-cups "needs" Epson-ALC1100-filter >=
> 1.2, which I think refers to the alc1100 executable, which is apparently
> licensed under the EAPL, which is non-free because of its §5 clause.
>
>> * I added some overrides because the alc1100 is precompiled.
>> * Is this package "free" enough to get into the main repository?
>
> No, see above. We need to have the source for the executable, which I
> couldn't find anywhere on the interwebs.
>
>> Thanks for your attention, I'd be happy to see my work under the
>> umbrella of the printing team.
>
> Feel free to set the Maintainer to "Debian Printing Team <debian-
> printing@lists.debian.org> and add yourself to the Uploaders field.
>
> Now, some more general remarks:
> - The source package name is usually close to how upstream names their
> tarball; in that case I would probably have named it "epson-alc1100
> filter".
I agree, will change that.
> - For the binary package name, I'm pondering the idea to name the non-
> free packages explicitely; printer-driver-non-free-alc1100. After
> further thought I think it's overkill. I won't add it to the
> Recommends of printing-metas anyway; at most to Suggests.
I haven't think about that thing. ;) But a clear name is important I
think, especially if you are relative new to the Debian and package
system and only know how to search for package names. :-)
> - This whole machinery is old (developped for CUPS 1.1, we're at 1.6)
> non-free and full of bad shell.
> - I'm answering to you encrypted, as you wrote to me encrypted, but I
> see no reason to not have this conversation on debian-printing@. Let's
> move there from your next mail?
Done.
> - As far as I see,
> - Someone could go talk to Epson or Avasys to get drivers for their old
> printers properly open-sourced. I noticed that Olaf Meeuwissen
> <olaf.meeuwissen@avasys.jp>, apparently "FLOSS engineer" at Avasys
> regularily reported bugs on the Debian bugtracker. It might be worth
> contacting him to see what can be done, what do you think?
Good point! It would be great if Epson could provide that really old
stuff, what have to loose?
I have wrote last year to the (german) support and ask them if it would
be possible to get the source of the binary. They replied that Linux
isn't a supported system. WTF???
But that answer was clearly that I expected. :-(
But o.k., I will contact Olaf and see if he could make something
possible. I will wait his reaction before I (re)work the current state.
> - I wonder if there are other Epson drivers that would warrant
> packaging; do you happen to know?
There will be surely other printer and driver that's worth to package,
but the ACL1100 is the only printer that I have manually handled, the
SX440W is working by the epson-inkjet-printer-escpr package. Other Epson
printer I never have worked with.
But most of the other Epson products having to use binary shipped linux
drivers. I'm always wondering how much time is wasted to create such
packages with 80% binary blobs inside ...
> Thank you very much for scratching this itch of you, that can only help
> others out there with your printer (if it doesn't work with ljet3, of
> course ! :-) )
Nope, I'm interested to know the packaging work flow, if the outcome is
something useful for other people I'd be happy to help. Debian have
giving me much possibilities and fun why not give back if possible. ;)
--
Regards
Carsten
Reply to: