Bug 1778425

Created attachment 1640960 [details]
File: backtrace

Created attachment 1640961 [details]
File: cgroup

Created attachment 1640962 [details]
File: core_backtrace

Created attachment 1640963 [details]
File: cpuinfo

Created attachment 1640964 [details]
File: dso_list

Created attachment 1640965 [details]
File: environ

Created attachment 1640966 [details]
File: exploitable

Created attachment 1640967 [details]
File: limits

Created attachment 1640968 [details]
File: maps

Created attachment 1640969 [details]
File: mountinfo

Created attachment 1640970 [details]
File: open_fds

Created attachment 1640971 [details]
File: proc_pid_status

This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Hi Alex,

thank you for reporting the issue!

Are you able to reproduce the issue with the latest sane-backends and updated Fedora?

Nope. I think there were some unsatisfied dependencies to blame, so it is more a packaging flaw rather than a software bug. IIRC the problem disappeared after I installed libnsl, but I forgot to update the bug info :(

Thank you for the info, Alex!

Installing libnsl sounds familiar to me - isn't your scanner manufacturer Samsung by any chance? IIRC There was an issue with samsung 3rd party drivers not being able to scan because they're are built with older libnsl, which is now not in glibc.

It is Brother, an old one, apparently the issue is the same!

▲ ~ ldd /usr/lib64/sane/libsane-brother2.so                                                                                                               
	linux-vdso.so.1 (0x00007ffc82941000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f57db01a000)
	libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f57daffe000)
	libusb-0.1.so.4 => /lib64/libusb-0.1.so.4 (0x00007f57daff6000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f57daeb0000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f57daea9000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f57dacdf000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f57db18e000)
	libusb-1.0.so.0 => /lib64/libusb-1.0.so.0 (0x00007f57dacc0000)
	libudev.so.1 => /lib64/libudev.so.1 (0x00007f57dac96000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f57dac7b000)

so the actual problem is on the proprietary driver side. Yet I think it would be nice to have a workaround for that.

Just noticed that the driver itself is GPLed long time ago. So it could be repackaged in a more sensible way. Requires some effort to compile it in a kosher way on a modern system, though.

What project is it? brscan? Is there a source code available? AFAIK there are only pre-compiled binaries, which doesn't solve the problem.

The real problem is that pre-compiled binary depends on deprecated library, which can go away anytime.

Adding a weak dependency on libnsl to sane-backends is not good solution too - most people don't use them, so libnsl defined as weak dependency will bring up libnsl to most users, not just Brother users.

I'll use 'Suggests:' for libnsl https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/ for now.

It will be built for F31, F32 and F33.

FEDORA-2020-1ac44833fc has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-1ac44833fc

Yes, it is brscan. Here is the link to the source code: https://support.brother.com/g/b/downloadend.aspx?c=eu_ot&lang=en&prod=mfc215c_eu_as&os=128&dlid=dlf006820_000&flang=4&type3=577&dlang=true

FEDORA-2020-1ac44833fc has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-1ac44833fc`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1ac44833fc

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

I looked into the source tarball - unfortunately there are still some shared libraries which are pre-compiled and its source code is missing - libbrcolm, libbrscandec... so it is not good for packaging in Fedora IIRC.

Apparently you are right, there are blobs :(

FEDORA-2020-1ac44833fc has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.