Description of problem: sane-backends are installed on x86_64 Fedora (in casu FC4) systems as two packages, one for i386 and the other for x86_64. Both packages are logically identical. In case of a fix which normally involves a compilation only the i386 installed package will be changed, the x86_84 package remains unchanged and therefore the fix will not be implemented. A procedure for compiling sane-backends targeting the x86_64 package is missing. The sane project only provides the i386 procedure and since the Fedora project has provided the x86_64 package it ought also to provide the necessary procedure for compiling it. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I don't understand your request. At what point does rebuilding the sane-backends source RPM on x86_64 fail?
I am not rebuilding the sane-backends source rpm, I am compiling it and the compilation hits the installed i386 but the system actually runs the x86_54 version so the fix was not applied. I believe it is an infrastructural bug to have parallel applications for both i386 and x86_64. I found that for firefox it is even worse, I have 5 firefoxes on my system, 2 x86:64 and 3 i386. And there are probably many more if I start looking for it.
I'm sorry, but I don't understand what you are saying - what do you mean by 'the fix was not applied' when you were compiling?
The fix was not applied to the version (x86_64) that I am running therefore it had no effect on my situation and hence "the fix was not applied". The source fix was downloaded at the advice of the developer and applied according to his procedure. This procedure updates the i386 version only and when asked what to do with the x86_64 version the developer refers to the packager of that version because he has not been involved in the packaging.
Are you installing updates via yum, or some other mechanism?
I was using configure, make and make install.
What fix are you talking about? If it's of general interest, I'd like to use it in the proper packages. You should really be building patched RPM packages, otherwise your system might get even more messed up than it already is due to multilib shenanigans. To do that, simply do rpm -i <src-rpm-file> put the patch into the SOURCES directory, include and apply it in the spec file, bump the release and build it once for i386 and the second time for x86_64: rpmbuild -ba --clean --rmsource --target=i386 <spec-file> rpmbuild -ba --clean --rmsource --target=x86_64 <spec-file> Install the resulting packages with rpm -Uvh <....i386.rpm> <....x86_64.rpm> Read Maximum RPM for more info about building RPM packages at http://www.rpm.org.
It is of interest to a certain number of hp scanners (in casu HP scanjet 7400c) which suffer segmentation fault. This was corrected in Build 182 of the avision backend, now included in the recently released version 1.0.17. I don't know if the information you provided regarding building an rpm package is motherhood but for me it would have been nice to have it in a readme for the package. I'll try the recepe.
Instructions how to build RPM packages would be a bit of overkill to have in each package. If you refer to building via the conventional way (configure && make && make install), contact upstream (sane-project.org) about including instructions. Meanwhile I've built sane-backends-1.0.17-0.fc4.1 which should hit updates-testing shortly. If I don't receive complaints about it, I'll push it to final by the end of the week.