This is an ebuild for the open source drivers published by avasys for Epson printers. Reproducible: Always
Created attachment 143111 [details] First version of ebuild
Created attachment 143113 [details] Gentoo-style init script
Thanks Alet for the ebuild. I had to reinstall the printer on a new computer, so this came quite handy. Or let's say almost: the ebuild has a problem, it doesn't install the needed files in /usr/lib/pipslite which contains also the ekpd daemon.. so this would be vital. Would be great if you could fix this eventually, unfortunately i still don't know enough about ebuilds...
(In reply to comment #3) Hi Mattia I'm pleased that you find it useful. Which files are you missing? On my computer (an amd64), the ebuild installs the following files in /usr/lib=/usr/lib64: /usr/lib64/liblite.a /usr/lib64/liblite.so.1.0.0 /usr/lib64/pipslite/ /usr/lib64/pipslite/filterlite /usr/lib64/pipslite/gsconfig /usr/lib64/pipslite/freset /usr/lib64/pipslite/ekpd /usr/lib64/liblite.so.1 -> liblite.so.1.0.0 /usr/lib64/liblite.so -> liblite.so.1.0.0 /usr/lib64/liblite.la
I have the same problem when I try to emerge this with ~x86 keyword: no files in /usr/lib/pipslite
This ebuild is wrongly written. First, on Gentoo Forums Mattia wrote that you have to copy files from /usr/lib/cups/filters to /usr/libexec/cups/filters, not move it there, otherwise it won't work (and it doesn't indeed). Second, you just throw away whole /usr/lib, I don't know if on amd64 this is handled in a different way (lib64 instead of lib), but I find it strange that you've got these libraries merged. And init.d file also doesn't work for me, it fails: ekpd | * Starting ekpd ... ekpd | * start-stop-daemon: caught an interrupt ekpd | * start-stop-daemon: /usr/lib/pipslite/ekpd died [ !! ] ekpd | * ERROR: ekpd failed to start But ekpd process starts. My baselayout version is 2.0.0_rc6. Actually I think this script is not needed, as running ekpd is only required to generate ppd file, printing doesn't need it (correct me if I am wrong, but my printer is able to print without ekpd running). Anyway, I corrected your ebuild a bit and now it works on ~x86. Ps. I have a small problem with these driver. When I print something with my Epson DX8450, it cuts top margin. Have anyone got similar behaviour?
Created attachment 147832 [details] corrected ebuild
(In reply to comment #7) Thanks for this unK (also for the version bump). I'll give your version a go - so far I haven't been able to get my DX8450 to print anything at all. This may be due to the problems in my ebuild that you have highlighted.
Thanks Alet and unK for your work! Now it's really easy to install this stuff. For the top margin problem: make sure you set the correct paper format (A4 usually) in cups and control the settings in all your applications before printing. It happened to me, that i set the correct paper in cups itself, but the applications changed it. Otherwise just try to edit the .ppd file manually... (i know.. maybe not such a good idea) About the ekpd daemon. It's not only needed for installation but also for monitoring the ink cartridges with the "ekpstm" command.
(In reply to comment #9) > Thanks Alet and unK for your work! Now it's really easy to install this stuff. > > For the top margin problem: make sure you set the correct paper format (A4 > usually) in cups and control the settings in all your applications before > printing. It happened to me, that i set the correct paper in cups itself, but > the applications changed it. I checked my settings and they are the same in cups and in other apps, but my printer still cuts top margin. The strange thing is that if I print something to pdf file and then print this pdf, it is printed correctly, with top margin. > About the ekpd daemon. It's not only needed for installation but also for > monitoring the ink cartridges with the "ekpstm" command. I edited rc script a bit and now it works with baselayout-2. Also updated ebuild a bit.
Created attachment 152299 [details] new ebuild
Created attachment 152301 [details] rc script working with baselayout-2
Created attachment 152303 [details, diff] patch for ekpstm
I would call this an awesome job! Thanks unK!
Created attachment 156377 [details, diff] fix compilation issue with glibc-2.8
* Messages for package drivers/pipslite-1.0.3: * Failed Patch: pipslite-ekpstm.patch ! * ( /home/portage/drivers/pipslite/files/pipslite-ekpstm.patch ) * * Include in your bugreport the contents of: * * /mnt/sdb6/tmp/portage/drivers/pipslite-1.0.3/temp/pipslite-ekpstm.patch-22104.out * * ERROR: drivers/pipslite-1.0.3 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 2154: Called epatch 'src_unpack' * environment, line 1124: Called die * The specific snippet of code: * die "Failed Patch: ${patchname}!"; * The die message: * Failed Patch: pipslite-ekpstm.patch! * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/mnt/sdb6/tmp/portage/drivers/pipslite-1.0.3/temp/build.log'. * The ebuild environment file is located at '/mnt/sdb6/tmp/portage/drivers/pipslite-1.0.3/temp/environment'. * This ebuild is from an overlay: '/home/portage/' # less /mnt/sdb6/tmp/portage/drivers/pipslite-1.0.3/temp/pipslite-ekpstm.patch-22104.out PATCH COMMAND: patch -p4 -g0 -E --no-backup-if-mismatch < /home/portage/drivers/pipslite/files/pipslite-ekpstm.patch ================================= missing header for unified diff at line 3 of patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- ekpstm/interface.c.orig2008-05-07 13:32:55.770840305 +0200 |+++ ekpstm/interface.c2008-05-07 13:35:40.227954851 +0200 -------------------------- No file to patch. Skipping patch. 1 out of 1 hunk ignored
Created attachment 164880 [details] pipslite-1.1.0 ebuild with files including old 1.0.2 ebuild I' ve created a new ebuild for pipslite 1.1.0. It is based on UnK's last ebuild. It installs fine for me. The filename of the download archive is hardcoded for the moment though. At the moment the pipslite-wrapper segfaults on my machine - I couldn't figure out why. It might have to do with glibc 2.8, but really, I'm not sure.
(In reply to comment #17) > At the moment the pipslite-wrapper segfaults on my machine - I couldn't figure > out why. It might have to do with glibc 2.8, but really, I'm not sure. I suspect UnK's patch adding <limits.h> is wrong. filter.c in the pipslite 1.1.0-1 distribution uses "#define NAME_MAX 41". I wouldn't be surprised if there's an impedence mismatch here. I also have (minor) problems getting it to build; it fails to build libcutils.la before it gets used. This seems to be the result of having MAKEOPTS=-j3 (I have a 2x2 Opteron configuration). Using "MAKEOPTS=-j1 emerge pipslite" gave a successful build. (I've run into this before with some other packages, so I suspect it's not a problem with pipslite. Thought I'd mention it, though.)
(In reply to comment #18) > (In reply to comment #17) > > > At the moment the pipslite-wrapper segfaults on my machine - I couldn't figure > > out why. It might have to do with glibc 2.8, but really, I'm not sure. > > I suspect UnK's patch adding <limits.h> is wrong. filter.c in the pipslite > 1.1.0-1 distribution uses "#define NAME_MAX 41". I wouldn't be surprised if > there's an impedence mismatch here. Probably you've figured this out already, but the CUPS people have really outdone themselves in broken interfaces. argv[0] of pipslite-wrapper is not supposed to be anything sane, it's supposed to be the name of the printer! To get this to work in gdb, the technique below works. (Of course you need to sustitute the name of your printer since PM-A970 probably doesn't exist on your system.) Since I don't know what to feed it on stdin, I haven't made any progress in debugging. But this might help other people get a little farther a little faster. :-) I have tried making the NAME_MAX = 41 change suggested above, but that doesn't seem to help. (gdb) break main Breakpoint 1 at 0x4012a4: file wrapper.c, line 91. (gdb) run Starting program: /home/steve/Downloads/pipslite-1.1.0/src/pipslite-wrapper 11 steve 'test run' 1 "" [Thread debugging using libthread_db enabled] [New Thread 0x2b750a5c4b00 (LWP 29234)] [Switching to Thread 0x2b750a5c4b00 (LWP 29234)] Breakpoint 1, main (argc=6, argv=0x7fffa216c2a8) at wrapper.c:91 91 memset (&fopt, 0, sizeof (filter_option_t)); (gdb) print argv[0] $3 = 0x7fffa216e411 "/home/steve/Downloads/pipslite-1.1.0/src/pipslite-wrapper" (gdb) set variable argv[0]="EPSON_PM-A970_USB_1" (gdb) print argv[0] $4 = 0x604010 "EPSON_PM-A970_USB_1" (gdb) cont
I tried copying the pipslite-1.1.0.ebuild to pipslite-1.2.0.ebuild, downloaded the pipslite-1.2.0 beta from Avasys's site, emerged it, and got the same result. The glibc28 patch was no longer needed (****Note! the 1.2.0 version does not use <limits.h>, it does "#define NAME_MAX 41"), so I nuked that. For some reason I got rid of the status-monitor patch too (I can try to figure out why if asked). However, when I changed the build I got a pipslited that doesn't crash and a pipslite-install that works. I don't know why and don't have the free time to investigate, just hope this helps others. I fixed a couple of warnings, one which *possibly* but not likely could be significant (pointer of different size from int, of the form int i = p1 - p2; I don't think it's likely that there's a 4GB+ string there!), the another was just an annoyance (assigning a pointer to const to a pointer to non-const). Patches attached, also new ebuild: pipslite-1.2.0.ebuild fix-pixbuf.patch fix-str_extract.patch I dedicate the above files to the public domain; do what you like with them. ;-)
Created attachment 166445 [details] Experimental ebuild for pipslite-1.2.0. I build with MAKEOPTS=j1 CFLAGS=-g -- note no optimization, probably required.
Created attachment 166446 [details, diff] Suppresses a warning about const-ness.
Created attachment 166448 [details, diff] Suppresses a warning about cast from pointer to too-small int.
Created attachment 180635 [details, diff] Patch to fix pipslite-wrapper craches Thanks stephen for your research. Unfortunately your ebuild and patches didn't work for me. Well they installed fine, but the wrapper still kept crashing. I've done searched for a while and finally found the problem. It's not a cups error, and maybe neither a driver error, but most likely a locale problem. The segmentation fault occurs, when the wrapper tries to parse the cups options, as it doesn't stop iterating through afor loop when unrecognized options are passed. The check for bailing out of the loop is done by by comparing the last option string to '/0', which doesn't work, as the last string is previously set to "". (weird thing, as both should actually be the same) Setting the string comparison to "", generates the correct results, and the for loop doesn't continue to read from invalid sddersses causing the segmentation fault. Attached is the patch for pipslite 1.3.0
Created attachment 180637 [details] pipslite-1.3.0 ebuild tarball I've also created a new ebuild for pipslite-1.3.0. Changes are: - added a fetch restriction, asthere is no direct link to the tarball anymore - it's redistributable anyways, so maybe on a laterp oint it can be removed - included my previous patch - added the autotools eclass enabling eautoreconf to work - removed the dodoc part, as it didn't work for me anymore (who needs documentation? :-P ) - fixed the backend symlink from eklp to pipslitelp I have to say that it works for me, hope it also works for you guys! Additional note: as this package is such a PITA, no wonder no one wants to maintain it...
Cool! Thanks for ebuild and patches, 1.3.0 with your patch works nicely here, even compiled with gcc-4.4 from svn.
(this is an automated message based on filtering criteria that matched this bug) 'EBUILD' is in the KEYWORDS which should mean that there is a ebuild attached to this bug. This bug is assigned to maintainer-wanted which means that it is not in the main tree. Heuristics show that no Gentoo developer has commented on your ebuild. 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
FYI: The last available version is already pipslite-1.4.0, which fixed the bug with wrong margins for me. Also patches for 1.3.0 are not needed anymore. I didn't provide an ebuild, because there are two different versions of 1.4.0, one "normal" and the second one that is marked suitable for 64bit arches and since I am running amd64 I tried only the latter. Basically you need to take an ebuild for 1.3.0, change version to the one you want and comment out all epatch commands.
Will there be any ebuild for 1.4.0?
Created attachment 207508 [details] ebuild for pipslite-1.4.0
here you are.
(In reply to comment #31) > here you are. > Thanks, I also copied the 1.3.0 and commented the epatch but there's an error in that ebuild. If you run with the --debug command to emerge you get: + for i in 'usr/$(get_libdir)/cups/filter/*' ++ echo 'usr/lib64/cups/filter/*' +++ get_libdir +++ local CONF_LIBDIR +++ '[' -n '' ']' +++ get_abi_LIBDIR +++ get_abi_var LIBDIR +++ local flag=LIBDIR +++ local abi +++ '[' 1 -gt 1 ']' +++ '[' -n amd64 ']' +++ abi=amd64 +++ local var=LIBDIR_amd64 +++ echo lib64 ++ sed -e 's/usr\/lib64\/cups\/filter\///' + dosym '/usr/lib64/cups/filter/*' usr/libexec/cups/filter/pipslite-filter usr/libexec/cups/filter/pipslite-wrapper usr/libexec/cups/filter/pipslitel2-filter /usr/lib64/portage/bin/ebuild-helpers/dosym: two arguments needed And when you try to run pipslite-install: # pipslite-install No such file or directory strace reveals: set_tid_address(0x7fa1ec7187c0) = 31498 set_robust_list(0x7fa1ec7187d0, 0x18) = 0 futex(0x7fff0a4e157c, FUTEX_WAKE_PRIVATE, 1) = 0 futex(0x7fff0a4e157c, 0x189 /* FUTEX_??? */, 1, NULL, 7fa1ec7186f0) = -1 EAGAIN (Resource temporarily unavailable) rt_sigaction(SIGRTMIN, {0x7fa1e86a47a0, [], SA_RESTORER|SA_SIGINFO, 0x7fa1e86adf10}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x7fa1e86a4830, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7fa1e86adf10}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 geteuid() = 0 open("/var/lib/cache/pipslite/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) mkdir("/var/lib/cache/pipslite/", 0755) = -1 ENOENT (No such file or directory) write(2, "No such file or directory\n"..., 26No such file or directory ) = 26 exit_group(1) = ?
yeah, that's a strange problem. to resolve it just create /var/lib/cache/pipslite directory.
Created attachment 207514 [details] New ebuild for 1.4.0 that fixes the dosym problem. This ebuild fixes the dosym problem of the previous ebuild. The bug occurred due to the fact that the installation tree was different than assumed by the script. the cups/filters dir was inside libexec, not inside /lib or /lib64 (result of $(get_libdir)).
Created attachment 207542 [details] Ebuild for pipslite with fixed symbolic links
yeah this (the new 1.4.0) installs with an error: >>> Checking whether we can merge to / .....................paludis@1256266269: [WARNING merger.empty_directory] In thread ID '4923': ... In program paludis (--continue-on-failure if-independent --dl-reinstall if-use-changed --show-reasons summary --log-level warning) --log-level warning --install --add-to-world-spec net-print/pipslite --continue-on-failure if-independent --serialised 0.37 package;=net-print/pipslite-1.4.0:0::local;installed;has_all_deps;T: ... When performing install action from command line: ... When executing install task: ... When installing 'net-print/pipslite-1.4.0:0::local': ... When merging 'net-print/pipslite-1.4.0:0::local' at '/var/tmp/paludis/net-print-pipslite-1.4.0/image' to VDB repository 'installed': ... When checking merge from '/var/tmp/paludis/net-print-pipslite-1.4.0/image' to '/': ... When checking merge from '/var/tmp/paludis/net-print-pipslite-1.4.0/image' to '/': ... When checking merge from '/var/tmp/paludis/net-print-pipslite-1.4.0/image/etc' to '/etc': ... When checking merge from '/var/tmp/paludis/net-print-pipslite-1.4.0/image/etc/init.d' to '/etc/init.d': ... Installing empty directory '/etc/init.d' and pipslited is not in /etc/init.d/ also, /usr/lib/ doesn't even have a cups directory in it, but all the files are in /usr/lib/libexec/cups/pipslite (not sure if this is what it's supposed to be) finally, /usr/bin has pipslited and pipslite-install, i ran pipslited fine (not sure if it did anything) but runnign pipslite-install gives me "No such file or directory" thanks also, any chance this'll get ported to sunrise?
First, thanks Andrzej and Paulo for the ebuild. Didn't test it, as I've already hacked my own, but never published it, as I run into similar problems like Omar. I don't know about the paludis issues, but for the rest (pipslite-install) it's about cups 1.4 and usblp. I'm not so sure whether pipslite-install needs usblp to be loaded to work, which might be blacklisted if you are running cups-1.4. It could also try to access the printer through cups, which then might not work, because the correct /dev/bus/usb/<id>/<id> the printer is attached to, is not owned by group lp, but by group scanner (if it's an all-in-one like mine). As far as I know there is still a lot of trouble with that part... Anyways, try to load usblp, and stop cups and run pipslite-install, or to give the proper rights to the usb device, and run it. At the end, somehow and hopefully you'll have a ppd file which you can load in cups. Once you have that, and all necessary pipslite files in /usr/libexec/cups/filter (yes it's correct) you're ready to go. You need to check the proper rights of the usb device each time you unplug your printer, or you switch it off, or you switch off the pc, or you change the cartridges, or you open the printer because of a paperjam etc.!! Said that.. I don't think this is ready to go anywhere... Mat
I also have the same permissions problem on the USB device. Unfortunately I have been setting them to 777 each time I print. I am not sure what the best solution is. Maybe is it possible to set a hal rule to set it to group lp and put the group scanner inside the group lp?
Hello, I hawe new Epson Stylus SX515W. I use last pipslite-1.4.0.ebuild, change its name to pipslite-1.5.0.ebuild and use the pipslite_1.5.0-2.tar.gz file and the Epson-Stylus_SX515W-pipslite-en.ppd file. At emerge time I get message: !!! doexe: /usr/local/portage.local/net-print/pipslite/files/pipslited does not exist doexe failed but all is working on amd64 and x86 platform.
From the upstream website: (Note: Photo Image Print System Lite is not available. We recommend users to use the latest version of Epson Inkjet Printer Driver (ESC/P-R) for Linux instead.)
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/
(In reply to Andreas K. Hüttel from comment #40) > From the upstream website: > > (Note: Photo Image Print System Lite is not available. We recommend users to > use the latest version of Epson Inkjet Printer Driver (ESC/P-R) for Linux > instead.) Upstream is gone. No idea where to get the source. Time for this bug to go too.
