pkgs/misc/cups/drivers: add brother mfcl3770cdw

[steveej]

This adds the printer driver for the Brother MFCL3770CDW.
It combines the cups-wrapper and the driver in one file which allows
sharing common variables and making it less error-prone than the other
Brother drivers in repository.

I volunteer for maintaining this one as long as I've got the model
around.

Motivation for this change

New driver for new hardware.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Assured whether relevant documentation is up to date
• Fits CONTRIBUTING.md.

---

[samueldr]

Hi!

Quick question / heads-up, depending: does your printer driver hard-code some settings, e.g. page size to A4? See #53027 and a discourse post.

My Brother printer's driver, and a couple other user's is seemingly disregarding the settings set in the print. As far as I was concerned, this was hard to spot until I realized what was going on.

Thanks.

(Additionally, looks like there's a merge conflict.)

[steveej]

@samueldr It seems to be the case here too. I have tried to print on portrait A5 (A4 split in half) and the result was as if the paper was A4. Are you suggesting to block this PR on that issue?

[samueldr]

@steveej since a bunch of the drivers in Nixpkgs already share the flaw I wouldn't block.

Though it would be nice to get a taskforce (1) looking at and fixing the issue (2) making a brother driver helper/builder that handles the common formats; after all it seems that they are generally similar when close in age.

[steveej]

@samueldr Alright, I will take a stab at it eventually. Can't be that bad to debug a CUPS issue 🙃

WRT this PR, CI should turn green now.

[samueldr]

I don't know if the "callPackage an expression returning an attrset" is frowned upon in that kind of situation, but I don't personally see anything wrong with it.

Other than the nits and changes asked, seems good.

[veprbl]

I believe this driver needs to follow the same form as mfcl2740dwlpr/mfcl2740dwcupswrapper and mfcl8690cdwlpr/mfcl8690cdwcupswrapper. If we later need to do the refactoring, we do it to all drivers at once.

Having said that, I see that the mentioned drivers set interpreter path in this way:

nixpkgs/pkgs/misc/cups/drivers/mfcl8690cdwlpr/default.nix

Line 34 in d484f2b

interpreter=${pkgs.pkgsi686Linux.glibc}/lib/ld-linux.so.2

nixpkgs/pkgs/misc/cups/drivers/mfcl8690cdwlpr/default.nix

Line 34 in d484f2b

interpreter=${pkgs.pkgsi686Linux.glibc}/lib/ld-linux.so.2

So I believe that solving issue raised in #55531 (comment) is not required to merge this PR.

I propose we do the simple refactoring and merge this.

[steveej]

I believe this driver needs to follow the same form as mfcl2740dwlpr/mfcl2740dwcupswrapper and mfcl8690cdwlpr/mfcl8690cdwcupswrapper. If we later need to do the refactoring, we do it to all drivers at once.

While I'm aware that this PR takes a different approach I don't agree that it needs to follow the existing one. A further refactor could take this one as an example, or unify all of them to an even different one.

[veprbl]

@steveej In your approach you bind driver attribute into your implementation of cupswrapper (see line 66), so one will not be able override the cupswrapper with a different driver. I don't know why you disagree with the current approach, but at least it provides a way override things using the .override provided by the callPackage.

[steveej]

@veprbl Making driver overrideable is a good suggestion, thanks! I think it's not a difficult change to add here. The approach is motivated by trying to minimize redundancy between the driver and the wrapper.

[steveej]

@samueldr please take a look at the changes I made recently, and see if your comments are addressed appropriately.

[samueldr]

As far as what I assked, it looks fine.

I assume this was tested at every step by yourself, as obviously not many users will have that particular printer :).

[steveej]

@samueldr

I assume this was tested at every step by yourself, as obviously not many users will have that particular printer :).

I've been using the printer on my system and it works OK, besides the side-effects you've mentioned in #55531 (comment) already. It's not bad enough to really debug the issue though.

[steveej]

@samueldr I don't have merge access, would you mind merging this as you've approved it? Or are you waiting for another maintainer to double-check?

[veprbl]

Here is a way to improve overridability:

inherit driver;
installPhase = ''
  basedir="$driver/${reldir}"