After going through the Printing Howto, and having no luck, I went to the forums, and found nothing relevant. I finally got Gentoo to *recognize* my printer, but it would never actually print. (Sometimes it would just feed paper through the printer). The EPSON provided drivers would not compile, even the rpm'd files wouldn't work properly (I tried those thinking they were already compiled), but that didn't work either. I've resorted to using a program called TurboPrint (www.turboprint.de/english.html) to handle the driver side of CUPS, and it works wonderfully, but it would be nice to see appropriate drivers inside the CUPS installation, or available as an Ebuild. Reproducible: Always Steps to Reproduce: 1.Kernel options: USB & USB Printing built-in, reboot, check for identification/recognition of printer. 2./etc/init.d/cups start 3.browse to localhost:631, set up printer using either of the listed Epson Photo drivers Actual Results: When set up with the "old" Epson Photo drivers, CUPS sees my printer but anything sent to it is completely ignored. So, it says "Test Page sent...." and acts like it was sent, but the printer does nothing, as if nothing had been sent. When set up with the "new" Epson Photo drivers, CUPS sees my printer, and will send to it. However, somehow, it tells the printer to just keep feeding paper through (I left it running, it went through 500 pages, and didn't put a drop of ink on any of them). Expected Results: A driver that supports Epson as an ebuild would be the best, however, if that's not possible, a TurboPrint Ebuild would be the best bet (as i know it works perfectly with the Epson Stylus Photo R200, and supposedly with others). MSI 865 PE Neo2 Motherboard, Intel 865PE (Piix4 / ICH5r) P4 3.0 GHz 800 MHz FSB, 2 GB Dual Channel DDR PC3200 RAM 120GB SATA HDD (ntfs storage), 80GB IDE HDD (linux partitions), 9GB SCSI Ultra 160 on an Adaptec 29160LP card (XP drive), CD-RW, DVD-RW. USB Devices: Logitech wireless keyboard/mouse receiver, Epson Printer (Stylus Photo R200). TurboPrint solved this for me, but it is not "open source." There is a "free" version and a "paid for" version.
if you can post an ebuild for the free version i'll add it
*** Bug 63120 has been marked as a duplicate of this bug. ***
Here is a quick shot at an initial ebuild from me, works for me, but checking it would be good, especially at the deps and the license, which is incorrect now, the right one is here: http://www.turboprint.de/manual/turboprint-1.html
Created attachment 41436 [details] turboprint-1.90.ebuild
I've spent a long time putting together this new and improved ebuild for version 1.91-2. It uses the tar.gz version instead of the RPM version and correctly installs the CUPS or the LPR version depending on whether the cups USE flag is set or not. The part of the installation script that deals with the KDE/GNOME shortcuts is skipped because this could probably be handled better within the ebuild itself. I haven't written any extra code since I don't know anything about making KDE/GNOME shortcuts and Gentoo seems to leave this up to the user for many packages anyway. There's two snags with this ebuild though. The first is that it can't be emerged in sandbox mode because of one particular test file it creates. This occurs within a binary setup program so this cannot really be fixed. I've included a warning if the user tries to install it with sandbox mode turned on. The other is that there is a fair amount of post-installation. I included a pkg_postrm() function to clean up the mess after the package has been unmerged but the problem is that this gets run even when the package is simply being upgraded and consequently breaks the upgraded version. This behaviour strikes me as odd. I would only expect pkg_postrm() to get run when the package is actually being removed altogether. This needs to be fixed before the ebuild can be added to Portage. Any ideas? I tested this with the Canon SmartBase MP390 and it works fine.
Created attachment 54903 [details] turboprint-1.91.2.ebuild
Created attachment 54904 [details, diff] post-install.patch
The setup of turboprint has to be fixed. It doesn't provide any equivalent to "make DESTDIR=". The setup is a shell-script, so we can patch it if the menufacturer doesn't want to provide any support. Just use "./setup --nogui", and the shell-script is used instead of bin/xtpsetup. I will contact the manufacturer soon, and i'll ask if he can provide us with a "--destdir" parameter fot the setup.
The work I've done on it already achieves this to a certain extent. The script already supports an "RPM Build Root" so I took advantage of that. It's just a case of clearing up the post-installation phase.
here's a new ebuild that executes lib/install-post earlier, but it still suffers from the "bug", that tpsetup tried to open /etc/turboprint/tp_testfile.tst, which has to be fixed by the manufacturer. We can't, since tpsetup is a binary (as James said already).
Created attachment 57109 [details] ebuild for turboprint 1.92
Created attachment 57110 [details, diff] patch needed by turboprint 1.92 ebuild
OK, i give up. My ebuild still has the following hickups: - "tpsetup --writeppdfiles" does not work without files in /etc/turboprint and therefor it cannot be executed before the package is installed - perhaps "tpsetup --writeppdfiles" will also search for tpp files in /usr/share instead of /var/tmp/portage/image/... which is wrong too I asked the manufacturer for support. The whole installation-process is not "Gentoo-compatible", and executing "tpsetup --writeppdfiles" from pkg_postinst() seems horribly wrong to me. Does anybody know, what "tpsetup --update" is for?
Created attachment 57117 [details, diff] patch needed by turboprint 1.92 ebuild
Created attachment 57118 [details] ebuild for turboprint 1.92
Yeah that's why I kept the post-installation as a post-installation. I can't remember what it does though. Been too long.
"tpsetup --writeppdfiles" generated creates a ton of ppd files, that are used by CUPS as far as i understand it. The comment for "tpsetup --update" was "call setup to update LPD config files / CUPS PPD files", but why should we update the ppd files we just generated? this doesn't make any sense to me. Perhaps it does make sense for LPD based systems, but i have none to test it. IMHO the ppd files should be installed/uninstalled by portage, and therefor we cannot move their generation to pkg_postinst().
I'm pretty sure there was a reason for the "update" but I can't remember right now. I'm extremely busy so I haven't got time to look into it but perhaps you could try copying the files you need to run tpsetup into ${D}? Though I suppose tpsetup will still want to use the real files. Hmmm. Is there any kind of chroot technique for situations like this?
Well, 1.92-2 is out. I'll ask the manufacturer for the promised gentoo-support. Perhaps we're lucky, and they already finished the work ... I don't think that there is any kind of chroot-technique, thought the sandbox could "overlay" the real filesystem with the image - couldn't it? But i guess that's nothing we will see soon.
*** Bug 87029 has been marked as a duplicate of this bug. ***
Sorry my eyes are very heavy. true/turbo print
Created attachment 69590 [details] turboprint-1.93.ebuild I have done this for 1.93 (ported for my work on 1.92(-2)) My first approach was to use LD_PRELOAD to avoid sandbox breakage by creating and removing an empty file in /etc/turboprint (don't know wy they do that), overriding fopen and unlink. But it was quite ugly, so I now use SANDBOX_ON=0/1, since this sandbox breakage seems to me not dangerous (only creating and removing a file wich is not usefull for anyone). follow the 2 needed patches
Created attachment 69591 [details, diff] install-post-root-r2.patch
Created attachment 69592 [details, diff] install-static-root.patch
That seems to be the easiest way around it. I didn't know it was possible to turn sandbox on and off like that. It's probably something the devs try to keep quiet. (-;
also there is a version 1.94 available
You can find my ebuild up to date here : http://gentoo.xwing.info/net-print/turboprint/ Same approach as I explained before (61311#c22).
Created attachment 76972 [details] turboprint-1.94.ebuild
works fine for me! please add it to portage!
seems fine to me, get a developer to add it or become developer yourself and maintain some more ebuilds.
ebuild for 1.95 version available here as usual : http://gentoo.xwing.info/net-print/turboprint/ (or from my overlay gently added to layman list : layman -a xwing) This is a enhanced version that does not use the install-post script anymore (that needed to be over-patched to work in the sandbox instead of the real root) but do the post-install manually in src_install function. This solution needs less patching and is easyier to maintain. As usual, there is some sandbox breakage during the tpsetup execution. Now I use the addpredict function to work around this problem instead of SANDBOX_ON=0/1 (more elegant solution). I only provide cups and x86 support in the ebuild since I cannot test lpr and/or amd64 (I do not have any of them). Any enhancement and feedback is welcomed ;)
I have used the ebuild for turboprint 1.96.3 and tried it for version 1.96.4. During this I encountered some sandbox violations. The steps "Generating ppd files" and "Simlinking ppd files" tried to access some files at /dev. My solution is adding: addread /dev/random addpredict /dev I first tried it with addpredict only but the setup will stop because it cannot gather random numers. So read access would be necessary.
Hi, This sound strange to me : sandbox should allready allow to read in /dev. Moreover, the "Simlinking ppd files" step is only a "dosym" loop (native eutils eclass function) Whats your emerge --info ? especially, do you have unusual FEATURES ?
> Whats your emerge --info ? especially, do you have unusual FEATURES ? Portage 2.1.4.4 (default-linux/amd64/2006.1, gcc-4.1.2, glibc-2.6.1-r0, 2.6.24-gentoo x86_64) ================================================================= System uname: 2.6.24-gentoo x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ Timestamp of tree: Sun, 30 Mar 2008 10:30:01 +0000 app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.4.4-r9 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=athlon64 -mfpmath=sse -mmmx -msse -msse2 -m3dnow -ggdb" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -pipe -march=athlon64 -mfpmath=sse -mmmx -msse -msse2 -m3dnow -ggdb" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer parallel-fetch sandbox sfperms splitdebug strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LINGUAS="de us" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/home/raikel/own/overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acpi alsa amd64 bash-completion berkdb cdr cli cracklib crypt cups dri dvd dvdr fam gdbm gif gpm iconv isdnlog jpeg kde kdehiddenvisibility lirc mad midi mp3 mudflap ncurses nls nptl nptlonly ogg openmp pam pcre png ppds pppd qt qt4 quicktime readline reflection session smartcard spl ssl tcpd tiff unicode usb vorbis xinerama xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de us" LIRC_DEVICES="serial" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
is there any chance, to get an ebuild for turboprint v2 in the overlay? For my new printer I would need this version.
(In reply to comment #35) > is there any chance, to get an ebuild for turboprint v2 in the overlay? > For my new printer I would need this version. > Hi, Currently, not from me : my license is not valid for the v2 (bought some years ago, so not eligible to v2), and my printers are supported by the v1. So I have not seriously studied the v2 install process. After a quick look, it seems to be more difficult to avoid a graphic install (and without any questions to the user) than with the v1, but I did not study deeper the installer, so I could miss the point. Regards
(this is an automated message based on filtering criteria that matched this bug) Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Because this is a mass message, we are also asking you to be patient with us. We anticipate a large number of requests in a short time. Thanks, On behalf of the Gentoo Sunrise Team, Jeremy. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
Created attachment 257487 [details] net-print/turboprint-2.17-r2 - ebuild: Version bump Ebuild for Turboprint V2. Please try and modify it so we can have a good ebuild, I'm not an experienced ebuild-writer. Language management should be improved, as well the printer selection.
Created attachment 257489 [details] net-print/turboprint - ebuild, patches and manifest: Version bump
Created attachment 257490 [details] net-print/turboprint - license
Is anyone still interested in this?
(In reply to comment #41) > Is anyone still interested in this? I picked one of the attached ebuilds some years ago. Currently I keep it in my own portage overlay. There was no activity on this bug for some years now. If noone is able/willing to spend effort on this it perhaps make sense to close this bug.
(In reply to comment #42) > (In reply to comment #41) > > Is anyone still interested in this? > I picked one of the attached ebuilds some years ago. Currently I keep it in > my own portage overlay. > There was no activity on this bug for some years now. If noone is > able/willing to spend effort on this it perhaps make sense to close this bug. Are you interested in maintaning this driver directly yourself in the new printer-drivers overlay [1]? If yes, just send me via personal e-mail at dilfridge@gentoo.org the following data, so we can give you git push access to the overlay: * the user name that you'd like to have * your public ssh key [2], so we can give you git push access to the overlay * your e-mail address * and your full name If you have a gnupg key, you should sign that e-mail [3]. Just a few rules: * Initially, the ebuilds should work for you, and not break anything else. * You enter yourself as maintainer in metadata.xml (together with the printing herd), and are then automatically cc'ed in bug reports on bugzilla. * We will guide you towards improving the ebuilds over the next months so they follow the rules and qa guidelines of the Gentoo main portage tree. In particular this means also using a recent EAPI (3 or perferably 4), and fixing repoman warnings [4]. Don't worry, we'll help you with that. * I hope this is never going to happen, but... ebuilds that "work but go against the guidelines" and do not see any improvement will be removed again one year after initial addition. There are many ways to get help. * You can directly ask me by personal e-mail (my time is limited, but I'll try), * you can ask on freenode, channel #gentoo-dev-help, * you can read the documentation (ebuild howto [5], devmanual [6]), * ... [1] http://git.overlays.gentoo.org/gitweb/?p=proj/printer-drivers.git;a=summary [2] http://www.gentoo.org/doc/en/articles/openssh-key-management-p1.xml [3] http://www.gentoo.org/doc/en/gnupg-user.xml [4] http://dev.gentoo.org/~zmedico/portage/doc/man/repoman.1.html [5] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2 [6] http://devmanual.gentoo.org/
Turboprint 2.30 is out. Any progress here after all the years? I want to make my canon mp810 working. Anyone has an ebuild for this in local overlay which can be posted here? would be nice.
