Created attachment 541558 [details] version bumped to 1.0.18; ebuild by floppym I recently bought a new printer: Epson ET-4750. For this printer there is no ebuild currently in the tree. I contacted Mike Gilbert (floppym) who was kind enought to point me to his repository overlay which contains an ebuild for version 1.0.9 of the driver. https://bitbucket.org/floppym/floppym-overlay/src/master/net-print/epson-inkjet-printer-escpr2/ Since 1.0.9 isn't current anymore and I could only download 1.0.18, I simply modified the ebuild for the version bump to 1.0.18. This version compiled and installed correctly, but did not print - each page would be ejected by the printer without on dot of ink on it. Reason unknown. I then tested the binary package and this version printed correctly. I made ebuild for it as well, which I will upload here. I hereby request addition of net-print/epson-inkjet-printer-escpr2 (or net-print/epson-inkjet-printer-escpr2-bin) to the main Gentoo repository. This hardware is out there and it is in use by users. I would also like to find out what's wrong with the source ebuild. Help appreciated.
Created attachment 541560 [details] include as sys-libs/liblsb-compat This transitional ebuild is required because the binary CUPS driver of net-print/epson-inkjet-printer-escpr2 expects /lib/ld-lsb.so.3 (x86) and /lib64/ld-lsb-x86-64.so.3 (amd64). The ebuild is far from perfect, but it works; tested only on amd64. To add it to your local repository in /usr/local/portage, create directory sys-libs/liblsb-compat in it, safe the ebuild there and simply run "ebuild liblsb-compat-3.0.ebuild digest" and you're all set. No need to install it, it will be pulled automatically by net-print/epson-inkjet-printer-escpr2-bin.
Created attachment 541562 [details] binary package of epson-inkjet-printer-escpr2 version 1.0.18 This ebuild required the transitional sys-libs/liblsb-compat to function. It blocks the source package (and vice versa), so only one can be installed at a time. With this binary version my printer, an Epson ET-4750, prints as it should. Again, the ebuild is far from being perfect. But at least I get my printer to work for me. To use it, put it into your local portage overlay in /usr/local/portage under net-print/epson-inkjet-printer-escpr2-bin and run "ebuild epson-inkjet-printer-escpr2-bin-1.0.18 digest", then install it running "emerge net-print/epson-inkjet-printer-escpr2-bin". This will 1) pull sys-libs/liblsb-compat and it will block net-print/epson-inkjet-printer-escpr2, should it be installed already. To solve this blocker, unmerge net-print/epson-inkjet-printer-escpr2. This ebuild is intended as a transitional step until the source package works. But for this I need help - I don't know what's wrong with it. Thus this binary package is the only way to print AFAIK right now.
Created attachment 541672 [details] include patch from Arch Linux I finally found how to build /usr/lib64/libescpr2.la library. This is one change, the other one is a patch I took from Arch Linux. To include it, run: wget https://aur.archlinux.org/cgit/aur.git/plain/bug_x86_64.patch?h=epson-inkjet-printer-escpr2 -o /usr/local/portage/net-print/epson-inkjet-printer-escpr2/files/bug_x86_64.patch Here is the whole effort for printers from Arch Linux: https://wiki.archlinux.org/index.php/CUPS/Printer-specific_problems#Epson and here the driver epson-inkjet-printer-escpr2: https://aur.archlinux.org/packages/epson-inkjet-printer-escpr2/ Long story short: it compiles and installs, but the printer stalls with "rendering complete" and doesn't print...
Progress! The ebuild works and the printer apparently also works. At least from certain applications. When I print from LibreOffice or Firefox, everything prints okay. KDE on the other hand... What I've found out so far is that the Test Page from KDE's Printer configuration does print a test page, yes. But compated to the one I got from Debian Linux it is missing the driver details, i.e. it has the frame of the page, it has "Printer Test Page" written on top and below it the Tux with the printer, the colour and b/w gradients and the CUPS logo. Every other job from any other KDE application, namely Okular, simply stays at "Rendering complete" and doesn't print. What puzzles me is that the binary driver works from KDE, but the source version does not... WHY?!?
I just bought an Epson 3750 and found myself in the same situation. Before I found this bug (sorry) I submitted my own ebuild at : https://bugs.gentoo.org/663630 I wrote this very simple ebuild from scratch and it Works For Me (TM) Hope this helps, -cgw
*** Bug 663630 has been marked as a duplicate of this bug. ***
Created attachment 544592 [details] escpr2 (1.0.18) ebuild
Created attachment 544594 [details, diff] Patch for WF-C5790BA PPD file
Created attachment 544596 [details, diff] bug_x86_64.patch from Arch Linux
I have added my version of a working ebuild for escpr2, v. 1.0.18. Read the comments in the ebuild for some details. the ebuild applies two patches, one from Arch Linux ( bug_x86_64.patch) and one that corrects a redundant blank on the CUPS filter line of the WF-C5790BA PPD file ( Patch for WF-C5790BA PPD file). Some notes: I use x86 architecture - did not test it on anything else. On x86, I actually did not need the Arch Linux patch. Including it did not harm either. Experiment yourself and enable or comment the relevant lines in the ebuild. Works fine on my old Gentoo with net-print/cups 2.1.4. For those stuck in "Rendering complete..." ++++++++++++++++++++++++++ Set LogLevel debug in /etc/cups/cupsd.conf and check the error log. In my case, it was NOT the escpr2 filter, it was Ghostscript which exited with error at a two-page PDF! The details: There are three (3!) filters invoked in the process, as one can see from the log: ############################################################################ ... D [19/Aug/2018:00:38:51 +0200] [Job 514] 3 filters for job: D [19/Aug/2018:00:38:51 +0200] [Job 514] pstops (application/vnd.adobe-reader-postscript to application/vnd.cups-postscript, cost 66) D [19/Aug/2018:00:38:51 +0200] [Job 514] pstoraster (application/vnd.cups-postscript to application/vnd.cups-raster, cost 100) D [19/Aug/2018:00:38:51 +0200] [Job 514] epson-escpr-wrapper2 (application/vnd.cups-raster to printer/EPSON-WF-C5790BA, cost 0) ... I [19/Aug/2018:00:38:51 +0200] [Job 514] Started filter /usr/libexec/cups/filter/pstops (PID 18748) I [19/Aug/2018:00:38:51 +0200] [Job 514] Started filter /usr/libexec/cups/filter/pstoraster (PID 18749) I [19/Aug/2018:00:38:51 +0200] [Job 514] Started filter /usr/libexec/cups/filter/epson-escpr-wrapper2 (PID 18750) ... ############################################################################ i.e. CUPS undertakes a chain of transformations in order to print the PDF: 1. application/vnd.adobe-reader-postscript --> application/vnd.cups-postscript with pstops 2. application/vnd.cups-postscript --> application/vnd.cups-raster with pstoraster 3. application/vnd.cups-raster --> printer/EPSON-WF-C5790BA with epson-escpr-wrapper2 The culprit is NOT the EPSON escpr2 driver (no. 3 in the toolchain), as one is tempted to think at first. The culprit is also NOT pstops (no. 1 in the toolchain above), as we see from the log line: D [19/Aug/2018:00:38:51 +0200] [Job 514] PID 18748 (/usr/libexec/cups/filter/pstops) exited with no errors. The culprit is pstoraster (no. 2 in the toolchain)! pstoraszer uses Ghostscript - and Ghostscript exits with an unrecoverable error: D [19/Aug/2018:00:38:57 +0200] [Job 509] new_state=0, change_state=0 D [19/Aug/2018:00:38:57 +0200] [Job 509] Error: /undefined in BOJQFG+Sabon-Roman D [19/Aug/2018:00:38:57 +0200] [Job 509] Operand stack: D [19/Aug/2018:00:38:57 +0200] [Job 509] false D [19/Aug/2018:00:38:57 +0200] [Job 509] Execution stack: D [19/Aug/2018:00:38:57 +0200] [Job 509] %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1955 1 3 %oparray_pop 1954 1 3 %oparray_pop 1938 1 3 %oparray_pop 1820 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- D [19/Aug/2018:00:38:57 +0200] [Job 509] Dictionary stack: D [19/Aug/2018:00:38:57 +0200] [Job 509] --dict:1194/1684(ro)(G)-- --dict:1/20(G)-- --dict:94/200(L)-- --dict:57/75(L)-- --dict:211/313(L)-- --dict:72/140(L)-- --dict:0/10(G)-- --dict:0/10(L)-- --dict:0/50(ro)(G)-- --dict:56/71(L)-- --dict:1194/1684(ro)(G)-- D [19/Aug/2018:00:38:57 +0200] [Job 509] Current allocation mode is global D [19/Aug/2018:00:38:57 +0200] [Job 509] Last OS error: No such file or directory D [19/Aug/2018:00:38:57 +0200] [Job 509] GPL Ghostscript 9.15: Unrecoverable error, exit code 1 Solution -------- Other than upgrading Ghostscript and hoping, there is nothing you can do.. You can of course configure a RAW printer queue in CUPS and send your PDF directly to the printer (if your printer model supports direct PDF printing, as WF-C5790 does). Conclusion -------------- It's not always the manufacturer filter that is to blame for the ominous "Rendering completed..." problem! Keep an eye on Ghostscript!
Created attachment 550948 [details] version bump for binary package, 1.0.24 released 2018-10-08 Version bump. New binary package version 1.0.24, released 2018-10-08.
Created attachment 550950 [details] version bump 1.0.24, released 2018-10-08 Version bump to 1.0.24, released 2018-10-08. Patch for Epson-WF-C5790BA-epson-escpr2-en.ppd no longer necessary. Interestingly, this version Works-for-Me™. Thanks, segmentation fault, for your hints. I've set "LogLevel debug" in /etc/cups/cupsd.conf, but a test print from Okular just worked...
Created attachment 550952 [details] 1.0.24, released 2018-10-08, code cleanup + escprlib useflag ebuild clean-up. Question: should the x86_64.patch be always included or only on amd64? I left it in for all architectures for the moment, but I'm not sure how to proceed with this. The new USE="escprlib" useflags controls if the library gets to be included or not. I don't know for what it's needed... I made x86 and amd64 stable architectures and included ~arm and ~arm64, like segmentation fault did. But does it even build on arm?
Created attachment 557610 [details] version bump 1.0.27, released 2018-11-22
Created attachment 557612 [details] version bump binary package 1.0.27, released 2018-11-22
In my opinion epson-printer-escpr2 should be installed in the second slot (if possbile) because some printers are supported in v1 driver, and some are in v2. When we bump version to v2 older printers will not be supported.
(In reply to Andreas Thalhammer from comment #13) > Created attachment 550952 [details] > 1.0.24, released 2018-10-08, code cleanup + escprlib useflag > > ebuild clean-up. > > Question: should the x86_64.patch be always included or only on amd64? I > left it in for all architectures for the moment, but I'm not sure how to > proceed with this. > > The new USE="escprlib" useflags controls if the library gets to be included > or not. I don't know for what it's needed... > > I made x86 and amd64 stable architectures and included ~arm and ~arm64, like > segmentation fault did. But does it even build on arm? I think the x86_64 patch should be safe for 32-bit systems.
(In reply to Paweł Ciechomski from comment #16) > In my opinion epson-printer-escpr2 should be installed in the second slot > (if possbile) because some printers are supported in v1 driver, and some are > in v2. > When we bump version to v2 older printers will not be supported. There's no reason to slot or bump versions. "escpr2" is part of the name of the new package, '2' is not the version. The two packages can be installed side by side with no slotting. The epson-inkjet-printer-escpr2 installs its print filters as /usr/libexec/cups/filter/epson-escpr-wrapper2 /usr/libexec/cups/filter/epson-escpr2 and ppd files go into /usr/share/ppd/epson-inkjet-printer-escpr2 The library installed is /usr/lib64/libescpr2.so.1 so everything has 'escpr2' explicitly in the name already. I have both epson-inkjet-printer-escpr and epson-inkjet-printer-escpr2 installed here, there's no problem with both packages coexisting. I'm not sure what problem using slots would solve.
Created attachment 566378 [details] version bump 1.0.30, released 2019-01-30 I switched from rpm to tar.gz, which can be downloaded from Epson when choosing ARM. The src should be identical though.
Created attachment 566380 [details] version bump binary package 1.0.30, released 2019-01-30 Only the download links were modified - I didn't test this ebuild.
Created attachment 586094 [details] Bump version to 2.1.1.1-r1 Version bump to 2.1.1-r1 Update link to Epson download Patch Epson-WF-C5790BA-epson-escpr2-en-PPD.patch is no longer required
Created attachment 586098 [details] version bump 1.1.1, released 2019-08-01 cleaned up ebuild, .tar.gz file (rpm SRC_URI deleted) version 1.1.1 of epson-inkjet-printer-escpr2 was released on the 1st of August 2019 (08/01/2019).
Created attachment 586100 [details] version bump binary package 1.1.1, released 2019-08-01 cleaned up ebuild, version 1.1.1 released 08/01/2019, binary package (pulls sys-libs/liblsb-compat).
Andreas - I'm not 100% sure but I think the patch bug_x86_64.patch is still relevant and required.
Also noting that escpr2 works for me here without liblsb-compat, I'm not clear on why that's required.
(In reply to Charles G. Waldman from comment #24) > Andreas - I'm not 100% sure but I think the patch bug_x86_64.patch is still > relevant and required. Yes, I included it in my ebuild and I also think so. (In reply to Charles G. Waldman from comment #25) > Also noting that escpr2 works for me here without liblsb-compat, I'm not > clear on why that's required. I made two sets of ebuilds. The first one is the source package: * epson-inkjet-printer-escpr2 The second one is the binary package. * liblsb-compat * epson-inkjet-printer-escpr2-bin I had to include something like liblsb-compat because the binary driver need the LSB compliant /lib/ld-linux.so.2 or /lib64/ld-linux-x86-64.so.2 library, symlinks to the current version 3 are sufficient. And since I made the binary ebuild I had to make sure that either the source or the binary ebuild is installed, so I included a blocker for the other ebuild respecively (epson-inkjet-printer-escpr2 blocks epson-inkjet-printer-escpr2-bin and vice versa). At first only the binary driver worked for me, reason unknown. Now I also use the source version and it works as expected. I use these directories: (in /usr/local/portage) * net-print/epson-inkjet-printer-escpr2/files/bug_x86_64.patch * net-print/epson-inkjet-printer-escpr2/epson-inkjet-printer-escpr2-1.1.1.ebuild * net-print/epson-inkjet-printer-escpr2-bin/epson-inkjet-printer-escpr2-bin-1.1.1.ebuild * sys-libs/liblsb-compat/liblsb-compat-3.0.ebuild I cannot remove attatchments from others, otherwise these files can safely go: * escpr2 (1.0.18) ebuild, 2018-08-22 by segmentation fault * Patch for WF-C5790BA PPD file, 2018-08-22 by segmentation fault * Bump version to 2.1.1.1-r1, 2019-08-07 by Charles G. Waldman I don't understand how you came to a version number of 2.1.1.1-r1, otherwise your ebuild will do as well. The differences are minimal, but since mine were already there I just had to pump the versions. Also, I use the .tar.gz source tarball and no longer the rpm file.
Thanks Andreas. The upstream version is `escpr2-1.1.1-1` which I interpreted as `1.1.1-r1`. But the `r1` isn't needed. I could not delete my attachment, but I marked it as OBSOLETE. Thanks for working on this issue.
I can only find 1.1.1 here: http://download.ebz.epson.net/dsc/du/02/DriverDownloadInfo.do?LG2=EN&CN2=&DSCMI=97205&DSCCHK=bbb2ac98048a66c147bb9aa1b1b27bd5435fc196 Anyway, thanks for your work too. As for my ebuild: * I compared the source rpm with the source tar.gz and they are identical, so I thought the .tar.get would be a better choice... * I added use flags for functions provided by the source: USE=escprlib * I still also provide an ebuild for the binary driver, for completeness. I myself had issues with the source driver at first, so I made it, and since it's already made, why not keep it up-to-date as well? I find it sad that there is no way for others to update ebuilds in such a way that the previous one is marked obsolete. Because what we have now are multiple ebuilds by multiple users, and some of them are old. Also the desired directory structure is not obvious right away, but with ebuild referring to each other (i.e. pulling in another one like sys-libs/liblsb-compat, or blocking another one like net-print/epson-inkjet-printer-escpr2[-bin]) this could become confusing. Which reminds me: I will write this structure down with the next update. And finally I come back to my initial request towards the Gentoo developers: @Gentoo Dev Team: please include epson-inkjet-printer-escpr2 in the official tree, just like epson-inkjet-printer-escpr...
Created attachment 596054 [details] version bump 1.1.2, released 2019-10-16 Downloaded from http://download.ebz.epson.net/dsc/search/01/search/?OSC=LX by specifying a compatible printer, e.g. ET-4750. To get the .tar.gz I selected "ESC/P-R Driver 2 (generic driver) for ARM(AArch32)". The ebuild includes that direct download link.
Created attachment 596058 [details] version bump binary package 1.1.2, released 2019-10-16
Created attachment 603090 [details] version bump 1.1.3, released 2019-12-26 Downloaded from http://download.ebz.epson.net/dsc/search/01/search/?OSC=LX by specifying a compatible printer, e.g. ET-4750. To get the .tar.gz I selected "ESC/P-R Driver 2 (generic driver) for ARM(AArch32)". The ebuild includes that direct download link.
Created attachment 603092 [details] version bump binary package 1.1.3, released 2019-12-26
Created attachment 611716 [details] revised ebuild for version bump I bought an ET-3760 yesterday and went to set it up, but it looks like Epson takes down old versions of the driver when new versions are available. v1.1.6 was made available yesterday, so the ebuild was tweaked accordingly.
Created attachment 625396 [details] version bump 1.1.10, released 2020-03-16
Created attachment 625398 [details] version bump binary package 1.1.10, released 2020-03-16
I just wanted to report that with the new driverless printing capability of CUPS, the printer should also work without this package out-of-the-box. If the printer is detected, say, over the network with Avahi (Bonjour), it will be presented as "IPP (Everywhere)". This recently worked on one of my Laptops running Debian, so why should it not work on Gentoo? It is, however, not yet reflected in the Gentoo Wiki (https://wiki.gentoo.org/wiki/Printing). See also: https://www.pwg.org/ipp/everywhere.html https://github.com/apple/cups/wiki/IPP-(Everywhere)-Mini-Tutorial https://wiki.debian.org/CUPSIPPEverywhere I assume that when using a recent version of CUPS this will work without requiring a) this driver and b) any PPDs at all. I don't know if it would also work when the printer is connected over the USB bus.
Thanks Andreas, this is a very interesting development. I'll do some testing with my Epson 3750.
Can I suggest you try add this to GURU and/or possibly proxy-maint for this? It's going to be hard for most people to do it given that it requires a specific model of printer, but it'd help anyone in your situation. Obviously if floppym still uses it, you might be able to ask him nicely.
(In reply to sam_c (Security Padawan) from comment #38) > Can I suggest you try add this to GURU and/or possibly proxy-maint for this? > > It's going to be hard for most people to do it given that it requires a > specific model of printer, but it'd help anyone in your situation. > > Obviously if floppym still uses it, you might be able to ask him nicely. Of course, depending on if driverless works on Gentoo. :)
Created attachment 645334 [details] version bump 1.1.12, released 2020-05-20 Downloaded from http://download.ebz.epson.net/dsc/search/01/search/?OSC=LX by specifying a compatible printer, e.g. ET-4750. To get the .tar.gz I selected "ESC/P-R Driver 2 (generic driver) for ARM(AArch32)". The ebuild includes that direct download link.
Created attachment 645336 [details] version bump binary package 1.1.12, released 2020-05-20 The ebuild includes that direct download links for x86 and amd64.
Created attachment 645338 [details] include as sys-libs/liblsb-compat, updated 2020-06-19 (amd64 and x86) Needed for net-print/epson-inkjet-printer-escpr2-bin. This transitional ebuild is required because the binary escpr2 CUPS driver expects /lib/ld-lsb.so.3 (x86) and /lib64/ld-lsb-x86-64.so.3 (amd64). The ebuild should now also work on x86; it is still far from perfect, but works on amd64 and x86. To add it to your local repository in /usr/local/portage, create directory sys-libs/liblsb-compat to copy the ebuild into; then simply run "ebuild liblsb-compat-3.0.ebuild digest" and you're all set. No need to install it separately, it will be pulled automatically by net-print/epson-inkjet-printer-escpr2-bin.
Created attachment 652146 [details] version bump 1.1.15, released 2020-07-23 Downloaded from http://download.ebz.epson.net/dsc/search/01/search/?OSC=LX by specifying a compatible printer, e.g. ET-4750. To get the .tar.gz I selected "ESC/P-R Driver 2 (generic driver) for ARM(AArch32)". Instead of the full URL, now only the relative path (which is different with every version) is changed as a variable of the ebuild. The result is still a direct download link.
Created attachment 652148 [details] version bump binary package 1.1.15, released 2020-07-23 Instead of the full URL, now only the relative path (which is different with every version) is changed as a variable of the ebuild. The result is still a direct download link for x86 and amd64.
Be sure to get the newest bug_x86_64.patch from Arch Linux (2.27.0, see last line in bug_x86_64.patch after the download). In your local repository (as configured in your repos.conf, see https://wiki.gentoo.org/wiki//etc/portage/repos.conf), this directory structure must be used (. is your local repo base directory): # tree . . ├── net-print │ ├── epson-inkjet-printer-escpr2 │ │ ├── Manifest │ │ ├── epson-inkjet-printer-escpr2-1.1.15.ebuild │ │ └── files │ │ └── bug_x86_64.patch │ └── epson-inkjet-printer-escpr2-bin │ ├── Manifest │ └── epson-inkjet-printer-escpr2-bin-1.1.15.ebuild └── sys-libs └── liblsb-compat ├── Manifest └── liblsb-compat-3.0.ebuild To download the patch, change into the base directory of the local repo, then run (as root): wget -O net-print/epson-inkjet-printer-escpr2/files/bug_x86_64.patch https://aur.archlinux.org/cgit/aur.git/plain/bug_x86_64.patch?h=epson-inkjet-printer-escpr2 Don't forget to run "ebuild epson-inkjet-printer-escpr2-1.1.15.ebuild digest" in net-print/epson-inkjet-printer-escpr2 afterwards (actually, on any of the changed ebuilds).
Bump to 1.1.19 means that the URLs in 1.1.15 ebuild are gone. What's the way to go from one ebuild version to next?
So, once the ARM/tar.gz is selected after the search for your device (ET-3760 in my case), look at the page source and search for the download toward the end. That's where the URI to be used in the ebuild is.
Created attachment 662767 [details] version bump 1.1.19, released 2020-09-15
Created attachment 662770 [details] version bump binary package 1.1.19, released 2020-09-15
I've created a Gentoo repository for this. If anyone would like to test it, it would automatically update the driver IF I can manage to keep up-to-date myself. If anyone is willing to test this, create /etc/portage/repos.conf/escpr2.conf with this contents: ---- /etc/portage/repos.conf/escpr2.conf [escpr2] location = /var/db/repos/escpr2 sync-type = git sync-uri = https://gitlab.com/at.gentoo.repo/epson-inkjet-printer-escpr2 auto-sync = yes ---- Adapt the location to your needs (the default is /var/db/repos for gentoo anyhow, so I stick to this standard). Then run "emerge --sync escpr2" (or "emerge --sync", which should include the repo as well). This should make it easier to get a working ebuild from the start, and to get the versions updated. The only requirement is that you trust me, because I keep the repo running... :-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/api.git/commit/?id=64baf326b351215021c6d26b149282014de7d33f commit 64baf326b351215021c6d26b149282014de7d33f Author: Andreas Thalhammer <andreas.thalhammer@linux.com> AuthorDate: 2021-02-15 07:06:36 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2021-02-15 10:55:17 +0000 repositories: Add escpr2 Bug: https://bugs.gentoo.org/662364 Closes: https://github.com/gentoo/api-gentoo-org/pull/371 Signed-off-by: Michał Górny <mgorny@gentoo.org> files/overlays/repositories.xml | 11 +++++++++++ 1 file changed, 11 insertions(+)
Since my repository has benn added to repositories.xml, the preferred way (for new users at least) is to add it using "eselect repository": # eselect repository enable escpr2 For more information refer to https://wiki.gentoo.org/wiki/Ebuild_repository and https://wiki.gentoo.org/wiki/Eselect/Repository ... I try to keep up with updates as they emerge on http://download.ebz.epson.net/dsc/search/01/search/?OSC=LX and if I miss something, feel free to point it out.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/api.git/commit/?id=179ccbc4ecf80e6c0e1030d487573eee9a245291 commit 179ccbc4ecf80e6c0e1030d487573eee9a245291 Author: Andreas Thalhammer <andreas.thalhammer@linux.com> AuthorDate: 2021-09-22 08:48:06 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2021-09-22 08:48:57 +0000 repositories: name fix for repository escpr2-overlay Bug: https://bugs.gentoo.org/662364 Closes: https://github.com/gentoo/api-gentoo-org/pull/432 Signed-off-by: Joonas Niilola <juippis@gentoo.org> files/overlays/repositories.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
FYI: Driver tested with ET-5880 and works perfectly. Thanks a lot.
Created attachment 832227 [details] supported printer list (PPDs) for escpr2 version 1.1.55 (2022-11-11) A quick and dirty way to list supported printers for the current escpr2 version is this (works only when the package is installed): equery f net-print/epson-inkjet-printer-escpr2 | grep /usr/share/ppd/epson-inkjet-printer-escpr2 | sed 's/\/usr\/share\/ppd\/epson-inkjet-printer-escpr2\///' | sed 's/-epson-escpr2-en.ppd//' | tr '-' ' ' | tr '_' ' '
Help! Does anyone know how to fix those "error: implicit declaration of function XY" kind of compilation failures, other than adding CFLAGS="-Wno-implicit-function-declaration"? I ask because the old bug_x86_64.patch stopped working with version 1.2.10. Aleix Quintana Alsius created a new patch for 1.2.10 (which also works with 1.2.11) in the Arch User Repository (AUR), which I included in my repository as well. But, like the previous bug_x86_64.patch, it could at any time stop working again... The (to me) more important issue is that I don't understand this patch. Why is it even necessary? Because: it fails on Arch Linux, but the build succeeds without errors (i.e. warnings only) on Gentoo (at least on my Gentoo system). Is the reason as simple as different CFLAGS? And secondly: how is this even related to x86-64? Because I don't really get this connection... Here is the patch from Aleix: https://aur.archlinux.org/cgit/aur.git/tree/bug_x86_64.patch?h=epson-inkjet-printer-escpr2 I do get the includes, and the extern function declarations, but why patch int printHeight = 0; --> EPS_UINT32 printHeight = 0; and PrintBand (rever_buf, bandBmp.widthBytes, &printHeight); --> PrintBand ((const EPS_UINT8 *)rever_buf, bandBmp.widthBytes, &printHeight); and read (STDIN_FILENO, &page_num, 1); --> (void)read (STDIN_FILENO, &page_num, 1); and how should I proceed in the future with those kind of errors (which makes the build fail Arch, but gives only warnings on Gentoo)? In other words: if we were to say "Arch is not our concern", then why even include the patch in the first place? Or should we just make sure that CFLAGS don't include "-Wimplicit-function-declaration" and, if this was the case, patch them out? (If the CFLAGS were set so e.g. in the users make.conf, for example, this could make this build fail on Gentoo as well...) In short: If I understood this better, it would help me greatly. Thanks.
