search

stefan-langenmaier / brother-overlay

Portage overlay for Brother printer and scanner software
GNU General Public License v3.0
34 stars 41 forks source link

net-print/brother-mfc6490cw-bin: new ebuild #75

Closed mehw closed 4 years ago

mehw commented 4 years ago

Fixes #72.

Add Brother MFC-6490CW CUPS and LPR support.

Please, don't hesitate to provide suggestions.

Credits

printer-drivers overlay, especially to the original author/maintainer (see metadata.xml).

Tasks to confirm/verify

Details

This ebuild merges net-print/brother-mfc6490cw-cups and net-print/brother-mfc6490cw-lpr drivers:

Patching binary files

/usr/local/Brother/Printer was changed into /opt/brother/Printers, which is the default directory used by many other net-printer's Brother drivers, like brother-mfc9130cw-bin.

Here is illustrated the method used to modify the binary files (the full path and name of files may be omitted for brevity):

$ objcopy --dump-section .rodata=brprintconf_mfc6490cw.dump brprintconf_mfc6490cw
$ objcopy --dump-section .rodata=brmfc6490cwfilter.dump brmfc6490cwfilter
$ dhex brprintconf_mfc6490cw.dump (search/replace the location as specified before)
$ dhex brmfc6490cwfilter.dump (search/replace the location as specified before)
$ cp brprintconf_mfc6490cw.dump brmfc6490cwfilter.dump net-print/brother-mfc6490cw-bin/files

The dumps are restored with something like the following (see the ebuild for exact commands):

$ objcopy --update-section .rodata=brprintconf_mfc6490cw.dump brprintconf_mfc6490cw
mehw commented 4 years ago

Hi @stefan-langenmaier,

I see there are a lot of Travis failures due to some drivers in this overlay.

If I'm not mistaken, brother-mfc6490cw-bin fails due to a file.size-fatal:

(92 KiB) net-print/brother-mfc6490cw-bin/files/brmfc6490cwfilter-1.1.2_p2.rodata

I have no error emerging the ebuild on my PC. I don't get it, I'm not aware of any file size limit.

What do you suggest?

stefan-langenmaier commented 4 years ago

Thanks for the explanation concerning the binary patching. I think I can see now the issue with the binary file. If I understand correctly the dhex step is difficult to automate.

mehw commented 4 years ago

First of all thanks for this detailed pull request.

You're welcome!

My only real question is why are you adding the binary files, when the files could also be generated?

LPR's brmfc6490cwfilter and brprintconf_mfc6490cw are closed source. They have a hardcoded path pointing to /usr/local/Brother/Printer. To be consistent with other drivers in net-printer, I've changed that to /opt/brother/Printers.

If I understand correctly the dhex step is difficult to automate.

I did use dhex only to create the patches for the binary files from above. The hardcoded path is in the .rodata section, objcopy can dump that easily, then I did a manual edit to the dumped sections, and the patching of the LPR binary files is done by objcopy from the ebuild importing back the edited dumped sections which reside in the files directory.

mehw commented 4 years ago

cupswrapper is now built from GPLv2 source code.

Also, the new way to patch LPR binary files, done directly form the ebuild itself via printf and objcopy, should solve the Travis file.size-fatal failure error.

I did a couple of forced pushes to fix some Travis complaints. First a digest.unused and then a ebuild.minorsyn (unquoted variable).

I see that there are a lot of ebuild.badheader errors like the following:

media-gfx/brother-ads1000w-bin/brother-ads1000w-bin-1.0.ebuild: Stale CVS header on line: 3

What do you think @stefan-langenmaier? IMHO those should be easily fixable, as I did before following your advice.

stefan-langenmaier commented 4 years ago

First of all, this is amazing work! I'm learning a lot. Thanks for putting in the effort to avoid the binary files and patching the files directly in the ebuild. This will be a lot clearer to the next user.

Also very cool to use the source for the cups driver. I hope that one day some of the drivers can be used on other architectures/we can avoid the binary files. But you are right

IMHO those should be easily fixable [...]

there are other things to fix at the moment with the repository. These issues should be easily fixable. Unfortunately I didn't tend enough to the repo in recent times. If you want to look into cleaning this up a little bit, I'd be very happy, but again thanks a lot for this very thorough PR.

I think an even more important step will be to write some documentation/structure/eclasses to share common functionality between ebuilds as they have drifted a part/there are by now a lot more than I have anticipated. :) Your ebuild can be a good source/template for this.

mehw commented 4 years ago

Thanks for merging!

I hope that one day some of the drivers can be used on other architectures/we can avoid the binary files.

You are right, the drivers should be compiled from source whenever it's possible. But unfortunately, the source code is not always made available...

If you want to look into cleaning this up a little bit, I'd be very happy, but again thanks a lot for this very thorough PR.

I may look into it, at least the more trivial stuff.

I think an even more important step will be to write some documentation/structure/eclasses to share common functionality between ebuilds as they have drifted a part/there are by now a lot more than I have anticipated. :)

That will be cool! I have a lot to learn here. I hope you are not in a hurry. This is an incentive to do some experiment. Who knows what may sprout...

Fixing Travis errors may be a start.

Cheers!