Arch Linux User Repository

Yes, works like a charm now, thanks @vitaliikuzhdin!

Thanks for pointing to epson-inkjet-printer-escpr. Weird, I'm pretty sure that I tried that package at some point before, but it didn't work back then, that's why I switched to this package instead. However, I just tried again and it indeed works with that one as well. I'll test both and decide later what driver to use.

I'd love to test epson-pc-fax, the SX620FW indeed supports fax. Unfortunately I don't have a landline (or another fax-capable printer) to test with 😅 The last time I sent a fax was more than 5 years ago I guess (I vaguely remember), and before that surely at least 10 years. You could add a comment to ask for feedback if someone tries using it.

Thanks again for everything, have a good one!

@PhrozenByte, package updated, hopefully without problems this time.

Writing the comments in the PKGBUILD made me check the download page again, and turns out SX620FW is also supported by a (more) modern alternative epson-inkjet-printer-escpr, so you can probably safely switch to it without using this package. Sorry for wasting so much time, paper, and ink, but I guess it was still worth it for other packages -- not every old driver is supported by these more modern drivers.

By the way, the same page suggests your printer supports epson-pc-fax, which I've also recently uploaded to the AUR. Any chance you could give it a try? I haven't seen anybody actually request it and the tests would probably require another fax-enabled printer with more setup, so it's not that important.

Oh, and I've just made you a co-maintainer. Feel free to make adjustments or write helpful comments in the PKGBUILD. If you ever find a change that'll be needed for all other inkjet printers, leave a comment somewhere and I'll try my best to help.

Thank you very much.

Oh dear, I don't know how often I printed that cover letter to my health insurance (my test page for debugging) 🙈 CUPS totally lead me into the wrong directions at first.

Yes, it's the sed expression indeed. The filter doesn't like the absolute path in the PPD, i.e. the following leads to our demise:

--- /usr/share/cups/model/epson-inkjet-printer-workforce-635-nx625-series/EPSON_SX620FW_Series.ppd  2025-01-18 12:19:57.000000000 +0100
+++ /home/daniel/Downloads/EPSON_SX620FW_Series.ppd 2025-01-18 12:19:13.096305387 +0100
@@ -30,7 +30,7 @@

 *cupsLanguages: "ja en nl fr de it pt es ru ko zh zh_TW"
 *epcgCoreLibrary: "libEpson_WorkForce_635_60_NX625.so.1.0.0"
-*epcgResourceData 1: "Epson_WorkForce_635_60_NX625.1.data"
+*epcgResourceData 1: "/usr/share/epson-inkjet-printer-filter-lsb/resource/Epson_WorkForce_635_60_NX625.1.data"
 *epcgWatermarkData Confidential: "/usr/share/epson-inkjet-printer-filter-lsb/watermark/WEPCG00.EID"
 *epcgWatermarkData Draft: "/usr/share/epson-inkjet-printer-filter-lsb/watermark/WEPCG01.EID"
 *epcgWatermarkData Urgent: "/usr/share/epson-inkjet-printer-filter-lsb/watermark/WEPCG02.EID"

So, this made me thinking... What if we actually switched one issue (LDFLAGS) by another (sed) and we don't actually need the LSB filter? Especially together with your explanation of EPSON's weird packaging choices (thanks for the explanation btw)? So, I checked the commits and indeed: That sed expression slipped in with pkgrel 14, i.e. with the revert back to the non-LSB filter and before we understood the issue with LDFLAGS. For my recent "It works" test I was using pkgrel 13, i.e. without that sed expression. So, what if we don't need that LSB filter after all?

And here we are: I just installed it with the non-LSB filter but the LDFLAGS hack applied, and without that sed expression, and voila, it works!

So, you can delete the LSB filter package once again (for good I hope 😂) and use the following PKGBUILDs: epson-inkjet-printer-workforce-635-nx625-series and epson-inkjet-printer-filter (.SRCINFO needs updating as well of course)

Again, thank you very, very much for your extensive support and help @vitaliikuzhdin!

@PhrozenByte, could this be because of the last sed expression at line 39?

Argh, I'm terribly sorry, but it doesn't work with the new packages for some reason :-( I feel like this EPSON driver just wants to drive both of us mad.

I'll investigate, just wanted to comment quickly before you go through all other driver packages. I checked your changes and can't see a reason why. But it's pretty late in my timezone already and I feel like I can't fully concentrate on this anymore, so before making mistakes and leading you into wrong directions, let me investigate tomorrow. Sorry. I'm the one who needs to be thankful. So, thanks again for your amazing help!

@PhrozenByte, packages updated, they should work out of the box now.

As for the filter versions, the lsb version and pkgrel=10 both actually use 1.0.0, from the same source archive. If you download the .src.rpm from the link above, you'll see not one but two .tar.gz archives inside it:

epson-inkjet-printer-filter-1.0.0.tar.gz
epson-inkjet-printer-workforce-635-nx625-series-1.0.1.tar.gz

So, the filter is of version 1.0.0 and the files for this printer model are of version 1.0.1. Weirdly, the identical 1.0.0 filter is shipped for all LSB-dependent (older) drivers, and the same 1.0.2 is shipped for all newer drivers. What's even weirder is that you can't download just the filter, so for epson-inkjet-printer-filter* packages, I have to download a random model and then extract the filter archive. Who knows why Epson decided this is the best way to distribute sources.

Anyway, thanks a lot for your patience and help with debugging. Sorry for breaking your printing workflow until we managed to solve it. Guess I'll have to update about 60 LSB-dependent drivers now.

Yeah, sure, let's debug it further first. Again, thanks for the help! About the additional testing and your questions:

1. Yes, ghostscript is installed, extra/ghostscript 10.04.0-1 [installed] to be precise.

2. I've applied the #4 patch (plus -i option, i.e. patch -NRp1 -i "${srcdir}/${pkgname}_test.patch") to epson-inkjet-printer-filter and with the LDFLAGS hack, unfortunately nothing changes (printer prepares printing, but then bails).

3. I then tried again with epson-inkjet-printer-filter-lsb, this time with the LDFLAGS hack. It works! :tada: Note that I'm not using export for LDFLAGS, but passing it as an argument to ./configure, but this shouldn't make a difference I guess. Last but not least, here's the log if you need it: /tmp/epson-inkjet-printer-filter.txt (unchanged filename btw, doesn't seem to matter, I just noticed)

So, epson-inkjet-printer-filter-lsb with the LDFLAGS hack is indeed the solution. It wasn't the path after all. No idea how this additional EPS_PAGEATTRIB_RETAIN_SIZE attribute could break things (especially since CUPS doesn't seem to even request it?), but it somehow does. What's the difference between v1.0.0 of epson-inkjet-printer-filter-lsb and v1.0.1 previously used by this package with pkgrel 10? Any hints there maybe?

Thank you very, very much @vitaliikuzhdin!

@PhrozenByte, thank you for the research. Yes, I was also planning on reverting the changes completely if we can't get it to work. But first, let's try a few more ideas, if you don't mind:

1. Are ghostscript and libjpeg-turbo installed? I'm 99% sure they are, but it feels wrong not to make sure.

2. Thank you for questioning whether the build fix was the only difference in the filter versions. Here is the full diff, omitting auto-generated files and changed years. Reading through, the only change, apart from the fixbuild and the parts I will discuss below, is the addition of a new function, which shouldn't break anything.

3. I will re-add export export LDFLAGS+=" -Wl,--no-as-needed" to the filter PKGBUILD once we decide how to move forward here, since it wouldn't hurt to have it anyway and might solve some issues. The reason I even removed it initially is that it creates an 'unused' (as I thought) dependency, and not having it works for newer models.

4. As you can see from the diff, the new version lacks the flag -fsigned-char for the pagemanager part. Could you please try to recompile the filter with it via this patch (you can apply it with patch -NRp1 ${srcdir}/patchname.patch, but notice the additional R in the command)?

5. If the old and new versions of the filter are indeed incompatible, there is still a good chance we can just have two of them. Could you please try to add export LDFLAGS+=" -Wl,--no-as-needed" to epson-inkjet-printer-filter-lsb and try the version of this package which depended on it? I have already deleted it, but you can still access it via git clone https://aur.archlinux.org/epson-inkjet-printer-filter-lsb.git

I'm sorry if I'm over- or under-explaining some parts. If you need me to provide full PKGBUILDs and patches for the experiments instead of explaining how to get them yourself, I will happily do so.

Thanks for the great explanations @vitaliikuzhdin! Sounds reasonable and makes sense to me (as someone without any experience with developing with C/C++).

So, I just tried a few things:

1. Moving both or one of the libraries (you meant libEpson_WorkForce_635_60_NX625.so.1.0.0 and libEpson_WorkForce_635_60_NX625.MT.so.1.0.0, right?) didn't work. The filter bails with Failed to dlopen(libEpson_WorkForce_635_60_NX625.so.1.0.0)->/usr/lib/libEpson_WorkForce_635_60_NX625.so.1.0.0: cannot open shared object file: No such file or directory (logged in /tmp/epson-inkjet-printer-filter.txt) then.

2. patchelf ultimately didn't work, but at least got me a little further. The filter didn't bail immediately and CUPS sends data to the printer, causing the printer to do its usual "preparing to print" stuff (i.e. I can hear the printer do its preparation steps), but stops right before feeding paper and printing. Now the filter's logfile isn't showing anything suspicious, it is just cut off (compare with #3 below). Since it might be interesting to see at which point it bails now, I'm providing the full CUPS logs now (note that I restarted a failed job because the log is less cluttered then, a new job shows the same behaviour though): /tmp/epson-inkjet-printer-filter.txt /var/log/cups/error_log (error at line 334)

3. I also switched back to pkgrel 10 with --enable-debug and one can clearly see in the filter's debug logs where the filter bails with newer pkgrels. Printing still works with pkgrel 10 and the logs seem to indicate that everything works fine (i.e. no limitations as you suspected)? I didn't include the CUPS logs here because everything works smoothly there. See here: /tmp/epson-inkjet-printer-filter.txt

4. While working on #3 I noticed that ./configure was executed with LDFLAGS="$LDFLAGS -Wl,--no-as-needed" with pkgrel 10, but not with later pkgrels. So I just built the latest epson-inkjet-printer-filter with these LDFLAGS, but no luck. In fact, I got the exact same result as with #2 / patchelf - i.e. it looks like this issue existed before, but was fixed with these LDFLAGS. So, the only remaining difference is that epson_inkjet_printer_filter uses a newer version (does it?) and the install path?

You got any other ideas? If not, how about a new pkgrel basically going back to the pkgrel 10 approach with files below /opt/${pkgname} and without the (unfortunately not working) shared filter for this package only?

@PhrozenByte, just looking up the filter error was really helpful. It seems that Epson developers either used gcc on C++ code which would normally be compiled with g++ and did not append -std=c++11 or -lstdc++. I had already noticed this while packaging, since all newer drivers (without the lsb3.2 postfix) depend on gcc-libs (which provides libstdc++.so.6), but the older ones, like this one, don't.

The problem is that these libraries are proprietary, and all solutions on the web just suggest recompilation with proper linker flags, which we can't do. Although I'm not sure this will work, you can try installing patchelf and executing this:

patchelf --add-needed libstdc++.so.6 /usr/lib/libEpson_WorkForce_635_60_NX625.so.1.0.0

I do wonder why it worked for you in the old installation. My theory is that the libraries were previously installed into /opt/${pkgname} and were thus never even seen by LD, so you could run the printing process with some limitations but no errors. You can try rming (or just renaming) the libraries to test this.

Another thing that might be helpful is installing the old version of this package but with the --enable-debug flag. Who knows if there will be anything interesting.