Created attachment 765376 [details] Apdapted ebuild from github.com/qix67/gentoo-overlay We currently only have media-gfx/brscan4 in portage. Newer Brother scanners (in my case a DS-640) need the currently available brscan5 driver to work properly. I took the brscan5 ebuild from https://github.com/qix67/gentoo-overlay (the only one I could find) and adapted it to work with the currently available version 1.2.9-0 of the brscan5 driver. It works without a problem. I think the ebuild would need some refactoring though, as it e.g. does not set the correct source URI for the x86 version and probably also has some other flaws. However, it would be nice if portage supported this brscan generation. Thanks in advance for adding official support for brscan5!
Created attachment 765377 [details] The brother5.conf file from files/ installed by the ebuild
I do not understand, if this is a version bump of brscan4, or something new. HOMEPAGE="http://welcome.solutions.brother.com/bsc/public_s/id/linux/en/index.html" is 404 Should we use https://support.brother.com ?
To reach the download page for the brscan driver, you actually have to search for some product, select "Linux", possibly "English", and then you see it. I think there's no direct link we could add, so https://support.brother.com/ is the starting point to begin. I'm not sure if brscan5 is something new either ... but I'm running an old manual installation of brscan3 on another machine (to access the scanner part of a Brother MFC printer/scanner/fax). So I could try out if that also works with brscan5. If the newer brscan versions support everything the older ones did, I think we should consider to call it "brscan" and move the obvious major version to where it belongs, no? Maybe some other Brother user can also check this out? I don't think we'll get information from Brother themselves ... Apart from that: The ebuild says: DESCRIPTION="SANE driver for Brother DS-series scanners (brscan5)" Actually, brscan also supports e.g. the scanners built into the MFC multifunction devices. So possibly, the "Brother scanner driver" we currently have in the tree is more applicable. Also, the SRC_URI is most probably a generated one that emerged whilst searching downloads for a specific device. But IIRC, one has to download the package manually anyway (and as said, the x86 version is not present). Also, the current tree ebuild says LICENSE="Brother" whereas the attached one says LICENSE="Brother-EULA" ... As said, the thing works but definitely needs some love ;-)
In the brother-overlay ( https://github.com/gentoo-mirror/brother-overlay ), they have distinct ebuilds for the different brscan versions: media-gfx/brother-scan2-bin media-gfx/brother-scan3-bin media-gfx/brother-scan4-bin (no ebuild for version 5 yet) Maybe, these should actually be added to the main portage tree? At least, I think that the people maintaining the Brother overlay will know what's up with those, and they will have a reason to keep different versions.
All newer (since 2014 at least) scanners or multi-function devices from Brother should support driverless scanning over the network with avahi/zeroconf. Therefore these scanner drivers are pretty much legacy; they are only needed for older devices, or if you connect the scanner via USB. Generally Brother recommends a specific driver package like brscan3 or brscan4 for your device, so it would make little sense to combine these different drivers in one package. Reassigning to maintainer-wanted, because I don't have any device to test this. (And see above, if I had then I'd use it driverless.)
> And see above, if I had then I'd use it driverless. ... unless you have an USB-only scanner, like the DS-640 ;-)
Created attachment 869129 [details] Updated ebuild for eapi 8 and brscan5-1.2.13-0
(In reply to Ulrich Müller from comment #5) Just to point this out once again: > All newer (since 2014 at least) scanners or multi-function devices from > Brother should support driverless scanning over the network with > avahi/zeroconf. Of course, we should use driverless scanning for multi-function devices. But this is not about those, but pure scanners that don't connect to the LAN and are USB-only. > Therefore these scanner drivers are pretty much legacy; they > are only needed for older devices, or if you connect the scanner via USB. ... and for those exact devices, in my case a Brother DS-640 mobile document scanner, those drivers are certainly not "legacy" but simply the only way to use them at all.
(In reply to Tobias Leupold from comment #7) > Created attachment 869129 [details] > Updated ebuild for eapi 8 and brscan5-1.2.13-0 Can you provide a copyright signoff please? Either by committing the new package to git and attaching the file obtained by "git format-patch" to this bug (much preferred), or by posting the Signed-off-by line as a comment. https://www.gentoo.org/glep/glep-0076.html#certificate-of-origin Also, would you volunteer as a proxied maintainer for this package?
Created attachment 874466 [details, diff] git patch for the build Well, as I'm using this on a regular basis, I can as well proxy-maintain it; at least I can try to do so (as this seems to be a quite complicated ebuild ...). Here's the signed-off git format-patch output.
(In reply to Tobias Leupold from comment #10) > Created attachment 874466 [details, diff] [details, diff] > git patch for the build > > Well, as I'm using this on a regular basis, I can as well proxy-maintain it; > at least I can try to do so (as this seems to be a quite complicated ebuild > ...). > > Here's the signed-off git format-patch output. Thank you. The ebuild should be in the media-gfx/brscan5/ package directory, not at top level of the repository. Also, could you add a metadata.xml for the package? (grep for proxy-maint in other metadata.xml files if you need an example.)
I had to pull this into my local overlay to get a borrowed USB-only scanner working in a pinch. (brscan4 resulted in pages only being half-scanned, but brscan5 resolved the issues. It's entirely likely that this was user error.) Just as a heads-up: the ebuild uses rpm_unpack to extract the blob from Brother, so I had to modify it to have app-arch/rpm listed as a BDEPEND.
I'll try to update it ...
(In reply to Suvi Adams from comment #12) > Just as a heads-up: the ebuild uses rpm_unpack to extract the blob from > Brother, so I had to modify it to have app-arch/rpm listed as a BDEPEND. rpm_unpack() uses rpm2tar from app-arch/rpm2targz (which is added to BDEPEND by the eclass), so not sure why you would need app-arch/rpm?
(In reply to Ulrich Müller from comment #14) > (In reply to Suvi Adams from comment #12) > > Just as a heads-up: the ebuild uses rpm_unpack to extract the blob from > > Brother, so I had to modify it to have app-arch/rpm listed as a BDEPEND. > > rpm_unpack() uses rpm2tar from app-arch/rpm2targz (which is added to BDEPEND > by the eclass), so not sure why you would need app-arch/rpm? Oh shoot, now I feel rather silly! I can confirm that my previous comment was completely incorrect. I forgot to put brother5.conf into files/, and somehow completely failed to realize that I'd not attempted a rebuild between fixing that and adding app-arch/rpm into the BDEPEND. I'll do my best to learn from this, but sorry to waste everyone's time!
You're welcome :-) Thanks for confirming the raison d'être of this ebuild ;-)
