I initially tried using wireless with my Brother, and it worked, but I had problems with getting the connection re-established after the router had been power cycled. I suspect that this is my hardware. I have found that if my router (set to use WPA2 only) receives an initial attempted connection using WPA, it then refuses to accept a subsequent WPA2 connection. YMMV.

People who persecute forests need to be taught/forced to use virtual pdf printers.

If you are using USB, you do not want the network scanning entry

On scanning, a few things to check.
Is your user a member of the lp group? (Your user also used to need to be a member of the scanner group, but I believe that is obseleted.) Perhaps try as root, in case there is a permissions isssue.
Does 'scanimage -L" show the scanner?
Is there an entry at the end of /etc/sane.d/dll.conf for your device? (e.g. brother2, brother3, brother4)

How did you actually install the drivers?

Just had another thought. With my device the scanning software (xsane, skanlite) defaulted to using '24bit Color[Fast]' as the scan mode. This did not work for me. Use '24bit Color' instead.

Yes, I'm a member of lp and scanner.

#scanimage -L shows:

No scanners were identified. If you were expecting something different,
check that the scanner is plugged in, turned on and detected by the
sane-find-scanner tool (if appropriate).

Nothing in /etc/sane.d/dll.conf for brother anything.

I downloaded the brscan-skey-0.2.4 and brscan4-o.4.1 rpm's, did src2pkg on each one then did installpkg on each one.

Okay, your last question made me go back and look at what I'd done. Apparently changing them to slackware packages screws something up, so, I installed them like plain ol' rpm's with #rpm -ivh --nodeps blah.rpm and now I have a scanner, although xsane froze up on me when I clicked 'preview'. Skanlite seemd to work okay though, so I'll mess with it some more and see what's going on.

Thanks a million allend and everyone else!

Allright, I don't know why xsane froze a little bit ago, but it worked this time. Looks like I've got a nice printer/scanner going for me now. Y'all are the best and I sure do appreciate the time you spent helping me. Thanks again.

I had hoped you would have used the technique from the SlackDocs page. I have been wanting a guinea pig for that!

Just goes to show there is more than one way to skin a cat. Glad you got it working!

You could do it in one step with either:

or:

(Note: All three of the above have the issue that data.tar could and often is, compressed with different methods however!)

It is no harder with rpms, just use bsdtar (provided by libarchive, which many apps depend on) to convert the internal cpio into a gzip compressed tar:

Whilst these types of tricks are kinda neat and fun they are not particularly good because the internal formatting of the tar package with regards to directory naming will be wrong, i.e. './' is found in front of all subdirectories. Slackware uses GNU Tar 1.13 in its package tools, hence the difference in formating. A further issue is that tar 'packages' made with methods other than makepkg may contain symlinks, which is not allowed within Slackware packages.

So really you shouldn't do these kinds of tricks at all but rather open the packages and then recreate the out tar contained again with makepkg. By the time you have gone to this level of effort you might as well write a simple SlackBuild or just use a dedicated tool like src2pkg.

I have done this occasionally but it is pretty ugly and generally not recommended. At the very least the user should inspect the rpm post install/uninstall scripts first to make sure they don't do anything nasty!

You can do this as follows:
Actually I would also look at files that would be installed as well to make sure the rpm doesn't overwrite anything it shouldn't!
Of course, by the time you have done a proper inspection and satisfied yourself that this won't blow up in your face you could have created a real Slackware package, so I'll again stress that this is generally a bad idea in any case.

Which is why I suggest using 'rpm2txz', an existing tool in Slackware.

I also agree that installing rpm's directly is not good practice. Far better to convert to a native Slackware package and install that. Then it is easy to uninstall if required.

A point made in the 'rpm2txz' script and emphasised on the SlackDocs page.

Sure, I just picked src2pkg because it is a bit for powerful, e.g. also handling debs and because it has so many fans here at LQ but I'm not disagreeing with you and rpm2txz is certainly far better than installing a random tar that was not designed for Slackware.

Indeed, for my own part I generally don't bother with rpm2txz or src2pkg but rather knock up a quick dedicated SlackBuild for that application I want to convert. This ensures the internal layout is exactly as it should be (e.g. usr/{man,doc} rather than /usr/share/{doc,man}) and the slack-desc is informative and useful to me later. SlackBuilds for deb/rpm package conversion are generally pretty easy to knock out quickly. On the other hand I certainly understand the convenience of tools like rpm2txz and src2pkg for quick conversion and get why they are so popular.

Uh, src2pkg does a lot of checks and corrections on the content before creating the archive. None of the other tools mentioned here do that. I'm just now working on a new tool which duplicates the content-checking steps of src2pkg -but without actually making any corrections.

I tried src2pkg with the rpm's and installed those packages and they didn't work.

@allend - I *thought* I'd done that on the slackdocs site, but could have missed it trying all the other suggestions. I'd *much* rather have prefered that a slackware package been installed than have done the rpm thing. Maybe there's a way to 'uninstall' that rpm and try the pkg2txz thing?

<later>...I just tried rpm -e brscan4xxx.rpm and I got back that it's not installed. Didn't think to try a scan right then and instead did the rpm2txz on the rpm and installed that and my scanner is still(?) working, but I can't say if it's from the installed rpm or from the installed txz.

@w1k0 - Which GNU Freefont should I download and install, the ttf, otf, sfd?

Next, how should I use these in your test? Would using kate be okay by just changing the font it uses to the Freefont and printing your test?

Let me know and send the test too.

For the specific task at hand, i.e. installing driver packages from Brother, then rpm2txz is OK for use when called with:
The Brother rpm packages can be successfully converted using this technique, but the user should check the resulting doinst scripts in the packages.
Another thing that none of these techniques will do is create a symlink (ln -s /etc/rc.d/rc.cups /etc/init.d/cups). This allows the Brother install scripts to stop and start the CUPS daemon during the package install.

Installing the package will have overwritten what was already installed.

irgunII,

the problem that I encountered is complicated so I described it in the separate thread: Brother laser printer and GNU FreeFont.

Your printer isn’t PostScript one but I think it’s good idea to test GNU FreeFont using some non-PostScript laser printer made by Brother as well. So if you’re still willing to perform the test I’m inviting you to the mentioned thread.