Search Criteria
Package Details: brscan4 0.4.11_1-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/brscan4.git (read-only, click to copy) |
---|---|
Package Base: | brscan4 |
Description: | SANE drivers from Brother for compatible models |
Upstream URL: | http://support.brother.com |
Keywords: | scanner |
Licenses: | GPL, custom:brother |
Submitter: | Harvey |
Maintainer: | Harvey |
Last Packager: | Harvey |
Votes: | 150 |
Popularity: | 2.36 |
First Submitted: | 2011-08-01 08:43 (UTC) |
Last Updated: | 2022-01-09 14:34 (UTC) |
Dependencies (2)
Required by (59)
- brother-dcp-b7500d (optional)
- brother-dcp-j752dw (optional)
- brother-dcp-l2500d (optional)
- brother-dcp1510 (optional)
- brother-dcp1610w (optional)
- brother-dcp1618w (optional)
- brother-dcp7070dw-cups (optional)
- brother-dcp9017cdw (optional)
- brother-dcpj525w
- brother-dcpj562dw (optional)
- brother-dcpj572dw (optional)
- brother-dcpj785dw (optional)
- brother-dcpj925dw (optional)
- brother-dcpj987n-cups-bin (optional)
- brother-dcpl2520dw (optional)
- brother-dcpl2530dw (optional)
- brother-dcpl2540dw-cups (optional)
- brother-dcpl2550dn (optional)
- brother-dcpt220 (optional)
- brother-dcpt310 (optional)
Latest Comments
jemzipx commented on 2022-05-06 09:35 (UTC) (edited on 2022-05-06 09:36 (UTC) by jemzipx)
Works great with simple-scan and Brother DCP-L3551CDW. Thanks a lot.
Harvey commented on 2022-04-06 18:10 (UTC)
@PC2022: Thanks for sharing your findings. I don't know this particular model, I have a ADS-3000CN here which has a web interface to set some of the basic settings i.e. paper size.
PC2022 commented on 2022-04-06 16:49 (UTC)
Here's my findings for a Brother ADS-2600W using scanimage (multiple pages, A4, double sided, PDF output)
To scan more than one page, you need to use --batch, which also means you cannot specify an output filename using -o. Instead the scan is written to current directory as out1.pdf
To scan A4, you also need to specify the document height in mm, otherwise it defaults to 410mm which is far too long.
scanimage -d 'brother4:net1;dev0' --source='Automatic Document Feeder(left aligned,Duplex)' --mode='24bit Color[Fast]' --resolution=600 --format=pdf --batch -y 298
Balamku commented on 2021-11-30 12:22 (UTC)
Works with xsane on Brother MFC L3750 CDW (with the printer being auto detected CUPS; not using the dedicated printer package) Thx!
ettavolt commented on 2021-08-05 09:26 (UTC)
@Konzertheld: your MFC-L2710DN seems to be connected by Ethernet, is it really so? Did you try connecting via USB? Also, how well does it react to printing requests?
Harvey commented on 2021-08-05 09:17 (UTC) (edited on 2021-08-05 09:18 (UTC) by Harvey)
Glad it's not my fault ;) Hope you find the problem. Anyway, thanks for reporting back.
Konzertheld commented on 2021-08-04 13:34 (UTC)
@Harvey XSane doesn't work for me, scans only one page, but I just tested scanadf and it worked, so not an issue with this package I suppose.
Harvey commented on 2021-08-04 10:45 (UTC)
@Konzertheld: Just tested with XSane under Wayland - works... But I am not a crack concerning Wayland as my laptop freezes the GUI when using a second monitor. So there might be more than meets the eye ;)
Konzertheld commented on 2021-08-03 21:55 (UTC)
Hello, I've been having trouble scanning since I switched from Gnome+X to Gnome+Wayland, so I kindly ask for assistance in searching for the error, be it Wayland related, related to re-installing the system (which I did at the same time) or something else just coinciding with the other two. These problems are not related to the April 21st update of this package, they were there before.
a) After every reboot, I have to enter my root password when I scan something for the first time. I use simple-scan and when I close it afterwards and open it later without reboot or logging out, no password is needed.
b) Worse, I can only ever scan one page from the ADF. The scanner pulls the others and simple-scan waits for it to do so but does not scan them, it only retrieves the first one and then throws a kinda generic error message after the last page has been pulled through by the scanner.
c) Also, I used to see the progress of the page while being scanned. Now I only see the page pop up as whole after it was scanned.
For the sake of readability, I pasted my log elsewhere. Also note how slow everything is. I use a MFC-L2710DN as can be seen there. https://pastebin.com/skCX4dFV
Thanks for reading.
Harvey commented on 2021-07-27 15:06 (UTC)
@maxfranco: Well looking into this I found that libavahi-client.so.3 is a dependency brought in by sane. It seems the -q query option depends on this (which makes perfect sense) - but there is no need to include it as sane should pull it in anyway.
Harvey commented on 2021-06-28 14:06 (UTC) (edited on 2021-06-28 14:06 (UTC) by Harvey)
@maxfranco: will take a look as soon as possible. Namcap is throwing some more errors I will have to investigate, but it does not point out avahi as a missing dependency. As it is working for you with avahi installed it is not completely broken at least ;)
purpleleaf commented on 2021-06-22 13:13 (UTC)
@ Harvey i'm working with a MFC-J470DW wifi scanner. I installed brscan4 then tried to add my scanner with: brscan4 -a brsaneconfig4 -a name=MFC-J470DW model=MFC-J470DW ip=192.168.x.x
brscan4 complains for missing libavahi-client.so.3 and don't let my add my scanner i installed avahi to solve the problem now i have removed avahi and i can anyway add new scanner, but the brsaneconfig4 -q problem persist brsaneconfig4 -q /opt/brother/scanner/brscan4/brscan_cnetconfig: error while loading shared libraries: libavahi-client.so.3: cannot open shared object file: No such file or directory installing again avahi fix it. sudo brsaneconfig4 -q * MFC-J470DW [ 192.168.x.x] MFC-J470DW
Harvey commented on 2021-06-22 09:51 (UTC)
@maxfranco: Please provide more information. Network or USB scanner, scanner model, which frontend do you use, are there any error messages, which steps did you take to use your scanner. Without this I can only tell that for me it works without avahi...
purpleleaf commented on 2021-06-22 09:10 (UTC)
There is a missing dependency, without avahi (libavahi-client.so.3) it's impossible add or query scanners.
ettavolt commented on 2021-04-21 12:28 (UTC)
Systemd developers seem to be unsure about this case subject too: https://github.com/systemd/systemd/issues/5642 ☺
Sondeluz commented on 2021-04-21 11:58 (UTC)
@ettavolt
Thanks, the workaround did the trick, though now it's fixed :)
@Harvey
I removed the udev rule, updated the package and rebooted for good measure, now I can confirm it's working perfectly, so the suspicions may have been correct.
Thank you both!
ettavolt commented on 2021-04-21 11:40 (UTC)
@Sondeluz, sorry, I've copy-n-pasted != for the idProduct check in the proposed rule. It should have been
ACTION=="add" ATTR{idVendor}=="04f9" ATTR{idProduct}=="041f" ENV{libsane_matched}="yes"
Harvey commented on 2021-04-21 11:23 (UTC)
@Sondeluz: Please try again with -5 (Converted to uppercase as used in 20-sane.hwdb)
Sondeluz commented on 2021-04-21 09:29 (UTC)
Hello!
The command returns libsane_matched=yes
Yes, I am the only user on a Plasma/X session with systemd indeed.
I had no luck with the udev rule, the (same) error keeps appearing.
ettavolt commented on 2021-04-20 15:15 (UTC)
Oh, this is much better!
Thank you for testing the change, I'm sorry that it disrupted your system even though that everything is seem to be correct.
What does the following command return in your environment?
systemd-hwdb query usb:v04f9p041f
Just to reconfirm: when you try to scan, you're the only user in the system and have a graphical session, driven by systemd, correct?
For an immediate remedy I suggest creating /etc/udev/rules.d/20-dcp-l2510d.rules with the following contents:
ACTION=="add" ATTR{idVendor}=="04f9" ATTR{idProduct}!="041f" ENV{libsane_matched}="yes"
I'm planning to have a testing session myself in a couple of days, maybe I find the package bug actually. My suspicion is that we need uppercase HEX in the hwdb in contrary to rules…
Sondeluz commented on 2021-04-20 13:19 (UTC) (edited on 2021-04-20 13:19 (UTC) by Sondeluz)
Sorry! I wasn't specific enough. This comes directly from the desktop scanner application, the printer itself was and is working nicely using brscan4 on Fedora, for example. It's a DCP-L2510D connected via USB, nothing fancy.
Both skanlite, simple-scan and xsane report I/O errors since the update. Here's what simple-scan complains about for example when running it with --debug:
[+3,50s] DEBUG: scanner.vala:341: sane_get_devices () -> SANE_STATUS_GOOD
[+3,50s] DEBUG: scanner.vala:353: Device: name="brother4:bus2;dev3" vendor="Brother" model="DCP-L2510D" type="USB scanner"
[+3,61s] DEBUG: app-window.vala:2080: Saving state to /home/sam/.cache/simple-scan/state
[+10,53s] DEBUG: app-window.vala:2080: Saving state to /home/sam/.cache/simple-scan/state
[+10,64s] DEBUG: simple-scan.vala:1819: Requesting scan at 300 dpi from device 'brother4:bus2;dev3'
[+10,64s] DEBUG: scanner.vala:1704: Scanner.scan ("brother4:bus2;dev3", dpi=300, scan_mode=ScanMode.COLOR, depth=8, type=single, paper_width=0, paper_height=0, brightness=0, contrast=0, delay=0ms)
[+10,64s] DEBUG: scanner.vala:837: Processing request
[+10,64s] DEBUG: scanner.vala:898: sane_open ("brother4:bus2;dev3") -> SANE_STATUS_IO_ERROR
[+10,64s] WARNING: scanner.vala:902: Unable to open device: Error during device I/O
ettavolt commented on 2021-04-19 20:23 (UTC)
Sorry, we can't help you with the information you've provided. Our printers don't show anything like this on their dot-led displays. ☺
Maybe that is an error in the output of some application or service? Which one? How is it launched?
Sondeluz commented on 2021-04-19 20:17 (UTC) (edited on 2021-04-19 20:17 (UTC) by Sondeluz)
I honestly fail to understand these changes, but if it is of any help, my printer now throws "Failed to open device 'brother:bus4;dev1': Error during device I/O." since the last update.
egrupled commented on 2021-04-17 14:11 (UTC)
@applebloom recent version doesn't install anything
/etc/udev
, please update.applebloom commented on 2021-04-17 14:06 (UTC)
Hi. I noticed that udev rules are installed in
/etc
(/etc/udev/rules.d/40-brscan4.rules
). Shouldn't they go into/usr/lib/udev
? Etc should be only for local configuration only, I think.ettavolt commented on 2021-04-17 06:46 (UTC) (edited on 2021-04-17 07:00 (UTC) by ettavolt)
@markuschaaf, the setup with rules adding 'scanner' group is package-specific. Sane's way is to add libsane_matched=yes to scanner devices and let some 'base' rule to react to this env. Particularly, /usr/lib/udev/rules.d/66-saned.rules runs /usr/bin/setfacl -m g:saned:rw $env{DEVNAME} for these.
You should probably tweak your service launchers to start under 'saned' group instead of 'scanner'.
Alternatively, add a copy of that rule in, say, /etc/udev/rules.d/66-scanner.rules with 'saned' group replaced by 'scanner'.
Note: both tweaks will leave all scanners (not just those supported by brscan4) equally accessible.
egrupled commented on 2021-04-16 18:19 (UTC) (edited on 2021-04-16 19:21 (UTC) by egrupled)
Group based permission management is deprecated in Arch and repo packages are moving away from it. It's hard to blame AUR package for doing exactly the same what repo package did. It's more a standard than a fashion. One of the points of systemd dynamic permission model is to differentiate between local and remote user permissions. Users are free to modify this behavior as they wish.
markuschaaf commented on 2021-04-16 15:41 (UTC)
What's the purpose of using hwdb, besides "because you can"? Supporting the scanner group has a real world use case: I can use the scanner from other services beside saned and over ssh, which is what I do. Now the package is broken for me and I have to roll my own. The udev-rules I had sent @Harvey worked for everyone. I don't know what's the reason for those commenters here pushing their unjustified but fashionable ideas.
ettavolt commented on 2021-04-14 12:27 (UTC) (edited on 2021-04-14 12:28 (UTC) by ettavolt)
Sorry, still didn't manage to bring my Arch installation to the device.
I can say that systemd-udevd accepts the new file at least.
Harvey commented on 2021-04-14 10:42 (UTC)
Ok, although I am not fully convinced yet I made up my mind to sync with sane's behavior. Pushed a new package Version with udev-hwdb support. Lets see what happens (Fingers crossed).
egrupled commented on 2021-04-13 20:12 (UTC)
I think when provided udev+hwdb approach will work here then other packages will follow (if they are still maintained). Someone must go first.
Harvey commented on 2021-04-13 19:07 (UTC)
@ettavolt: Did you test it? I only have networked devices here so this is rather like flying blind for me :( I had a look at your PKGBUILD. Does this work for you? Meanwhile I looked at the other brscan incarnations (2/3/5) in AUR, none of them is using udev+hwdb... I feel if we decide to go this way, at least all should do the same. And the Arch wiki should be corrected as well: https://wiki.archlinux.org/index.php/CUPS/Troubleshooting#Conflict_with_SANE
Harvey commented on 2021-04-13 19:04 (UTC)
@ettavolt: Did you test it? I only have networked devices here so this is rather like flying blind for me :( I had a look at your PKGBUILD. Does this work for you? Meanwhile I looked at the other brsan incarnations (2/3/5) in AUR, none of them is using udev+hwdb...
ettavolt commented on 2021-04-12 18:13 (UTC) (edited on 2021-04-12 18:16 (UTC) by ettavolt)
Yes, like this: https://github.com/ettavolt/aur-brscan4/commit/3680c46f83ec7909e433cebfae4d0c92cdb98238
Let me test it though. ☺
egrupled commented on 2021-04-12 17:20 (UTC) (edited on 2021-04-12 17:26 (UTC) by egrupled)
My understanding is if you add right device id to hwdb then systemd will take care of permissions (it will grant permission for currently logged user regardless of any groups set).
I think the request from https://aur.archlinux.org/packages/brscan4/#comment-793321 was about generating .hwdb file with device ids and install it to /usr/lib/udev/hwdb.d/ instead of creating custom udev rules which grant permissions for generated device id.
Harvey commented on 2021-04-12 16:13 (UTC) (edited on 2021-04-12 16:28 (UTC) by Harvey)
To be honest this seems far more complicated to me than it should be and, to be even more honest, I don't understand it. brscan4 is for Multi-function devices, Scan-only devices and god knows for what else, all of them being either networked or attached via local ports. How can a scanner driver decide what group to use or not? Is saned the only daemon/piece of software using scanner devices? If would be easy to generate rules for saned group instead of scanner then... Me scratching head... BTW, mine looks not so different from https://github.com/archlinux/svntogit-packages/blob/packages/sane/trunk/66-saned.rules
egrupled commented on 2021-04-12 15:24 (UTC)
@Harvey sane maintainer in Arch said scanner group (or any other group) isn't used anymore with udev+hwdb setup so why did you switch over it right now?
https://bugs.archlinux.org/task/57391#comment197064
Harvey commented on 2021-04-12 13:41 (UTC)
2nd try, forgot to push mk-udev-rules
yywrobbie commented on 2021-04-12 13:33 (UTC)
mk-udev-rules did not pass the validity check (md5sum). Package version brscan4 0.4.10_1-2
Harvey commented on 2021-04-12 13:31 (UTC)
Published a new version only based on acl udev rules. Please try!
Harvey commented on 2021-03-08 06:42 (UTC)
@ettavolt: Will have a look as soon as I find the time. The gawk script was provided by another user, so :p For now: Don't change a running system...
ettavolt commented on 2021-02-24 10:09 (UTC)
Harvey, now that Arch has switched [1] to hwdb + acl, would you mind doing the same here next time you get your hands on this?
That means changing mk-udev-rules to build something like /usr/lib/udev/hwdb.d/20-sane.hwdb supplied by the sane package now. (Sorry, I'm total noob in awk) Arch's custom 66-saned.conf will take care of other things (like some sane's rules did before).
I see no specific lines in the source [2] of Arch's sane package to do hwdb rebuild/reload. systemd likely does that automagically.
Benefits of hwdb are the ability to supply the data to something else but udev and it's indexed nature [3].
For Manjaro nothing should change (they should already have systemd with hwdb).
I think I saw someone from OpenSUSE coming here. They seem to have two separately maintained packages in the OBS, for which I didn't find any traces connecting them to AUR's brscan4.
Thank you for maintaining this package!
[1] https://bugs.archlinux.org/task/57391 [2] https://github.com/archlinux/svntogit-packages/blob/packages/sane/trunk/ [3] https://github.com/systemd/systemd/blob/main/NEWS, see "CHANGES WITH 196"
Harvey commented on 2021-02-15 20:01 (UTC)
@jowlo: updated, thanks for the hint
jowlo commented on 2021-02-15 16:56 (UTC)
There is a new version 0.4.10 available at the Brother website since 25/01/2021 at https://download.brother.com/welcome/dlf105200/brscan4-0.4.10-1.amd64.deb
Would you mind updating the package? Thank you!
Harvey commented on 2021-01-31 13:44 (UTC)
@trapezestunned: This does not look like a standard brscan4 device. Quick google search found this: https://bbs.archlinux.org/viewtopic.php?id=250065 Please take some time to investigate yourself ;)
trapezestunned commented on 2021-01-30 21:14 (UTC)
Trying to get scanning with a Brother DS-620 working. I've installed this package (the Brother website said to use brscan4), but it isn't working. I can see the device when I use lsusb, but scanimage and sane-find-scanner don't see anything whether run as root or not. I've tried adding my user to lp, rebooting, replugging, no change. Any idea what I could've done wrong?
Harvey commented on 2020-08-06 11:54 (UTC)
@yywrobbie: If it is in the driver, I can't be of any further help. Please contact upstream support. Did you try both ADF and Flatbed? Any settings of the hardware that you could change?
yywrobbie commented on 2020-08-06 04:55 (UTC)
@Harey Having the same problem on opensuse with the upstream rpm driver. Tried xsane and it didn't work as well.
Harvey commented on 2020-07-13 13:15 (UTC)
@surm: I suggest reading the comments before complaining, on the second page you will find your answer.
surm commented on 2020-07-13 11:35 (UTC)
I have a trouble updating brscan4 to version 0.4.9_1-1:
Harvey commented on 2020-06-28 15:29 (UTC)
@yywrobbie: I suggest to validate if the driver is working correctly on other linux distributions. Have you tried sane-frontends, i.e. xsane?
yywrobbie commented on 2020-06-24 22:30 (UTC)
Unable to scan US letter-sized documents on my MFC-L2700DW. On skanlite it shows that the maximum width of scannable area is 8.3 inches which is smaller than the width of a US letter (8.5 inches). Same thing with gscan2pdf where the maximum width is 211.90mm (~8.3 in) which suggests an issue with the scanner driver or the configuration of it.
Harvey commented on 2020-06-18 09:55 (UTC) (edited on 2020-06-28 15:25 (UTC) by Harvey)
updated. Thanks @lgm @ua4000: The 'Required by xxx (optional)' tag has to be provided by the other package, in this case brother-dcpj4110dw
ua4000 commented on 2020-05-23 11:07 (UTC)
Thanks ! Got my Brother DCP-J4110DW working.
You could add: Required by brother-dcpj4110dw (optional)
Have a good day!
gsgleason commented on 2020-04-30 18:56 (UTC) (edited on 2020-04-30 18:57 (UTC) by gsgleason)
I installed this package and ran the following command:
At this point scanimage --list-devices showed the device, and scanimage successfully scanned the paper I had in there. It was super easy.
Thanks!
Harvey commented on 2020-04-09 06:28 (UTC)
Again (like stated before on 2020-03-18)... The brsan4.install file should get this right without user interaction. Calling /opt/brother/scanner/brscan4/setupSaneScan4 -i does exactly that - adding 'brother4' to /etc/sane.d/dll.conf... Don't know why this does not work for you... Did you by chance configure addditional restrictions for pacman? If noone answers the question I won't be able to find a cause for the missing entry in /etc/sane.d/dll.conf. And it won't help to just add it like you suggested. Think about uninstallation and update...
James_Eder commented on 2020-04-09 02:08 (UTC)
There's a drop in folder that can be used to make this package work out of the box.
Any reason why not to include it in the package?
julienfalque commented on 2020-03-27 12:59 (UTC) (edited on 2020-03-27 17:04 (UTC) by julienfalque)
Makes sense. I didn't understand this error was from Git, fixed now :)
ettavolt commented on 2020-03-27 12:28 (UTC)
Looks like yay downloads sources to the folder with PKGBUILD. That's why when agree.html became a versioned file, Git refused to check it out over already present unversioned copy. Victoria, Julien, can we see a listing of your directories with brscan4 PKGBUILD? I bet we'll see rpms there too.
Harvey commented on 2020-03-27 12:22 (UTC)
So why don't you just overwrite the file agree.html? BTW, yay is not an official tool. I tested with makepkg which is the arch way and this worked for me.
julienfalque commented on 2020-03-27 07:54 (UTC)
I have the same issue when updating the package:
Harvey commented on 2020-03-24 11:53 (UTC)
@vstuart: I don't get the sense of your message, sorry ;) I tested pure 'makepkg -cfsi' and it works without quirks. Could you please tell us a little more?
vstuart commented on 2020-03-23 18:22 (UTC) (edited on 2020-03-23 18:56 (UTC) by vstuart)
Start update (e.g.,
yay -Syu
), and at appropriate prompt (brscan4
update) choose to view the differences (diff
), to get your path toagree.html
:Then, in a terminal:
Update /install should now proceed. :-)
ellolo commented on 2020-03-23 15:05 (UTC)
It works ! Many Thanks
Harvey commented on 2020-03-23 13:56 (UTC)
Brother seems to have deleted the license file from their website. For the time being I have pushed a new version of the package that contains the license file.
ellolo commented on 2020-03-23 12:19 (UTC) (edited on 2020-03-23 12:20 (UTC) by ellolo)
Hello Harey and all
Brscan4 (0.4.8_1-1) build fails as http://www.brother.com/agreement/English_sane/agree.html can't be downloaded (error 404). Is there a way to bypass this?
Thanks in advance
Harvey commented on 2020-03-18 16:42 (UTC) (edited on 2020-03-18 16:44 (UTC) by Harvey)
The brsan4.install file should get this right without user interaction. Calling /opt/brother/scanner/brscan4/setupSaneScan4 -i does exactly what you did manually - adding 'brother4' to /etc/sane.d/dll.conf... Don't know why this does not work for you... Did you by chance configure addditional restrictions for pacman? Puzzled...
Mr.Magne commented on 2020-03-18 15:20 (UTC) (edited on 2020-03-18 15:20 (UTC) by Mr.Magne)
I used brsaneconfig4 but I had to do this also:
$ echo brother4 | sudo tee /etc/sane.d/dll.d/brother4
thanks @Junker
Harvey commented on 2020-03-02 10:57 (UTC)
@Junker: Did you use brsaneconfig4 after the installation?
Junker commented on 2020-02-28 16:16 (UTC) (edited on 2020-02-28 16:17 (UTC) by Junker)
my scanner DCP-1510 didn't work until i didn't do this:
$ echo brother4 | sudo tee /etc/sane.d/dll.d/brother4
so, maybe should add this file to the package
rhabbachi commented on 2019-07-02 19:14 (UTC)
Hopefully your surgery went well @Harey!
Harvey commented on 2019-07-02 16:16 (UTC)
Updated to 0.4.8-1
Harvey commented on 2019-03-28 10:20 (UTC) (edited on 2019-03-28 10:20 (UTC) by Harvey)
Just a short note: I am in the process of getting hip surgery atm and can't do much. Online time is short and precious ;) If someone else wants to adopt the package I'll orphan it for now. But I will be back in about 3-4 weeks.
dreieck commented on 2019-03-20 17:38 (UTC)
I suggest adding to the
package()
-function a creation of a symlink of the/etc/opt/[...]
-stuff directly into/etc/
, so it is easier to find. E.g.:/etc/opt/[...]
is quite a strange directory. I had a very hard time looking where I defined my network scanner, because, when it/ the network is not available, sane was rejecting any other work, too.fbrennan commented on 2019-03-11 10:08 (UTC)
Note to self and future Googlers:
brscan4
's notion of your scanner's IP address has nothing to do with CUPS' notion thereof. If you change your printer's IP, it won't affect the scanning, and you'll get the dreadedInvalid argument
error.You can fix this by correcting your scanner's IP in
/opt/brother/scanner/brscan4/brsanenetdevice4.cfg
lemongrab commented on 2018-12-13 00:44 (UTC) (edited on 2018-12-13 01:00 (UTC) by lemongrab)
Hi ettavolt. I'm not sure if that was directed towards me but "/opt/brother" does not exist. I had installed brscan4 using yay and I'm not sure if another tool is advised instead.
EDIT: I had this error: brscan4: /usr/lib/sane/libsane-brother4.so exists in filesystem brscan4: /usr/lib/sane/libsane-brother4.so.1 exists in filesystem brscan4: /usr/lib/sane/libsane-brother4.so.1.0.7 exists in filesystem Errors occurred, no packages were upgraded.
so I deleted these three files and were able to install brsane4 just fine and run brsaneconfig4. Thanks!
ettavolt commented on 2018-12-11 16:53 (UTC) (edited on 2018-12-11 16:58 (UTC) by ettavolt)
lemongrab commented on 2018-12-11 16:40 (UTC)
I noticed that after installing this package that I don't get a binary starting with "brs", namely brsaneconfig4. I was wondering what package I'll need to install for that.
Harvey commented on 2018-10-31 11:18 (UTC)
updated to 0.4.6_1
Harvey commented on 2018-07-29 09:07 (UTC)
@marcin: changed that back, thanks. Learned: never rely on anything :(
marcin commented on 2018-07-29 03:16 (UTC) (edited on 2018-07-29 03:18 (UTC) by marcin)
Was getting this error:
curl: (51) SSL: no alternative certificate subject name matches target host name 'www.brother.com' ==> ERROR: Failure while downloading https://www.brother.com/agreement/English_sane/agree.html
I downloaded the brscan4:
git clone https://aur.archlinux.org/brscan4.git
and then manually edited PKGBUILD to have
http
instead ofhttps
for two brother links there.And then manually build and install the packakage
makepkg -si
Harvey commented on 2018-07-27 12:35 (UTC)
@lordbalmung: Done. Thank you for the hint. Did not change the pkgver though because it does not change the package itself.
lordbalmung commented on 2018-07-25 23:38 (UTC)
Can you please modify the source to https instead of http? brother seems to release the rpm in https as well.
egrupled commented on 2018-07-13 15:47 (UTC) (edited on 2018-07-13 16:01 (UTC) by egrupled)
@Harey: it still blocks executing binary files. To be clear:
noexec
flag isn't defense against maliciousPKGBUILD
. It's a coincidence that it can break building in circumstances as described below. What I'm advocating here is to prevent that accidental breakage.Harvey commented on 2018-07-13 14:20 (UTC)
Just out of curiosity: what is the sense in this if a malicious PKGBUILD can circumvent it with a - agreed - trivial change?
egrupled commented on 2018-07-13 11:59 (UTC)
@ettavolt: You're partially right :)
If the files were simply copied to chroot dir it will work as files can have executable bit (
x
) onnoexec
filesystem - it's just not effective.The problem is that in Archlinux chroot they're
bind
mounted, see https://git.archlinux.org/devtools.git/tree/makechrootpkg.in#n419 . That means original mount point flags likenoexec
are inherited and the build will fail.So in this example mounting
/home
(or/var
or whatever) withnoexec
will even break building in clean chroot (assuming/home
is where you downloaded PKGBUILD). That's why using./some-script
is harmful in PKGBUILD.ettavolt commented on 2018-07-13 05:43 (UTC)
Even if the files are copied from
noexec
FS into clean chroot for that kind of build, they'll miss the flag, won't they?egrupled commented on 2018-07-12 14:55 (UTC) (edited on 2018-07-12 15:08 (UTC) by egrupled)
@ettavolt: It's not about
BUILDDIR
(which is set to/tmp
as default) directory where packages are being built. It's aboutSRCDEST
(which defaults to dir wherePKGBUILD
is stored).If you download
brscan4
snapshot to/home
mounted withnoexec
it will still break building in/tmp
mounted with default flags. That's because files (likemk-udev-rules
) from/home
will be symlinked to/tmp
. That's the essence of this issue.Luckily this problem goes away with a trivial change :)
ettavolt commented on 2018-07-12 14:43 (UTC) (edited on 2018-07-12 14:43 (UTC) by ettavolt)
To quote the wiki:
Particularly,
noexec
on/tmp
is saidAlso, many other packages execute some script as a part of build process.
sane
itself uses a built undistributed binary to write udev rules.egrupled commented on 2018-07-12 14:16 (UTC)
@Harey
Well, I did my best to explain the benefit. Mounting partitions with
noexec
flag is what Arch wiki recommends for security: https://wiki.archlinux.org/index.php/Security#Mount_options . I don't understand why not use my approach which will work always instead of something which can break in a known scenario. I'm modifying this locally for years but I thought it would be beneficial to upstream it to prevent everyone from hitting this issue.Harvey commented on 2018-07-11 11:41 (UTC)
@egrupled: I don't see the benefit for this but you are always free to edit the PKGBUILD to suit your needs before building. Anybody else having the same problem?
egrupled commented on 2018-07-10 16:15 (UTC) (edited on 2018-07-10 16:27 (UTC) by egrupled)
@Harey
Yes, it breaks when you try building the package and the directory where you downloaded sources is mounted with
noexec
flag.In such case executing scripts directly like
./some-script
will fail withpermission denied
.But executing scripts by passing them to interpreter like
bash some-script
,python some-script
orgawk -f some-script
will still work.The script functionality is unchanged so there is no downside of doing this change.
Harvey commented on 2018-07-08 12:41 (UTC)
@egrupled: Could you describe the scenario a bit more and why somebody wants to use it? It breaks only while building the package, right?
egrupled commented on 2018-07-04 15:41 (UTC)
Hi, thx for providing this package!
Could you change in https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=brscan4#n26
to:
Otherwise it breaks when "mk-udev-rules" is cached on mount point with "noexec" flag.
Harvey commented on 2018-07-03 06:25 (UTC)
updated to 0.4.5_1 @ron2138 I changed the upstream URL to something more unspecified because the one you provided did not have the latest updates. Thanks for reporting upstreams - please keep us informed if you get an answer.
ron2138 commented on 2018-06-13 21:31 (UTC) (edited on 2018-06-19 15:56 (UTC) by ron2138)
The upstream URL recorded above can not be found
Replying ettavolt comment on 2018-06-13 05:13 and Harey comment on 2018-06-12 09:20: On 2018-06-19 I sent a message through Email Support. Got #180619-000271 reference number for follow up. A reply by email was they will provide this to the software engineers.
ettavolt commented on 2018-06-13 05:13 (UTC) (edited on 2018-06-13 05:14 (UTC) by ettavolt)
Man (https://www.freedesktop.org/software/systemd/man/udev.html) says that /etc/udev/rules.d/ is for local administrator. Local = per-machine. Package isn't machine-dependent (though it may be useful only for some that have Brother's scanner connected). Having rules in /usr/lib would allow a simple disabling via linking /etc/udev/rules.d/40-brscan4.rules to /dev/null. And this way won't interfere with package updates (while deleting file does).
Harvey commented on 2018-06-12 09:20 (UTC)
The output of 'pacman -Qo /usr/lib/udev/rules.d/' makes me feel it is better to leave this directory alone ;). As far as you don't have a pressing argument I will stay with /etc/udev/rules.d/. One could interpret 'vendor' as 'Archlinux' as well...
ron2138 commented on 2018-06-11 22:54 (UTC)
Currently, /etc/udev/rules.d/40-brscan4.rules are installed by brscan4. I think it would be better if that file will be installed under /usr/lib/udev/rules.d/. The reason is that, as far as I can tell, /usr/lib/udev/rules.d/ are for vendor files, while /etc/udev/rules.d are for local files.
Harvey commented on 2018-01-12 17:14 (UTC)
So you should file a bug for sane in Archlinux's bugtracker and see what the devs think about the situation...
ettavolt commented on 2018-01-12 12:21 (UTC) (edited on 2018-01-12 12:25 (UTC) by ettavolt)
Works, thank you. But for a bit different reason. ☺
So, what's happening with my DCP-1510 (as I understand it now):
40-brscan: MODE 664, GROUP lp, libsane_matched=yes
49-sane: MODE 664, GROUP scanner
50-udev-defaults: GROUP="lp" (because ENV{ID_USB_INTERFACES}==":0701??:")
70-uaccess: TAG+uaccess (because libsane_matched=yes)
Systemd somehow adds current-user ACL for uaccess-TAGged devices (this package owns udev-defaults and uaccess). Since brscan4 has priority of 40 (higher than 70 of uaccess) scanner works for current user without modification of his group. I think Arch's sane has to generate ACL-based udev rules (instead of what's generated now).
Here you can remove MODE and GROUP actions. The combination of sane.rules and udev-default.rules will do exactly the same (checked for DCP-1510).
Harvey commented on 2018-01-12 11:24 (UTC)
ettavolt: OK, this seems quite logical to me. I pushed a new version of the package with the change you proposed. Let's see what happens ;)
ettavolt commented on 2018-01-11 10:44 (UTC) (edited on 2018-01-11 10:49 (UTC) by ettavolt)
Sorry, forgot to enable notifications. Basically udev is applying files from /etc and /usr in lexical order (without directory paths). Sane's rules are chowning scanner ports to 'scanner' group if ENV{libsane_matched}=="yes" (see the bottom of /usr/lib/udev/rules.d/49-sane.rules). "brscan4" is lexically after "49-sane". That's why ENV{libsane_matched}="yes" in "brscan4" will be applied after sane's rules and thus a Brother's scanner port won't be chowned to 'scanner'.
BTW, I wonder why is there MODE=xxx GROUP=xxx in the sane's rules file? This changes are reapplied by ENV{libsane_matched}=="yes" condition…
Harvey commented on 2017-11-08 07:33 (UTC)
ettavolt commented on 2017-11-08 06:46 (UTC)
Harvey commented on 2017-11-06 14:52 (UTC)
timofonic commented on 2017-08-16 16:28 (UTC) (edited on 2017-08-16 16:38 (UTC) by timofonic)
vfrico commented on 2017-05-23 19:57 (UTC)
Harvey commented on 2017-05-17 13:20 (UTC)
lordbalmung commented on 2017-05-17 09:41 (UTC)
Harvey commented on 2017-03-29 10:02 (UTC)
commented on 2017-01-07 15:47 (UTC)
Harvey commented on 2016-10-26 09:38 (UTC)
dhtseany commented on 2016-10-25 19:15 (UTC)
Harvey commented on 2016-10-24 09:29 (UTC)
pitlochry commented on 2016-10-23 11:32 (UTC)
Harvey commented on 2016-10-11 06:38 (UTC)
bhartshorn commented on 2016-10-11 01:58 (UTC) (edited on 2016-10-11 02:04 (UTC) by bhartshorn)
Harvey commented on 2016-09-13 08:33 (UTC)
herzmeister commented on 2016-07-21 09:56 (UTC)
timofonic commented on 2016-04-28 14:21 (UTC) (edited on 2016-04-28 14:40 (UTC) by timofonic)
sowieso commented on 2016-02-26 10:22 (UTC)
Harvey commented on 2016-02-26 07:56 (UTC)
aborigines commented on 2016-02-25 19:44 (UTC)
sowieso commented on 2016-02-10 12:16 (UTC)
Harvey commented on 2016-02-10 10:11 (UTC)
sowieso commented on 2016-02-08 13:11 (UTC)
pfrenssen commented on 2016-01-25 20:23 (UTC)
thb commented on 2016-01-23 12:28 (UTC) (edited on 2016-01-23 12:28 (UTC) by thb)
garcs commented on 2016-01-03 20:35 (UTC)
tuxayo commented on 2015-12-21 11:14 (UTC)
Harvey commented on 2015-12-21 08:49 (UTC)
DrMartinus commented on 2015-12-03 16:12 (UTC)
Matty_r commented on 2015-11-18 23:31 (UTC)
tangodaddy commented on 2015-10-08 08:54 (UTC)
valr commented on 2015-09-29 18:40 (UTC)
STEELBAS commented on 2015-09-23 23:44 (UTC)
Harvey commented on 2015-09-01 09:12 (UTC)
ava1ar commented on 2015-08-29 19:01 (UTC)
commented on 2015-05-05 20:50 (UTC)
Harvey commented on 2015-05-05 06:35 (UTC)
Harvey commented on 2015-05-05 06:34 (UTC)
commented on 2015-05-05 00:05 (UTC)
Harvey commented on 2015-05-02 12:13 (UTC)
supernaicol commented on 2015-04-29 10:25 (UTC)
Harvey commented on 2015-04-28 16:07 (UTC)
supernaicol commented on 2015-04-28 11:16 (UTC)
Harvey commented on 2015-04-28 09:14 (UTC)
mksingh commented on 2015-04-21 12:35 (UTC)
Harvey commented on 2015-01-24 16:14 (UTC)
supernaicol commented on 2015-01-24 13:40 (UTC)
Harvey commented on 2015-01-22 12:55 (UTC)
supernaicol commented on 2015-01-21 23:27 (UTC)
Harvey commented on 2014-12-18 14:17 (UTC)
CjK commented on 2014-12-18 11:43 (UTC)
Harvey commented on 2014-12-17 11:09 (UTC)
Harvey commented on 2014-11-26 10:42 (UTC)
valandil commented on 2014-11-23 23:38 (UTC)
ozlacs commented on 2014-11-12 12:05 (UTC)
Harvey commented on 2014-10-27 13:29 (UTC)
amiad commented on 2014-10-27 11:47 (UTC)
Harvey commented on 2014-10-13 08:47 (UTC)
sjakub commented on 2014-10-13 07:59 (UTC)
Ravenman commented on 2014-08-18 23:57 (UTC)
Harvey commented on 2014-08-18 14:52 (UTC)
Ravenman commented on 2014-08-17 18:03 (UTC)
sb56637 commented on 2014-07-10 15:24 (UTC)
Harvey commented on 2014-07-10 07:42 (UTC)
Harvey commented on 2014-07-09 17:20 (UTC)
sb56637 commented on 2014-07-08 15:33 (UTC)
Harvey commented on 2014-07-03 15:32 (UTC)
sb56637 commented on 2014-07-03 15:05 (UTC)
Harvey commented on 2014-03-15 12:46 (UTC)
Harvey commented on 2014-01-22 17:43 (UTC)
integer0 commented on 2014-01-22 16:28 (UTC)
Harvey commented on 2013-07-31 09:24 (UTC)
Harvey commented on 2013-07-30 09:22 (UTC)
mutterschiff commented on 2013-07-30 08:36 (UTC)
battlepanic commented on 2013-07-14 21:13 (UTC)
Harvey commented on 2012-12-12 21:18 (UTC)
Harvey commented on 2012-08-02 09:21 (UTC)
chepaz commented on 2012-08-01 18:41 (UTC)
Harvey commented on 2012-08-01 08:58 (UTC)
chepaz commented on 2012-07-31 20:29 (UTC)
Harvey commented on 2012-06-26 18:39 (UTC)
dk0r commented on 2012-06-25 16:16 (UTC)
Harvey commented on 2012-04-28 10:11 (UTC)
flexiondotorg commented on 2012-04-26 11:01 (UTC)
Harvey commented on 2012-03-25 17:17 (UTC)