[sane-devel] [PATCH] xerox_mfp - man page misnamed
Hi all, I needed to build a tar file of latest CVS to aid in custom RPM generation. I found make dist failed without the following fix to xerox_mfp man page. Chris Index: doc/Makefile.in === RCS file: /cvsroot/sane/sane-backends/doc/Makefile.in,v retrieving revision 1.100 diff -u -w -r1.100 Makefile.in --- doc/Makefile.in15 Dec 2008 21:48:20 -1.100 +++ doc/Makefile.in11 Jan 2009 23:49:16 - @@ -115,7 +115,7 @@ sane-u12.man sane-niash.man sane-sm3840.man sane-genesys.man sane-hp4200.man \ sane-mustek_usb2.man sane-hp3500.man sane-pixma.man sane-stv680.man \ sane-hp5590.man sane-hpljm1005.man sane-cardscan.man sane-hp3900.man \ - sane-epjitsu.man sane-hs2p.man sane-canon_dr.man sane_xerox_mfp.man + sane-epjitsu.man sane-hs2p.man sane-canon_dr.man sane-xerox_mfp.man .PHONY: all clean depend dist distclean html html-man install \ sane-html uninstall
[sane-devel] [PATCH] xerox_mfp - man page misnamed
They will be CVS snapshots... If someone finds them useful then I guess I could post them on the net. I'm starting from Fedora's RPM spec files and a few of their patches no longer apply against current CVS. I don't need them personally but probably others do. I'll try to get those working and incorporated into CVS were appropriate. Once thats done then I can publish my RPM's. Chris m. allan noah wrote: Committed, thanks! Any word on publishing these updated rpms somewhere? allan On Sun, Jan 11, 2009 at 6:59 PM, Chris Bagwell chris at cnpbagwell.com wrote: Hi all, I needed to build a tar file of latest CVS to aid in custom RPM generation. I found make dist failed without the following fix to xerox_mfp man page. Chris Index: doc/Makefile.in === RCS file: /cvsroot/sane/sane-backends/doc/Makefile.in,v retrieving revision 1.100 diff -u -w -r1.100 Makefile.in --- doc/Makefile.in15 Dec 2008 21:48:20 -1.100 +++ doc/Makefile.in11 Jan 2009 23:49:16 - @@ -115,7 +115,7 @@ sane-u12.man sane-niash.man sane-sm3840.man sane-genesys.man sane-hp4200.man \ sane-mustek_usb2.man sane-hp3500.man sane-pixma.man sane-stv680.man \ sane-hp5590.man sane-hpljm1005.man sane-cardscan.man sane-hp3900.man \ - sane-epjitsu.man sane-hs2p.man sane-canon_dr.man sane_xerox_mfp.man + sane-epjitsu.man sane-hs2p.man sane-canon_dr.man sane-xerox_mfp.man .PHONY: all clean depend dist distclean html html-man install \ sane-html uninstall --
[sane-devel] How best to distribute the m4 directory?
Hi all, I notice one of Fedora's patches against sane-backends-1.0.19.tar.gz is that they add back in the m4/ directory that is in CVS but not packaged by make dist. Thats because they need to rerun autoreconf to make some configure.in patches take affect. Since we are distributing configure.in and acinclude.m4 (which references m4 directory), I'm assuming we should be packaging the m4 directories as well. As it stands, the end user needs to stop using released packages and go to CVS if they make any source code changes that require rerunning autoreconf. I'd like to help resolve this issue but need some direction from whomever looks over the make infrastructure the most. I see a few basic options. #2 and #3 are my preferences. 1) Follow include/ directories lead and place a Makefile in m4/ directory so that its files can be packaged up. Not sure how autotools will react to that but it probably ignores anything that doesn't end in .m4. 2) Change makefiles to be built using automake tools. It handles the dirty work pretty good. It would also simplify the Makefile logic quite a bit. Current Makefile.in look very much like a hand generated files based on how automake would do it anyways. Any objections to using automake? 3) Port over latest automake logic for DISTFILES which supports path names and will both create these directories and copy files. This would allow adding m4/byteorder.m4 and similar to toplevel DISTFILES in Makefile.in and would also allow removing the unneeded Makefile from the include/ directory and move its work to toplevel or src/ as well. Chris
[sane-devel] How best to distribute the m4 directory?
m. allan noah wrote: On Sun, Jan 11, 2009 at 9:01 PM, Chris Bagwell chris at cnpbagwell.com wrote: I'd like to help resolve this issue but need some direction from whomever looks over the make infrastructure the most. I see a few basic options. #2 and #3 are my preferences. 1) Follow include/ directories lead and place a Makefile in m4/ directory so that its files can be packaged up. Not sure how autotools will react to that but it probably ignores anything that doesn't end in .m4. 2) Change makefiles to be built using automake tools. It handles the dirty work pretty good. It would also simplify the Makefile logic quite a bit. Current Makefile.in look very much like a hand generated files based on how automake would do it anyways. Any objections to using automake? 3) Port over latest automake logic for DISTFILES which supports path names and will both create these directories and copy files. This would allow adding m4/byteorder.m4 and similar to toplevel DISTFILES in Makefile.in and would also allow removing the unneeded Makefile from the include/ directory and move its work to toplevel or src/ as well. Which of these works best on all the platforms on which SANE builds? #1 was my original intention... allan All three should be equally portable. Option #3 would run 'sed' and 'sort' but existing Makefile.in is already using 'sed' so should not be any issues in enhancing the dist target to support paths. Option #2 should also be equally portable. I have experience in other projects that use automake on linux, various BSD's, OS/2, cygwin, Mac OS X, and a lot of fringe OS's like Atari and DOS. No issues found... All issues I've had revolve around libtool's behavior and not automake itself. I remember being uncomfortable the first time a project I worked with switched to automake but it turned out for the best. If you guys are game for it, I'll be happy to do the conversion. I'll try to give you a feel for how automake makes things easier to read. I think the toplevel Makefile.in would convert to the following for Makefile.am (untested but should be close). Its pretty easy to convert over because the sane Makefile.in's are already very automake-ish for what ever reason. autoreconf converts Makefile.am into Makefile.in that looks very much like todays Makefile.in but with some additional useful targets and maybe slightly enhanced versions of existing targets (like dist and install can install filenames with directory names on them). Then Makefile.in gets converted to Makefile in same step as today. Basically, automake takes care of defining all your standard variables like $prefix and all your standard targets like install/uninstall, install-man, dist, clean, depend, ctags/etags, and so on. Then we can just worry about the project specific stuff. The backend/Makefile.am would be much more interesting example to see and show better benefit but it would take me a couple of hours to prototype it so would like some feedback first (so not to waste precious time :-) ). Also, notice any Autotool's related files are automatically track so do not need to be manually listed any more. Chris --- Makefile.am --- SUBDIRS = include lib sanei backend frontend tools doc po DIST_SUBDIRS = include lib sanei backend frontend tools doc po EXTRA_DIST = AUTHORS COPYING ChangeLog ChangeLog-1.0.0 ChangeLog-1.0.1 \ ChangeLog-1.0.2 ChangeLog-1.0.3 ChangeLog-1.0.4 ChangeLog-1.0.5 \ ChangeLog-1.0.6 ChangeLog-1.0.7 ChangeLog-1.0.8 ChangeLog-1.0.9 \ ChangeLog-1.0.10 ChangeLog-1.0.12 ChangeLog-1.0.13 ChangeLog-1.0.14 \ ChangeLog-1.0.15 ChangeLog-1.0.16 ChangeLog-1.0.17 ChangeLog-1.0.18 \ ChangeLog-1.0.19 \ LICENSE NEWS \ PROBLEMS PROJECTS README README.aix README.beos README.darwin README.djpeg \ README.freebsd \ README.hp-ux README.linux README.netbsd \ README.openbsd README.os2 README.solaris README.unixware2 README.unixware7 \ README.windows README.zeta \ sane-backends.lsm $(PACKAGE)-$(VERSION).lsm: $(PACKAGE)-$(VERSION).tar.gz $(PACKAGE).lsm ( cat $(PACKAGE).lsm | \ sed -e s|_DATE_|`date +%d%b%y`|g \ -e s|_VERSION_|$(VERSION)|g \ -e s|_T_S_|`find $(PACKAGE)-$(VERSION).tar.gz -printf \%4k\`|g\ -e s|_L_S_|`find $(PACKAGE).lsm -printf %4k`|g \ $(PACKAGE)-$(VERSION).lsm \ ) lsm: $(PACKAGE)-$(VERSION).lsm # # Keep the .cvsignore files sorted, and use this target to do it. # PERL=perl sort-cvsignore: for f in `find . -name .cvsignore`; do \ $(PERL) -e 'print sort ;' $$f $$f.tmptmp; \ mv $$f.tmptmp $$f; \ done done # # Check to make sure only sane_ and sanei_ symbols are exported from # the libraries # libcheck: @echo Libraries exporting 'illegal' symbols: @for lib in backend/.libs/*.a; do \ lines=`nm -g $$lib|grep '\( T \)\|\( D \)'|egrep -v ' sane_| sanei_
[sane-devel] How best to distribute the m4 directory?
Ah yes, I hadn't thought about looking at iscan source code yet; although I'd recently installed the binary to play with on my new Epson Artisan 800. I just looked at iscan now and it is indeed a great starting point for this task and I like the diff approach to ltmain.sh Olaf, if you have suggestions on how to proceed then please let me know. Based on your past work, I'm guessing you could whip this up pretty fast... I also don't mind diving right in and know I can get it completed soon as well. I can provide some draft patches soon. I don't think we can split the work very well but definitely can use each other to test on variety of autotool versions (those issue tend to be limited to configure.ac though). Chris m. allan noah wrote: Sounds good. Chris- can you coordinate with Olaf to do something similar with sane's copy of ltmain? allan On Mon, Jan 12, 2009 at 7:43 PM, Olaf Meeuwissen olaf.meeuwissen at avasys.jp wrote: m. allan noah kitno455 at gmail.com writes: [switching sane build system to autotools] You (and others on this list) have more experience with these tools than I, so I am willing to defer to your judgement. But watch out for the sane-specific copy of libtool. We have some hacks in there to make each sane backend's .so export symbols so that it can be linked directly. The iscan sources include these changes as a patch to ltmain.sh and uses a little bootstrap script to apply it. I'd be happy to help out with converting the SANE build system to an autotool based one. FWIW, iscan started out with SANE's build system and I've converted it to use autotools a few years ago. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
[sane-devel] How best to distribute the m4 directory?
Olaf Meeuwissen wrote: Indeed, it is a bit difficult to split the work, but we could do it a directory at a time. Start with the top-level without descending the source tree and then add in subdirectories as you go. That way, each of us can do a different directory and not step on the other's toes, so to speak. What you posted to the list seems like a reasonable starting point for the top-level directory (after you add a license blurb). We should probably focus on getting the regular build for the binary parts to work ASAP, then deal with the support targets for documentation and website info and leave the niceties like build-time options to select specific backends and such for later. Of course, we should also switch sane-frontends over. More detailed discussion we should probably take off-list. What do you think? Sounds good... I've got the top level changes done and will try to forward a patch tomorrow for people to comment on. Chris
[sane-devel] Epson SX600FW support
On 1/14/2009 12:00 PM, Thibaut GIRKA wrote: Hi, I bought an Epson SX600FW scanner/printer, and it doesn't work with SANE (at least the version in debian/testing). When I do scanimage -L, here is what I get: [epson2] Cannot send this command to a networked scanner I have recently purchased an Epson Artisan 800 which based on external appearance are probably related. I also get this same error message. To be more specific though, we are using this with the ethernet/wifi connection and not USB. Also, its worth pointing out the epson2 driver does auto-discover the scanner and perform basic communications with it (as you mention towards the end). So, why cannot this command be sent to a networked scanner? The reason for the failure in code seems reasonable. The code is using a function that defines no length for the response message. It would be painful to implement waiting for random length packets responses coming back from the printer. So the better question to me is why was a length not specified? Do all scanners have the same length for this command? However, I modified epson2.c (at line 1068) to disable the identity2 request. By doing that, I can scan. A similar solution is to modify the code to specify a length of the response to expect. I've not put much effort in this debug yet because I requested access to developer docs from Epsons developer web page and was hoping to hear back... No word in 2 weeks though so they may have thought I'm not important enough to get it. But google turned up a PDF of some other random Epson scanner that shows the length of identity2 response. The patch at the end of this email specifies the response length and also fixes the issue. As I've spent a grand total of 1 hour on researching this so far, I do not know enough yet to decide if the length is the real fix (and safe for all scanners) or disabling the call like you did is right (esci_request_identity() also uses a zero length but is wrapped by a != SANE_EPSON_NET to prevent similar error). Hopefully, others on the list already have experience and can immediately answer. However, I get an error when requesting a preview, and the connexion between the scanner and the computer stops from time to time (I then have to restart the scanner). Same behavior for me. Simple scanimage appeared to scan a blank page when I tried but xsane's preview window errored out. I'm hoping this next part is as easy to debug but I've been side track cleaning up some sane build stuff at the moment. Also, heres to hoping Epson has some Docs they can distribute to help my understanding occur faster. :-) Chris Index: epson2-commands.c === RCS file: /cvsroot/sane/sane-backends/backend/epson2-commands.c,v retrieving revision 1.4 diff -u -w -r1.4 epson2-commands.c --- epson2-commands.c 3 Feb 2008 12:09:09 - 1.4 +++ epson2-commands.c 15 Jan 2009 01:09:27 - @@ -702,7 +702,7 @@ params[0] = ESC; params[1] = s-hw-cmd-request_identity2; - status = e2_cmd_info_block(s, params, 2, 0, buf, len); +status = e2_cmd_info_block(s, params, 2, 46, buf, len); if (status != SANE_STATUS_GOOD) return status;
[sane-devel] Small build fixes
On 1/14/2009 6:12 PM, Pierre Willenbrock wrote: Hi list, i tried to build sane with different source and build directories and ended up needing the attached patch to tools/Makefile.in. I am not sure if i got the build-directory creation right, but it works for different source/build directories as well as when they are identical. If no one objects, i will commit this in about 2 days. Regards, Pierre This patch was good timing for me. I'm working on moving the top level Makefile to use automake. I needed this change to be able to use automake's make distcheck target; which tests building in a directory different then source. One of the Makefiles is failing on the cleanup phase but I'm almost got it working. Chris
[sane-devel] [PATCH] Make existing Makefile.in's automake compatible
Hi all, I hope that someone can commit the following patch. They are minor changes to existing Makefiles, except top-level Makefile, to make them compatible with automake generate Makefiles. Changes include: * Pierre Willenbrock's patch to allow compiling and installing tool's directory when build and source directory are not the same. Needed by automake's distcheck target. * Add support for $(DESTDIR) on uninstall target to match existing support in install target. This is used by automake's distcheck target. * Changed distdir to mean a path related to current Makefile (top_distdir would have been a better name for former code) to match automake's behavior. * Add new targets distdir, dvi, check, installcheck, and distuninstallcheck to allow running make distcheck target when it finally exists. I will send some actual automake specific patches next but hope to get these patches incorporated first. This patch will allow us to implement automake support slowly and to only directories we chose. Chris -- next part -- An embedded and charset-unspecified text was scrubbed... Name: automake_alignment_diff Url: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090115/09cea2e6/attachment.txt
[sane-devel] [PATCH] Make existing Makefile.in's automake compatible
On Thu, Jan 15, 2009 at 9:35 AM, Julien BLACHE jb at jblache.org wrote: m. allan noah kitno455 at gmail.com wrote: Hi, Chris- register on alioth, and request to join SANE, and we'll let you clean up your own messes :) Haha, that's another way to put it :p OK, submitted my request... only fair to clean up my own messes. :-) If, along the way, we could make it so that each backend only gets linked to the relevant libraries (without resorting to --as-needed), that'd be definitely great. I'm doing that with a monster patch right now and I'm looking forward to simplifying that :p Mind emailing me this monster patch for my reference? I've done this on another project to clean up warnings reported by debian's deblint util and most the work is in configure script. Debian has a web page somewhere with build logs that reports the unneeded libraries. I'll have to dig that page up for sane as it helps in this task. Chris -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090115/c001baf0/attachment.htm
[sane-devel] make fails on debian unstable
norv wrote: Hi and thanks for sane, I am trying to compile from cvs on debian sid and make fails with following lines ... epkowa.desc: Warning: Backend `epkowa': 8 USB devices without :usbid brother.desc: Warning: Backend `brother': 1 USB devices without :usbid brother2.desc: Warning: Backend `brother2': 9 USB devices without :usbid make[1]: Leaving directory `/home/norv/sane-backends/tools' making all in doc make[1]: Entering directory `/home/norv/sane-backends/doc' Generating index for sane.ps... make[1]: *** [sane.ind] Error 1 make[1]: Leaving directory `/home/norv/sane-backends/doc' make: *** [all-recursive] Error 1 norv at sid5600:~/sane-backends$ I have libusb-dev installed and my configure argument is ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var BACKENDS=pixma I get the same error with and without the BACKENDS=pixma entry. What could I do? Norv Is it possible to tell me what time you took a snapshot of CVS? I committed some updates to Makefile.in's at roughly the timestamp of your email. I didn't touch anything related to your failure but I'll try to help out to be sure its not my changes. I've just done a cvs update and mine compiles OK there: Generating index for sane.ps... Generating sane.ps... Some things follow to help debug this. Try running make in debug mode to get better reason for failure (warning: volume of info is huge). cd doc make -d also, the Makefile.in is hiding the output that may explain the failure better. Use an editor that will preserve *tabs* and modify the lines in doc/Makefile.in file: sane.ind: sane.tex net.tex @echo Generating index for sane.ps... @touch sane.ind @$(LATEX) $(srcdir)/sane /dev/null /dev/null \ $(MAKEINDEX) sane.idx 2/dev/null to be (remove @'s and /dev/null's): sane.ind: sane.tex net.tex @echo Generating index for sane.ps... touch sane.ind $(LATEX) $(srcdir)/sane \ $(MAKEINDEX) sane.idx You can email complete output directly to me if it doesn't seem to make sense. Chris p.s. it never hurts to run cvs update and autoreconf afterwards just to see if it helps.
[sane-devel] make fails on debian unstable
That is probably the problem now that you mention it... I just looked at tracker and their is a patch that seems incomplete. I could probably get it working but I have an issue to resolve first. I'm running a newer version of autoconf (2.63) then current CVS files seem to be based on. Any issues with me submitting configure updates from that version of autoconf? See my other email as well on this. Chris On 1/16/2009 7:15 PM, m. allan noah wrote: there were some patches recently either on the list or in the bug tracker to make sane.ps optional if the user did not have latex installed. allan On Fri, Jan 16, 2009 at 7:11 PM, Chris Bagwellchris at cnpbagwell.com wrote: norv wrote: Hi and thanks for sane, I am trying to compile from cvs on debian sid and make fails with following lines ... epkowa.desc: Warning: Backend `epkowa': 8 USB devices without :usbid brother.desc: Warning: Backend `brother': 1 USB devices without :usbid brother2.desc: Warning: Backend `brother2': 9 USB devices without :usbid make[1]: Leaving directory `/home/norv/sane-backends/tools' making all in doc make[1]: Entering directory `/home/norv/sane-backends/doc' Generating index for sane.ps... make[1]: *** [sane.ind] Error 1 make[1]: Leaving directory `/home/norv/sane-backends/doc' make: *** [all-recursive] Error 1 norv at sid5600:~/sane-backends$ I have libusb-dev installed and my configure argument is ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var BACKENDS=pixma I get the same error with and without the BACKENDS=pixma entry. What could I do? Norv Is it possible to tell me what time you took a snapshot of CVS? I committed some updates to Makefile.in's at roughly the timestamp of your email. I didn't touch anything related to your failure but I'll try to help out to be sure its not my changes. I've just done a cvs update and mine compiles OK there: Generating index for sane.ps... Generating sane.ps... Some things follow to help debug this. Try running make in debug mode to get better reason for failure (warning: volume of info is huge). cd doc make -d also, the Makefile.in is hiding the output that may explain the failure better. Use an editor that will preserve *tabs* and modify the lines in doc/Makefile.in file: sane.ind: sane.tex net.tex @echo Generating index for sane.ps... @touch sane.ind @$(LATEX) $(srcdir)/sane/dev/null/dev/null \ $(MAKEINDEX) sane.idx 2/dev/null to be (remove @'s and /dev/null's): sane.ind: sane.tex net.tex @echo Generating index for sane.ps... touch sane.ind $(LATEX) $(srcdir)/sane \ $(MAKEINDEX) sane.idx You can email complete output directly to me if it doesn't seem to make sense. Chris p.s. it never hurts to run cvs update and autoreconf afterwards just to see if it helps. -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org
[sane-devel] Autotools generated files and CVS
Hi all, I've not seen this discussed in mailing list archive. Is there any past discussions? Its pretty common practice (but not 100%) that projects using autotools to not check in files generated by autoconf/autoreconf into CVS/git/etc. Currently, the sane project falls into the camp that they check these files into CVS. Is the project open to removing these files? What would that change mean to you? It requires CVS users to have autotools installed on their system and the first time you check out CVS, you'd have to manually run autoreconf --install. Not much beyond that; although autotools will be required to stay on the system in case a CVS update requires rerunning it. Reasons to continue leaving them in CVS: * Autotools not required, as long as developer is not modifying configure.in Reasons for leaving them out of CVS: * People submitting patches tend to have a wide range of autotools versions on their systems. This leads to multiple issue. They include but are not limited to: ** A one line change to configure.in will cause 100's of lines of updates to CVS after running autoreconf if submitters version of autotools doesn't match the previous persons (newer or older). For example, I'm running autoconf 2.63 but main submitter to current CVS seems to be using 2.61 ** Autotools scripts are not perfect when it updates files. When you rerun autoreconf, its easy to have only some autotools support files updated. The support files could be from incompatible versions of autotools. Its easy for this mismatched files to find their way into CVS and cause other peoples compiles to fail. I've seen this in other projects. The work around is to run autoreconf --install --force but that has its own issues (like overwriting our custom ltmain.sh). Files requested to remove from CVS. acinclude.m4 aclocal.m4 config.guess config.sub configure install-sh mkinstalldirs include/sane/config.h.in Files note requested to remove: ltmail.sh [ custom modified ] libtool.m4 [ forces aclocal.m4 to have macros that match custom ltmail.sh ] [ automake can install/overwrite the following files at times ] INSTALL NEWS README AUTHORS ChangeLog COPYING Chris
[sane-devel] make fails on debian unstable
On 1/17/2009 7:54 AM, m. allan noah wrote: On Fri, Jan 16, 2009 at 9:29 PM, Chris Bagwellchris at cnpbagwell.com wrote: That is probably the problem now that you mention it... I just looked at tracker and their is a patch that seems incomplete. I could probably get it working but I have an issue to resolve first. I'm running a newer version of autoconf (2.63) then current CVS files seem to be based on. Any issues with me submitting configure updates from that version of autoconf? See my other email as well on this. sure, let it rip. but now you see why we keep all that stuff in cvs- don't leave it up to me to generate it the day before a release and hope it works for everyone :) Yes, that would be crazy. Based on this response and Julien's, I'm getting ready to submit initial automake support for top level makefile. This will give a new target called distcheck which will test creating a package.tar.gz file and compile, install, uninstall in stressful ways. For people modifying configure or Makefiles, its a great target to require them to get working before acceptting the patches. Chris allan
[sane-devel] Autotools generated files and CVS
On 1/17/2009 3:20 AM, Julien BLACHE wrote: Chris Bagwellchris at cnpbagwell.com wrote: Hi, I've not seen this discussed in mailing list archive. Is there any past discussions? We leave autotools files in CVS because: - it's a pain to regenerate them - developers don't always know autofoo - distributions ship broken version of the autotools routinely - autotools versioning issues JB. Fair enough. Might as well continue on this way as long as its not presenting problems to the group. Chris
[sane-devel] Autotools generated files and CVS
On 1/17/2009 4:21 AM, Julien BLACHE wrote: Chris Bagwellchris at cnpbagwell.com wrote: * Autotools not required, as long as developer is not modifying configure.in While speaking of configure.in... it could use a good cleanup as you've probably seen, and while doing so it could also avoid testing for freebsd/beos/osx things when running on Linux and vice-versa. That would speed things up a fair bit. JB. I'll keep this in mind... when I get to part of linking in only libraries needed then I'll try to do some general configure cleanup. Chris
[sane-devel] Autotools generated files and CVS
On 1/18/2009 8:50 PM, Olaf Meeuwissen wrote: See also, http://www.gnu.org/software/gettext/manual/html_node/Files-under-CVS.html#Files-under-CVS. Agree with all your comments... Also, here is similar link from Automake that describes cvs issues in a little more detail. http://sourceware.org/automake/automake.html#CVS I'll continue down the current path of checking in updates until we are at the automated bootstrapping point. I guess it won't be to conveniencing that its painfree on users to remove generated files until it truly is pain free. BTW, on all projects I've worked on, I've usually commited to making sure configure.ac and Makefile.am's work with widest range of autotools as possible; even when those tools are known buggy. So far I've not had much issues with supporting +/- 2 years or more worth of versions. In other words, keeping it pain free to a wide swath of developers. Chris
[sane-devel] Autotools generated files and CVS
Julien BLACHE wrote: autofoo one has to know. As for the amount of pain involved, I can only think of the time it takes. Julien mentions versioning issues and broken deployment but I have little experience with that. You obviously never had to work with broken libtool versions, which is about every libtool version until something like 3 years ago, and even then, there have been some pretty broken versions after that too. If going with automake means we have to put up with the maintainer mode crap and bootstrapping the build system after every pull, then thanks, but no thanks, I'm keeping the current one. JB So I think its safe to say that you've had some sort of bad experience with some part of the autofoo chain in the past and have settle on current method as comfortable. Thats more then fair enough and a reason to stick with current approach. This is ultimately my reason to bring it up in first place so that I understand the developers preference. I'd like to be clear on one point. The issues we've discussed are common to using any autofoo products and are a concern with or without automake being added. In fact, the issues I've personally experience have never fallen in automake's areas... Issues were with either autoconf or libtool. You've mentioned automake maintainer mode a few times to resolve issues... I'd like to understand the exact issue if thats possible so I can try to resolve it up front. Was it ultimately the well documented issue with CVS timestamps and enablity of even running autoreconf to generate the correct updates to various generated files when running different versions of autotools? My suggestion of removing generated files is based on my experience. It happens that in my experience it was a royal pain until I both made sure maintainer mode was ON (the default) and removed generated files from CVS. I suspect the other approach (checking in generated files and turning off maintainer mode) doesn't really help solve any issues with mixed autotools versions but isolates the issue to key people that tend to maintain the configure and makefile frameworks. In otherwords, the ones that understand how to run autoreconf --force -install and then back out the bad things it does. I think for the most part, we are all agreeing on core issues. - Libtool is a big concern and should be in CVS to reduce issues. - Need a bootstrapping solution to recover from autoreconf --force --install to aid distributions. - Don't want to tax all developers with autofoo issues. I don't think bootstrapping is taxing developers myself but I know plenty of people that feel otherwise. So we will proceed with current approach of checking generated files in. We may need to further explore Olaf's suggestion of defining acceptable autotools versions to use for CVS submissions at some point. But it sounds like you guess haven't had much of issues with autoconf so far so perhaps it will continue to not be a problem in the future. Chris
[sane-devel] improved libcheck target
stef wrote: Le mercredi 21 janvier 2009 06:42:17 stef, vous avez ?crit : Hello, I have tried 'make libcheck' now it handles dynamic libraries. I notice it fails at the first violation without testing following libraries. I'd rather have it check all libraries then fail at the end so we get the full list of violations. ... While I am at it, here's a proposed patch to make libchek behave like that. Regards, Stef Looks good to me... I'll commit it soon . But while its out for review, could some more people look at this patch? Specifically, at the list its checking for non-standard sane_* symbols. Since we are building dynamic libraries by default and libcheck wasn't working before in default case, I wasn't sure how outdated that list was. I've not yet had time to compare the list to current API document but looks pretty close. Also, it does produce useful information for current maintainers of canon, epjitsu, espon2, fujitsu, hs2p, pixma, and epsons backends as shown in Stef's first email. Chris
[sane-devel] SANE_DEBUG_* items
Hi all, During my conversion of backend/Makefile.am I ran into following minor issue. I'd prefer to always pass in -DBACKEND_NAME to truly be backend name and not based on filename being compiled. This turned up that BACKEND_NAME is not really meant like it sounds. Instead its mostly a way categorize debug messages via SANE_DEBUG_*. What I'd prefer to do is modify Makefile to only pass in the real backend name and if a specific backend wants finer granularity or wants to pretend its something else then it should override BACKEND_NAME itself... In fact, several backend source code already does this anyways. Below is a list of files that rely on Makefile to change BACKEND_NAME instead of doing it themselves. These same files do not document in MAN pages that they even support the extra granularity. So I'd like to get agreement if its OK to change them to real BACKEND_NAME or if I should update MAN pages to reflect actual behaviour. epson - man page only has SANE_DEBUG_EPSON but also supports SANE_DEBUG_EPSON_SCSI. epson2 - no man page but supports SANE_DEBUG_EPSON2_NET and SANE_DEBUG_EPSON2_SCSI. rts8891 - no man page but supports additional SANE_DEBUG_RTS88XX_LIB. umax_pp - man page is missing SANE_DEBUG_UMAX_MID Chris
[sane-devel] SANE_DEBUG_* items
stef wrote: rts8891 - no man page but supports additional SANE_DEBUG_RTS88XX_LIB. The rts8891 man page existed but the backend was forgotten in the Makefile. This is fixed now. Ahh, yes. I was mistakenly using my distribution's sane man pages instead of referring to doc/ directory. I see now they are documented for this backend so I will keep as-is. With no objections then I'll keep all current backend behavior and document man pages were missing. I'll also move forward with making BACKEND_NAME truly mean BACKEND_NAME in Makefiles and make minor update to source code were needed to override. Chris
[sane-devel] Net Backend and Avahi support
Hi all, I notice that configure defaults to turning off Avahi support for the net backend. Is there any reason for this not to be set to auto-detect by default? Also, assuming the feature works (I haven't tried it yet), it seems like a nice thing to mention in sane-net.man. I can add a comment to the man page if its a stable feature. Chris
[sane-devel] build sane-backends on Mac OS X -- 10.5.*
Did this fail during configure phase or make phase? Can you send error messages? If its large output or if its failure is in configure then can you send the output directly to me and the config.log that configure generates? I'm working on some large updates to Makefiles on sane so pretty familar with what could go wrong... Maybe I even caused your failure during recent submission. :-) Its on my TODO list to compile on a Mac OSX to see its status but I'm probably a week off before I can do that right now. Chris On Sun, Jan 25, 2009 at 7:44 PM, Dhi Aurrahman dio.rahman at gmail.com wrote: Hello all! I can successfully build the sane-backends on mac os x from here: http://www.ellert.se/twain-sane/ But, I need to have the latest sane-backends code from cvs to be compiled on mac os x. I have tried to check out the latest code from cvs; (configure, make -- but error). But I had such a hard time to figure it out. Could you help me to list out what we need for building sane-backends on mac os x? Many thanks! Best, Dio -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090125/606b20dc/attachment.htm
[sane-devel] build sane-backends on Mac OS X -- 10.5.*
dio.rahman at gmail.com wrote: And then I go to the make phase. gave me following error message configure.in:136: error: possibly undefined macro: AC_DEFINE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. make: *** [configure] Error 1 I can confirm that a fresh CVS checkout will not compile on Mac OSX. This is automake and timestamp issues raising its ugly head that was discussed somewhat on mailing list a few days back. I checked some files in out-of-order 4 days ago I guess and this is causing Makefile.in to want to rebuild files. Normally, thats not the end of the world but configure.in has some issues on Mac OSX it looks like right now. Something about the pkg-config macros are dying. I'll look into both above issues more in the near future but for an immediate work around, I was able to get a compile started from a fresh CVS checkout by doing this. I manually copied the lines below from another computer so I may have a typo in a filename or two. cd sane-backend touch acinclude.m4 aclocal.m4 m4/libtool.m4 m4/byteorder.m4 m4/stdint.m4 configure Makefile.am Makefile.in ./configure make This compiled successfully. Chris
[sane-devel] build sane-backends on Mac OS X -- 10.5.*
Julien BLACHE wrote: Chris Bagwell chris at cnpbagwell.com wrote: This is automake and timestamp issues raising its ugly head that was discussed somewhat on mailing list a few days back. I checked some files in out-of-order 4 days ago I guess and this is causing Makefile.in to want to rebuild files. AM_MAINTAINER_MODE, please. JB. OK, I'll submit this soon as I have a chance to test it... I've not used it before but I assume it makes things no worse then they are today (I mean that today you have to rerun ./configure or similar any time you modify Makefile.in to make those changes go into affect and same will apply to Makefile.am's). Chris
[sane-devel] build sane-backends on Mac OS X -- 10.5.*
An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090126/ba9a338b/attachment.htm
[sane-devel] Usage of LIBOBJS/ALLOCA in Makefiles
Hi all, I notice that sane-backend's has the pretty common setup where it looks for functions that are commonly missing from some platforms and compiles its own internal version and they are all located in lib/ directory. I also see that it creates a library named liblib.a but no one usages it. Instead it uses LIBOBJS and ALLOCA in backend/Makefile.in. I can't really test the existing logic easy right now because all my platforms have external versions of all these utils. When I try to simulate it, the backend/Makefile.in fails. Not sure why. First question is if anyone on this list works on a platform that needs to link in the items from lib/ directory into the backends. I'd like confirmation that existing logic even works. Second question is this: I don't think its a good idea to link internal versions of standard functions into the backends. As I mentioned earlier, its super common for all projects to do this. If we link in, for example, snprintf into libsane and then if someone else links in libsane along with their own internal snprintf then we will get symbol collisions and failed compiles. In the past, I've worked around this issue by using preprocessor magic. When we detect internal version will be used then add a #define snprintf sanei_snprintf to some global header file. Then normal code keeps referring to just snprintf() but it sometimes get remapped to internal version without library knowing it. Exported symbol table will be proper sanei_ prefix as well. Anyone have issues with me making this change? Chris
[sane-devel] Minor network code change could use more testers
Hi all, I needed a secondary platform to do some automake tests on; besides linux; but the two I tried wouldn't compile (cygwin and solaris) even without automake support. So I've submitted a few portability improvements. The changes to remove MSG_NOWAIT and MSG_WAITALL could use a little testing in the epson2 and pixma (bjnp) backends. Also, changes seem safe but could use a review. I could only verify that epson2 changes continue to work same as before with my Epson Artisan 800 networked scanner (only scanimge -L currently works). Chris
[sane-devel] Please clean before CVS update
Thanks for the report. I should have also mentioned that part as a warning. I modified backend/Makefile to only link in what it needs. On my platform, coolscan2 didn't need math for some reason. I'll submit the fix in a minute but if others have similar issues, here is a list of items that you can add to the specific libsane_$(BACKEND_NAME)_la_LIBADD line and it will get auto-substituted by configure; generally only when a platform needs it. Please bare with me as these failure occur on platforms I do not have access to. @SCSI_LIBS@ @CAM_LIBS@: scsi related libraries @IEEE1284_LIBS@: ieee1284 libraries @MATH_LIB@: Math lib @JPEG_LIBS@ @TIFF_LIBS@: graphics libs @SOCKET_LIBS@: -lsocket (when needed) @GETHOSTBYADDR_LIBS@: -lnsl (when needed) @GPHOTO2_LIB@: -lgphoto @AVAHI_LIBS@: avahi @V4L_LIBS@: -lv4l @DL_LIBS@: -ldl Chris Nicolas Martin wrote: Hi, Just tried a full CVS rebuild. Compilation fails for me when linking coolscan2: /bin/sh ../libtool --silent --tag=CC --mode=link gcc -g -O2 -W -Wall -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -pedantic -ansi -Wl,-z,defs -rpath '/usr/lib/sane' -version-number 1:1:0 -o libsane-coolscan2.la libsane_coolscan2_la-coolscan2-s.lo ../lib/liblib.la libcoolscan2.la ../sanei/sanei_init_debug.lo ../sanei/sanei_constrain_value.lo ../sanei/sanei_config.lo ../sanei/sanei_config2.lo sane_strstatus.lo ../sanei/sanei_usb.lo ../sanei/sanei_scsi.lo -lusb ./.libs/libcoolscan2.a(libcoolscan2_la-coolscan2.o): In function `cs2_full_inquiry': /data/sane-backends/backend/coolscan2.c:2375: undefined reference to `floor' /data/sane-backends/backend/coolscan2.c:2383: undefined reference to `floor' collect2: ld returned 1 exit status make: *** [libsane-coolscan2.la] Erreur 1 Looking more deeply at what's going on, I noticed that the -lm flag (for math.h) has gone away from the linker command line. If I add it manually and recompile just this step, it works. Might there be any relation with config/make tools updates ? Nicolas Le vendredi 30 janvier 2009 ? 21:15 -0600, Chris Bagwell a ?crit : Hi all, I just submitted a rather large CVS update related to backend/ changing to automake and some related portability fixes. To be safe, please do a make distclean before updating to current CVS. I'm not aware of any issues if you do not but just a warning. Thanks also to Olaf for helping with the Makefile.am parts. Chris
[sane-devel] Please clean before CVS update
Julien BLACHE wrote:
../sanei/sanei_jpeg.c:229: fatal error: opening dependency file
.deps/../sanei/sanei_jpeg.Tpo: No such file or directory
compilation terminated.
make[1]: *** [../sanei/sanei_jpeg.lo] Error 1
make[1]: Leaving directory `/home/julien/devel/sane/sane-backends/backend'
make: *** [all-recursive] Error 1
Obtained with
BACKENDS=xerox_mfp ./configure --sysconfdir=/etc --prefix=/usr
make
Ahh yes. Fixed in CVS now. Its on my TODO list to clean up and expand
what can be optionally compiled in sanei directory to scsi/usb/tiff/etc
files as well. Need to get all dependencies right in
backend/Makefile.am first though.
Also, I've got the debian patches and reviewing now. I see I chose
PKG_CHECK_MODULES naming convention of ${PKGNAME}_LIBS while debian
patch uses a name that matches library name exactly (LIBJPEG for
example). Opps. Hopefully, no issues since intent is to be able to
drop that section of patches instead of rework.
Chris
[sane-devel] CVS and Solaris
Hi all, FYI: I've made enough updates to lib/, source code, and Makefile's that I can now compile everything under Solaris again and some basic tests work (I have no scanner hooked to the machine)... Well, it all working except for the hpljm1005 backend. I get a strange link error about not finding round() even though I have -lm and when I look at /usr/lib/libm.so I see the round() symbol marked as W (weak). I've tried moving the -lm earlier with no luck either. It could very well be because I have a buggy version of GNU tools on that platform. If anyone else wants to give it a spin, let me know if it works for you. gcc -shared -Wl,-h -Wl,libsane.so.1 -o .libs/libsane-hpljm1005.so.1.1.0 .libs/libsane_hpljm1005_la-hpljm1005-s.o ../sanei/.libs/sanei_init_debug.o ../sanei/.libs/sanei_constrain_value.o ../sanei/.libs/sanei_config.o .libs/sane_strstatus.o ../sanei/.libs/sanei_usb.o -Wl,-z -Wl,allextract,../lib/.libs/liblib.a,./.libs/libhpljm1005.a -Wl,-z -Wl,defaultextract -lm -lc -Wl,-z -Wl,defs Undefined first referenced symbol in file round ./.libs/libhpljm1005.a(libhpljm1005_la-hpljm1005.o) ld: fatal: Symbol referencing errors. No output written to .libs/libsane-hpljm1005.so.1.1.0 Chris
[sane-devel] Internal getopt opinions
Hi all, I'm trying to improve the way I modified the getopt.c to always be compiled... It has a problem, as pointed out by Mattias, that it requires some ordering issues with config.h. I'm seeking opinions before proceeding just to be safe. In case people didn't catch it, I've modified lib/getopt*.c to *always* compile now on any platform and have it do some #define magic to prefix it with sanei_ (as not to conflict with platform versions). The #define magic has issues with platforms that have getopt defined in stdio.h though and requires moving stdio.h before #include config.h... There are some things in config.h that make having any #include's before config.h a bad idea. So I have a circular logic bug I need to break. Fixes boil down to 2 options: 1) Go back to conditionally compiling getopt*.c but to do this right, I need to also rename include/getopt.h. Right now, there is no way to include platform's getopt.h because of -L../include and there are conflicting prototype issues in todays getopt.h compared to what can be linked in from platform. Pros: This approach aligns with lalloca.h, lassert.h, and _stdint.h. Cons: a) To keep CVS history, someone would need access to backend of CVS server. b) it wasn't correctly conditionally compiling before for Solaris/Darwin and I'll need to create some new configure.in logic. 2) Continue to always compile getopt*.c files and update the header file. Instead of using #define magic to add sanei_ prefixes, manually change the prototypes to include it. Thats around 5 variables and 5 functions in header to add sanei_ to and 5 #define's added to each source file. Pros: No configure support to maintain for various platforms. Cons: Its deviating alot from standard getopt* files and will be harder to port any updates. Chris
[sane-devel] problems on OS/2
Olaf Meeuwissen wrote: Based on the libtool/ltmain.sh code from the CVS snapshot (2009-02-05), I would expect CURRENT to have a value of 2 (1 on FreeBSD and SunOS). You get an empty string. The '1:1:0' version information looks fine to me. I do not see os2 listed in that general area so it looks like empty string is to be expected takign this code path. I can only guess we used to short-circuit some of this code before. Not obvious to me were that was at. Can you rerun that command with `sh -x` instead of `sh` and send the output of that. A copy of the libtool script in your source directory may be helpful as well. Yes, please. Also, another thing to try for the heck of it is ./configure --disable-shared --enable-static and see if it works in that mode. Chris Hope this helps,
[sane-devel] problems on OS/2
Can you give me a few pointers on timeframe of latest modifications? I think you mean the addition of backend/Makefile.am in last 2 weeks but want to be sure. I'm reviewing old backend/Makefile.in and old libtool that was generated. It looks like -version-number was always passed into libtool for libsane.so and that would seem should never have worked; unless maybe it used to building static libraries and is now trying to build dynamic? BTW, do you mind emailing me the config.log thats generated after running configure? I would be interested in reviewing it for clues. Chris Franz Bakan wrote: Hi, After the latest modifications with the libtool stuff I now get this error: ... Making all in backend make[1]: Entering directory `G:/src/432/sane-backends/backend' sh ../libtool --silent --tag=CC --mode=link gcc -D__EMX__ -DOS2 -D__ST_MT_ERR NO__ -fno-omit-frame-pointer -O2 -W -Wall -Wcast-align -Wcast-qual -Wmissing-dec larations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -pedantic -rpath '/usr/lib' -version-number 1:1:0 -Zexe -Zmtd -D__ST_MT_ERRNO_ _ -s -o libsane.la -rpath /usr/lib libsane_la-dll-s.lo ../lib/liblib.la libdll. la sane_strstatus.lo ../sanei/sanei_init_debug.lo ../sanei/sanei_constrain_value .lo ../sanei/sanei_config.lo ../sanei/sanei_config2.lo ../sanei/sanei_usb.lo ../ sanei/sanei_scsi.lo ../sanei/sanei_pv8630.lo ../sanei/sanei_pp.lo ../sanei/sanei _thread.lo ../sanei/sanei_lm983x.lo ../sanei/sanei_access.lo ../sanei/sanei_net .lo ../sanei/sanei_wire.lo ../sanei/sanei_codec_bin.lo ../sanei/sanei_pa4s2.lo . ./sanei/sanei_ab306.lo ../sanei/sanei_pio.lo ../sanei/sanei_tcp.lo ../sanei/sane i_udp.lo ../sanei/sanei_jpeg.lo -ldl -lm -ljpeg libtool: link: CURRENT `' must be a nonnegative integer libtool: link: `1:1:0' is not valid version information make[1]: *** [libsane.la] Fehler 1 make[1]: Leaving directory `G:/src/432/sane-backends/backend' make: *** [all-recursive] Fehler 1 What does this mean? What's CURRENT ? What's a valid version information? Franz
[sane-devel] problems on OS/2
Olaf Meeuwissen wrote: Franz Bakan fbakan at gmx.net writes: Hi, After the latest modifications with the libtool stuff I now get this error: [snip] make[1]: Entering directory `G:/src/432/sane-backends/backend' sh ../libtool --silent --tag=CC --mode=link gcc -D__EMX__ -DOS2 -D__ST_MT_ERR NO__ -fno-omit-frame-pointer -O2 -W -Wall -Wcast-align -Wcast-qual -Wmissing-dec larations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -pedantic -rpath '/usr/lib' -version-number 1:1:0 -Zexe -Zmtd -D__ST_MT_ERRNO_ _ -s -o libsane.la -rpath /usr/lib libsane_la-dll-s.lo ../lib/liblib.la libdll. la sane_strstatus.lo ../sanei/sanei_init_debug.lo ../sanei/sanei_constrain_value .lo ../sanei/sanei_config.lo ../sanei/sanei_config2.lo ../sanei/sanei_usb.lo ../ sanei/sanei_scsi.lo ../sanei/sanei_pv8630.lo ../sanei/sanei_pp.lo ../sanei/sanei _thread.lo ../sanei/sanei_lm983x.lo ../sanei/sanei_access.lo ../sanei/sanei_net .lo ../sanei/sanei_wire.lo ../sanei/sanei_codec_bin.lo ../sanei/sanei_pa4s2.lo . ./sanei/sanei_ab306.lo ../sanei/sanei_pio.lo ../sanei/sanei_tcp.lo ../sanei/sane i_udp.lo ../sanei/sanei_jpeg.lo -ldl -lm -ljpeg libtool: link: CURRENT `' must be a nonnegative integer libtool: link: `1:1:0' is not valid version information make[1]: *** [libsane.la] Fehler 1 make[1]: Leaving directory `G:/src/432/sane-backends/backend' make: *** [all-recursive] Fehler 1 What does this mean? What's CURRENT ? What's a valid version information? I've found out some interesting facts... I've arrived at why its broke but not sure I know the fix quite yet. I went back to a copy of CVS that pre-dates my automake changes. When I look at output of make, I see that -rpath /path -version-number x:x:x was never passed to linker! Wonder how long thats been broke? When I converted over to automake, I made sure the following original rule was working: libsane.la: dll.lo dll-s.lo $(EXTRA) $(addsuffix .lo,$(DLL_PRELOAD)) $(LIBOBJS) @$(LIBTOOL) $(MLINK) $(CC) -o $@ $(LDFLAGS) $(BACKENDLIBS) $^ \ $(addsuffix .lo,$(DLL_PRELOAD_EXTRAS)) @LIBTOOL_LINK_EXTRA@ \ -rpath $(libdir) -version-number $(V_MAJOR):$(V_MINOR):$(V_REV) It looks like the rule wasn't working *before* my conversion under Linux. Basically, everything starting from @LIBTOOL_LINK_EXTRA@ was not being passed to libtool. I think its because of bug in configure.in: dnl Windows/Cygwin needs this, else the library creation fails dnl BeOS also needs this (why isnt it the default anyway ???) if test $ac_cv_header_windows_h = yes -o $ac_cv_header_be_kernel_OS_h = y es ; then LIBTOOL_LINK_EXTRA=-no-undefined AC_SUBST(LIBTOOL_LINK_EXTRA) fi That AC_SUBST() should be outside the if() statement. As is, the Makefile contains literally @LIBTOOL_LINK_EXTRA@ on anything but Windows/BeOS and confuses; but doesn't crash; libtool. I noticed the bug during review and fixed it without realizing the above behaviour was occurring. Fix went into CVS along with backend/Makefile.am. Before the bugfix and on OS/2 it would not see the -rpath or -version-info flags. Now its seeing it. Theoretically, if OS/2 is building shared libraries then it should support -version-info. I don't think support shared libraries though because on other apps I've worked on everyone tells me they add -no-undefined for OS/2. I think thats affectively same as running ./configure --disable-shared --enable-static. Franz, can you try compiling as follows? If it works on OS/2 then I know how to update configure to have it always work: ./configure LDFLAGS=-no-undefined make Chris
[sane-devel] problems on OS/2
Olaf Meeuwissen wrote: Oops! I just realised that the code I was looking at was **after** `autoreconf --force --install`. The code in CVS is 11 months old and does NOT have a wildcard that would match 'os2'. The CVS version has: VERSION=1.5.22 TIMESTAMP= (1.1220.2.365 2005/12/18 22:14:06) After autoreconf, mine has: VERSION=1.5.26 Debian 1.5.26-4 TIMESTAMP= (1.1220.2.493 2008/02/01 16:58:18) On that front, yesterday I upgraded ltmain.sh to 1.5.26 (with patch) and I'm planning on submitting it today (I hope). But I *still* don't see that wildcard your talking about. Surely, its gotta be there though. If OS/2 was happy with the ltmain.sh in the SANE CVS repository, I suggest we add in a case for whatever version_type is appropriate for OS/2. May want to ping libtool upstream about this as well. Well, based on my last email, its a fluke that it was working with old ltmain.sh. I'd prefer that it worked with libtool as-is. I'm no OS/2 expert but I think OS/2 requires -no-undefined and that *may* be why current ltmain.sh will ignore the buggy options. Hopefully, an expert is lurking out there. Chris
[sane-devel] problems on OS/2
Can you update to current CVS and try again? I went ahead and added -no-undefined for OS/2 to help speed things along. I'm 99% sure its needed. As a bonus it has latest libtool which may fix an OS/2 bug or two. Chris Franz Bakan wrote: Hi, After the latest modifications with the libtool stuff I now get this error: ... Making all in backend make[1]: Entering directory `G:/src/432/sane-backends/backend' sh ../libtool --silent --tag=CC --mode=link gcc -D__EMX__ -DOS2 -D__ST_MT_ERR NO__ -fno-omit-frame-pointer -O2 -W -Wall -Wcast-align -Wcast-qual -Wmissing-dec larations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -pedantic -rpath '/usr/lib' -version-number 1:1:0 -Zexe -Zmtd -D__ST_MT_ERRNO_ _ -s -o libsane.la -rpath /usr/lib libsane_la-dll-s.lo ../lib/liblib.la libdll. la sane_strstatus.lo ../sanei/sanei_init_debug.lo ../sanei/sanei_constrain_value .lo ../sanei/sanei_config.lo ../sanei/sanei_config2.lo ../sanei/sanei_usb.lo ../ sanei/sanei_scsi.lo ../sanei/sanei_pv8630.lo ../sanei/sanei_pp.lo ../sanei/sanei _thread.lo ../sanei/sanei_lm983x.lo ../sanei/sanei_access.lo ../sanei/sanei_net .lo ../sanei/sanei_wire.lo ../sanei/sanei_codec_bin.lo ../sanei/sanei_pa4s2.lo . ./sanei/sanei_ab306.lo ../sanei/sanei_pio.lo ../sanei/sanei_tcp.lo ../sanei/sane i_udp.lo ../sanei/sanei_jpeg.lo -ldl -lm -ljpeg libtool: link: CURRENT `' must be a nonnegative integer libtool: link: `1:1:0' is not valid version information make[1]: *** [libsane.la] Fehler 1 make[1]: Leaving directory `G:/src/432/sane-backends/backend' make: *** [all-recursive] Fehler 1 What does this mean? What's CURRENT ? What's a valid version information? Franz
[sane-devel] problems on OS/2
Olaf Meeuwissen wrote: From the libtool --help --mode=link output: -no-undefined declare that a library does not refer to external symbols I fail to see how that has anything to do with the library version. To tell you the truth, I don't understand -no-undefined... but from libtool there is a comment that makes me suspect -no-undefined means static. If thats true then there is additional code in the general area of $current crash that spits out warnings that -rpath and -version-number are ignored for static. That would make OS/2 not crash then. Its pretty much a wild guess... If it doesn't solve the issue I'll continue to dig deeper. if test $allow_undefined = no; then $echo $echo *** Since this library must not contain undefined symbols, $echo *** because either the platform does not support them or $echo *** it was explicitly requested with -no-undefined, $echo *** libtool will only create a static version of it. if test $build_old_libs = no; then oldlibs=$output_objdir/$libname.$libext build_libtool_libs=module build_old_libs=yes else build_libtool_libs=no fi
[sane-devel] problems on OS/2
Julien BLACHE wrote: Chris Bagwell chris at cnpbagwell.com wrote: -rpath $(libdir) -version-number $(V_MAJOR):$(V_MINOR):$(V_REV) From my 1.0.19 build: -rpath $(libdir) -version-info $(V_MAJOR):$(V_REV):$(V_MINOR) Hmm, thats a difference between 1.0.19 and CVS... When the hard coded -ldl got fixed, probably -version-info got converted to -version-number (pre-dates automake changes anyways). I thought -version-number was correct way as well but output of libtool --help --mode=link only lists -version-info. I go research. Chris
[sane-devel] problem building sane-backends
On Fri, Feb 6, 2009 at 3:40 PM, Mihai Emanuel Dolha mihaid8 at gmail.comwrote: Hello! First of all I want to mention that I'm a new user of Sane and I don't know actually if I'm posting on the correct list. If I'm not I apologize in advance. Now for the actual problem: I need th Sane CVS for using a scanner (it's a Pixma), I downloaded sane-backends from CVS and I did: /mihai at mikedell:~/sane-backends$ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var/ This is went smooth with no problems, but when I did make I got: /mihai at mikedell:~/sane-backends$ make Making all in include make[1]: Entering directory `/home/mihai/sane-backends/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/mihai/sane-backends/include' . /bin/bash ../libtool --silent --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../include/sane -I/usr/local/include -I. -I. -I../include -I../include -DLIBDIR=/usr/lib/sane -D_REENTRANT -DPATH_SANE_CONFIG_DIR=/etc/sane.d -DPATH_SANE_DATA_DIR=/usr/share -DPATH_SANE_LOCK_DIR=/var/lock/sane -DV_MAJOR=1 -DV_MINOR=1 -g -O2 -W -Wall -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -pedantic -ansi -MT ../sanei/sanei_jpeg.lo -MD -MP -MF .deps/../sanei/sanei_jpeg.Tpo -c -o ../sanei/sanei_jpeg.lo ../sanei/sanei_jpeg.c ../sanei/sanei_jpeg.c:235: warning: ISO C forbids an empty source file *../sanei/sanei_jpeg.c:7: fatal error: opening dependency file .deps/../sanei/sanei_jpeg.Tpo: No such file or directory compilation terminated. make[1]: *** [../sanei/sanei_jpeg.lo] Error 1* make[1]: Leaving directory `/home/mihai/sane-backends/backend' make: *** [all-recursive] Error 1 /If it's relevant, I'm using Ubuntu 8.10. sane-devel-request at lists.alioth.debian.org I think I see the problem... You can either install libjpeg development package or try the following patch out. I didn't think I had libjpeg on cygwin... not sure why I'm not seeing this issue myself. RCS file: /cvsroot/sane/sane-backends/sanei/Makefile.in,v retrieving revision 1.27 diff -u -r1.27 Makefile.in --- sanei/Makefile.in 16 Jan 2009 23:39:48 - 1.27 +++ sanei/Makefile.in 6 Feb 2009 23:00:14 - @@ -53,13 +53,13 @@ sanei_net.o sanei_wire.o sanei_codec_ascii.o sanei_codec_bin.o \ sanei_scsi.o sanei_config.o sanei_config2.o sanei_pio.o sanei_pa4s2.o \ sanei_auth.o sanei_usb.o sanei_thread.o sanei_pv8630.o sanei_pp.o \ - sanei_lm983x.o sanei_access.o @SANEI_JPEG@ sanei_tcp.o sanei_udp.o + sanei_lm983x.o sanei_access.o sanei_jpeg.o sanei_tcp.o sanei_udp.o LIBSANEI_LTOBJS = sanei_ab306.lo sanei_constrain_value.lo sanei_init_debug.lo \ sanei_net.lo sanei_wire.lo sanei_codec_ascii.lo sanei_codec_bin.lo \ sanei_scsi.lo sanei_config.lo sanei_config2.lo sanei_pio.lo \ sanei_pa4s2.lo sanei_auth.lo sanei_usb.lo sanei_thread.lo \ - sanei_pv8630.lo sanei_lm983x.lo sanei_pp.lo sanei_access.lo @SANEI_JPEG_LO@ \ + sanei_pv8630.lo sanei_lm983x.lo sanei_pp.lo sanei_access.lo sanei_jpeg.lo \ sanei_tcp.lo sanei_udp.lo TARGETS = libsanei.a $(LIBSANEI_LTOBJS) -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090206/6a734331/attachment.htm
[sane-devel] problems on OS/2
Anyone with access to OS/2, please try out current CVS. I've reverted back to -version-info with libtool; same as 1.0.19. Chris
[sane-devel] problem building sane-backends
Mihai Emanuel Dolha wrote: I hope somebody will be able to help me get through this problem. Please retry current CVS and ignore my earlier patch. I've submitted a better fix. Chris
[sane-devel] problems on OS/2
Franz Bakan wrote: The way to build on OS/2 was to run configure and then replace the autogenerated libtool with a rather old version of libtool (once patched by Yuri Dario some years ago). This always worked. Can you email me the old patched libtool? Perhaps I can forward port what ever OS/2 changes to latest libtool for you. I now tried the latest CVS after Chris reverted the libtool changes. But when I now use the autogenerated libtool the 'CURRENT problem' is gone and I get further. While building I get a lot of mv -f .deps/nnn.Tpo .deps/nnn.Plo mv: .deps/nnn.Tpo: No such file or directory errors nnn is a placeholder for various filenames. Can you log the output of each failed run to me? I'd like to see the filenames that are failing to see if I can find any Makefile issues. I've heard this type of failure before for OS/2 but never understood how a second run could resolve it. If I run make again (and again) I get past these errors. Perhaps a timing issue. But the build process get's to an end without further error messages. The object files and the libs and the exe files are generated. But the shared libraries (DLLs) are missing. Can you verify that the frontends/scanimage.exe is a working program after this? Its good to know that we are generating a good executable and then we can move on to share library issues... From my limited experience, I've always heard the first thing people do is --disable-shared --enable-static on OS/2 (no DLL's)... So I suspect your patched libtool was some custom solution that allowed DLL's to be created on OS/2. BTW, I would like to see the output from make when it creates libsane.la. Hopefully, you can email it to me from above request. I want to make sure -no-undefined is there (which is required on Windows and I think OS/2 fore DLL creation to be possible). I tried the build process with sh configure --prefix=/usr. Still have to try with '--disable-shared --enable-static' As long as your getting a working scanimage.exe but without DLL's, then libtool is going to this mode on its own. Chris
[sane-devel] problems on OS/2
Franz Bakan wrote: I built again and zipped the result. you can get it here: http://www.fbakan.de/temp/Sane-OS2-Build.zip The zip-file contains the generated libtool, the main Makefile, the output from configure and make stdout (.1) and stderr (.2) and the old os2-specific-libtool, which used to work. Thanks... That helps. I'll see what changes were needed in os2-specific-libtool and see if they've been added upstream yet. The output does give us a nice warning message about why its not building the DLL's. The message isn't quite self-explanatory though so I need to research more on it. sh ../libtool --silent --tag=CC --mode=link gcc -D__EMX__ -DOS2 -D__ST_MT_ERR NO__ -fno-omit-frame-pointer -O2 -W -Wall -Wcast-align -Wcast-qual -Wmissing-dec larations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -pedantic -rpath '/usr/lib' -version-info 1:0:1 -Zexe -Zmtd -D__ST_MT_ERRNO__ -s -no-undefined -o libsane.la -rpath /usr/lib libsane_la-dll-s.lo ../lib/liblib .la libdll.la sane_strstatus.lo ../sanei/sanei_init_debug.lo ../sanei/sanei_con strain_value.lo ../sanei/sanei_config.lo ../sanei/sanei_config2.lo ../sanei/sane i_usb.lo ../sanei/sanei_scsi.lo ../sanei/sanei_pv8630.lo ../sanei/sanei_pp.lo .. /sanei/sanei_thread.lo ../sanei/sanei_lm983x.lo ../sanei/sanei_access.lo ../san ei/sanei_net.lo ../sanei/sanei_wire.lo ../sanei/sanei_codec_bin.lo ../sanei/sane i_pa4s2.lo ../sanei/sanei_ab306.lo ../sanei/sanei_pio.lo ../sanei/sanei_tcp.lo . ./sanei/sanei_udp.lo ../sanei/sanei_jpeg.lo -ldl -lm -ljpeg *** Warning: inter-library dependencies are not known to be supported. *** All declared inter-library dependencies are being dropped. *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. ... Can you verify that the frontends/scanimage.exe is a working program after this? Yes, scanimage.exe is a working program OK, good. Probably, I will try with --disable-shared --enable-static later this weekend. No need; since you've got a working scanimage.exe. It will only do same thing that is occuring now. I need to find fix for above warning message now. Chris
[sane-devel] genesys backend update
--- On Sun, 2/8/09, Pierre Willenbrock pierre at pirsoft.dnsalias.org wrote: PS1: don't try to test this on current cvs -- at least for me, it creates libsane-*.so.0.1.0, instead of libsane-*.so.1.1.0. I originally missed your PS. This appears to be related to my reverting part of the backend/Makefile.am to look like it did in 1.0.19 (to work with OS/2 again). Can't explain why libtool isn't working as expected by just browsing the makefile. I'll figure it out and submit a fix. Chris
[sane-devel] problems on OS/2
On Tue, Feb 10, 2009 at 2:45 PM, Franz Bakan fbakan at gmx.net wrote: On Thu, 05 Feb 2009 18:14:00 -0600, Chris Bagwell wrote: ... ... Also, another thing to try for the heck of it is ./configure --disable-shared --enable-static and see if it works in that mode. Finally I tried with configure with --disable-shared --enable-static This works ( I get a huge working scanimage.exe) with the autogenerated libtool after the latest backleveling with two minor issues: OK, thats good at least. Not sure if we will be able to get shared libraries working under OS/2 with current libtool. Unfortunetly, I'm driving blind trying to debug libtool without access to OS/2 myself. Mostly, I'm running in to dead ends. 1. I have to run make again and again because I get many errors mv: .deps/xxx.Tpo: No such file or directory xxx is a placeholder for various filenames. Maybe a timing issue. I don't know I think if you add --disable-dependency-tracking to your configure options that this may go away. Looks like your compiler may not correctly support the -MF option? Or a directory named .deps? Dunno exactly. 2. I have to manually add -ltiff -ljpeg -lpthread to LIBS = in frontend/Makefile There is a chance this will be fixed once I get to the point of converting frontend/Makefile to automake (soon). I'm not sure we are currently linking in *.la versions of all libraries everywhere which is required to give libtool hints to link in these external libraries on platforms that have inter-library dependency issues (OS/2, windows, etc). Chris Franz -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090210/e5102b5f/attachment.htm
[sane-devel] Canon Pixma MX300 - it may or may not be supported by SANE?
On Tue, Feb 10, 2009 at 7:25 AM, Adam PAPAI wooh at wooh.hu wrote: Hi, I've tried to install the sane-backed from the CVS repo. I followed these instructions: http://mp610.blogspot.com/2008/04/give-your-scanner-new-freshly-sane.html Everything went fine, except when I run sane-find-scanner and scanimage -L I got these outputs: To be safe, can you do ldd /path/to/your/new/scanimage and make sure that its linked to your new libsane.so that you built and not old one /usr/lib or similar? There is a bug in version # reported in current CVS that should be fixed soon. Small chance your new scanimage is still using old libsane. CVS should be fixed within the next day. Chris -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090211/f9dbf7c3/attachment.htm
[sane-devel] test backend broke
Hi all, I was converting the testsuite directory to automake but I noticed in CVS version of sane that the following basic command doesn't work. So not much for me to test right now. frontend/scanimage -d test -T lt-scanimage: scanning image of size 1x1 pixels at 8 bits/pixel lt-scanimage: acquiring gray frame, 8 bits/sample lt-scanimage: reading one scanline, 1 bytes...PASS lt-scanimage: reading one byte...FAIL Error: End of file reached Running 1.0.19 from my /usr/bin does work for same command line. Anyone know when it broke? Chris
[sane-devel] test backend broke
I think this is the interesting part of --help? Geometry: -l 0..200mm (in steps of 1) [0] Top-left x position of scan area. -t 0..200mm (in steps of 1) [0] Top-left y position of scan area. -x 0..200mm (in steps of 1) [80] Width of scan-area. -y 0..200mm (in steps of 1) [100] So the values shown as default do not seem to be used. Your information has limited the problem enough that I don't mind debugging it from here. Thanks, Chris m. allan noah wrote: with a couple week old cvs, when i run your command i get this: scanimage -d test -T scanimage: scanning image of size 157x196 pixels at 8 bits/pixel scanimage: acquiring gray frame, 8 bits/sample scanimage: reading one scanline, 157 bytes... PASS scanimage: reading one byte...PASS scanimage: stepped read, 2 bytes... PASS scanimage: stepped read, 4 bytes... PASS scanimage: stepped read, 8 bytes... PASS scanimage: stepped read, 16 bytes... PASS scanimage: stepped read, 32 bytes... PASS scanimage: stepped read, 64 bytes... PASS scanimage: stepped read, 128 bytes... PASS scanimage: stepped read, 256 bytes... PASS scanimage: stepped read, 255 bytes... PASS scanimage: stepped read, 127 bytes... PASS scanimage: stepped read, 63 bytes... PASS scanimage: stepped read, 31 bytes... PASS scanimage: stepped read, 15 bytes... PASS scanimage: stepped read, 7 bytes... PASS scanimage: stepped read, 3 bytes... PASS but if i add -x 1 -y 1, i get this: scanimage -d test -x 1 -y 1 -T scanimage: rounded value of br-x from 0.85 to 1 scanimage: rounded value of br-y from 0.85 to 1 scanimage: scanning image of size 1x1 pixels at 8 bits/pixel scanimage: acquiring gray frame, 8 bits/sample scanimage: reading one scanline, 1 bytes... PASS scanimage: reading one byte...FAIL Error: End of file reached If the image is too small (only has one scanline, etc), then scanimage -T runs out of data. It's just poorly programmed, because it is rarely used. The bigger question is why does your copy of the test backend have such a small scan area? what does 'scanimage -d test --help' show? allan On Wed, Feb 18, 2009 at 10:56 PM, Chris Bagwell chris at cnpbagwell.com wrote: Hi all, I was converting the testsuite directory to automake but I noticed in CVS version of sane that the following basic command doesn't work. So not much for me to test right now. frontend/scanimage -d test -T lt-scanimage: scanning image of size 1x1 pixels at 8 bits/pixel lt-scanimage: acquiring gray frame, 8 bits/sample lt-scanimage: reading one scanline, 1 bytes...PASS lt-scanimage: reading one byte...FAIL Error: End of file reached Running 1.0.19 from my /usr/bin does work for same command line. Anyone know when it broke? Chris -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org
[sane-devel] test backend broke
m. allan noah wrote: or they are used, but the resolution is unused? allan OK, my fault again... I failed to notice that when I converted sanei directory to automake a few days back that it stopped finding config files. :-( It will be fixed within the day. Need to add reference to $(configdir) to its makefile so that it can find the config files again. So it turns out a feature that the test backend fails to run with no config file... It will help make distcheck discover this type things in the near future. Chris
[sane-devel] Build system issues.
On Fri, Feb 20, 2009 at 12:38 PM, m. allan noah kitno455 at gmail.com wrote:
I'm not sure, but i think the build system used to overwrite all the
.so and .so.1 symlinks. It no longer does. I think this is a useful
feature, because you can tell users just to build from source and they
will be using the new version. Otherwise, they have to uninstall the
old version, and this can get hairy with novice users and helpful
package managers.
You mean during install phase, right?
When backend was converted to automake, it uses the standard automake
support to install libraries. That does install symlinks on fresh install.
I think your point is that now if a user installs, libsane.so.1.1.0 on top
of a previous libsane.so.1.0.19 install then libsane.so symlink still points
to libsane.so.1.0.19?
I've not tried above yet but seems reasonable libtool behavior to me. I'll
read up on libtool and see if they have an opinion on this.
I didn't port over the following logic from old install-be target but it
must have been doing what you said (move symlink to libsane.so.1.1.0). The
comment suggested that libtool simply wasn't working but since it was I
didn't bother porting over...
If people agree with old behavior, I can add it back. Old logic seems
dangerious if we ever have a libsane.so.2.0.0 (as apposed to
libsane2.so.0.0.0). We don't want to move libsane.so to libsane.so.2.0.0
blindly or else will break a lot of applications that were working fine.
But since we are not at that point yet, no issue to restore it. Moving
libsane.so.x to lastest version of libsane.so.x.y.z seems safe.
@# Create library links manually. Actually this is libtool's job but
it
doesn't
@# seem to work on some platforms.
@# Assume the dll name without any versions is last
@if test $(USE_LINKS) = yes ; then \
dllend=`../tools/libtool-get-dll-ext libsane-dll.la`; \
list=$(ALL_BACKENDS); cd $(DESTDIR)$(libsanedir) for be in
$$list
; do \
file=libsane-$${be}.$$dllend.$(V_MAJOR); \
lib=`grep dlname= libsane-$${be}.la | cut -f2 -d'`; \
if test ! -f $${file} -a -n $${lib}; then \
$(LN_S) $${lib} $${file}; \
fi; \
done; \
fi
Chris
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090220/d9e5d3f1/attachment.htm
[sane-devel] Build system issues.
OK, I'll add the old symlink logic back in. Chris
[sane-devel] Build system issues.
Hmmm, I was going to add it back in but I noticed 1) the old CVS code
was probably broken and 2) the old CVS code was probably doing what the
comment said and only creating symlinks for missing symlinks (I hadn't
noticed the test ! -f $${file} before). It doesn't appear to be
fixing symlinks in the way described.
I'll see if libtool upgrade caused a change in behaviour next or if the
behaviour pre-dates automake/libtool updates.
In case your interested in why old code was broke: Some key logic it
uses, I ran by hand and it returns:
../tools/libtool-get-dll-ext libsane-dll.la
so
If I use epson as an example backend then above results in:
file=libsane-epson.so.1
grep dlname= libsane-epson.la | cut -f2 -d
libsane-epson.so.1
lib=libsane-epson.so.1
and finally it will use above values:
ln -s libsane-epson.so.1 libsane-espon.so.1
Not very useful.
Chris
@# Create library links manually. Actually this is libtool's job but
it
doesn't
@# seem to work on some platforms.
@# Assume the dll name without any versions is last
@if test $(USE_LINKS) = yes ; then \
dllend=`../tools/libtool-get-
dll-ext libsane-dll.la`; \
list=$(ALL_BACKENDS); cd $(DESTDIR)$(libsanedir) for be in
$$list
; do \
file=libsane-$${be}.$$dllend.$(V_MAJOR); \
lib=`grep dlname= libsane-$${be}.la | cut -f2 -d'`; \
if test ! -f $${file} -a -n $${lib}; then \
$(LN_S) $${lib} $${file}; \
fi; \
done; \
fi
Chris
[sane-devel] Build system issues.
m. allan noah wrote:
On Fri, Feb 20, 2009 at 3:08 PM, Chris Bagwell chris at cnpbagwell.com
wrote:
When backend was converted to automake, it uses the standard automake
support to install libraries. That does install symlinks on fresh install.
I think your point is that now if a user installs, libsane.so.1.1.0 on top
of a previous libsane.so.1.0.19 install then libsane.so symlink still points
to libsane.so.1.0.19?
it's not just that it leaves the links behind, it actually makes the
links to 1.0.19, even when 1.1.0 is also installed.
I've not tried above yet but seems reasonable libtool behavior to me. I'll
read up on libtool and see if they have an opinion on this.
Couldn't find any documentation related to what libtool behaviour should
be in tihs area.
I just now installed sane 1.0.19 tarball into a private directory and
then installed current CVS on top of it. The behaviour I got seems to
be the behaviour you want. In the end, all symlinks were updated and
pointed to latest so. I had the following in ${prefix}/lib and other
backends followed same behaviour.
libsane.la
libsane.so - libsane.so.1.1.0
libsane.so.1 - libsane.so.1.1.0
libsane.so.1.0.19
libsane.so.1.1.0
Let me know if you continue to see different behaviour and we can
continue to debug it.
Also, this means I won't be porting over the Makefile symlink logic I
previously mentioned since it was broke and current libtool seems to be
OK on all platforms I tested.
Chris
[sane-devel] Build system issues.
Chris Bagwell wrote:
Couldn't find any documentation related to what libtool behaviour
should be in tihs area.
I just now installed sane 1.0.19 tarball into a private directory and
then installed current CVS on top of it. The behaviour I got seems to
be the behaviour you want. In the end, all symlinks were updated and
pointed to latest so. I had the following in ${prefix}/lib and other
backends followed same behaviour.
libsane.la
libsane.so - libsane.so.1.1.0
libsane.so.1 - libsane.so.1.1.0
libsane.so.1.0.19
libsane.so.1.1.0
Let me know if you continue to see different behaviour and we can
continue to debug it.
Also, this means I won't be porting over the Makefile symlink logic I
previously mentioned since it was broke and current libtool seems to
be OK on all platforms I tested.
Hmm, I did notice one interesting thing. I went ahead and re-installed
sane-1.0.19 back on top of the pre-existing private directory that had
both 1.0.19 and 1.1.0-cvs installed.
sane-1.0.19's libtool did overwrite all symlinks (based on timestamps)
but chose different values at different levels.
libsane.so - libsane.so.1.0.19
libsane.so.1 - libsane.so.1.1.0
libsane.so.1.0.19
libsane.so.1.1.0
Re-installing CVS points *everything* back to 1.1.0 so. Its hard to
tell if 1.0.19 behaviour was a bug in libtool or if there is some rule
that *.so should point to last installed while *.so.x should always
point to highest installed version.
Anyways, current CVS seems to be doing as expected since it has highest
so version released yet.
Chris
[sane-devel] Build system issues.
m. allan noah wrote: On Sun, Feb 22, 2009 at 2:16 PM, Chris Bagwell chris at cnpbagwell.com wrote: Re-installing CVS points *everything* back to 1.1.0 so. Yes- i can confirm that it works as expected on top of a vendor-packaged 1.0.19, except for one problem: /usr/lib/sane/libsane.so.1 - libsane-xerox_mfp.so.1.1.0 Looks like we picked up the last backend and made an extra symlink for it? I have installed fedora 10's rpm too, so perhaps that made the symlink as well? Hmmm, thats back? It was a feature of sane-1.0.19's libtool as well but the backend/Makefile would specifically delete it at end of install phase so it wasn't noticed. :-) After upgrading ltmain.sh I hadn't noticed it being created anymore but I guess something must be tickling it. Yesterday, I almost submitted that cleanup logic back into backend/Makfile to be safe but reverted it at the last minute. I'll go ahead and add it back since it hurts nothing to have it there. Oh, and the neat/screwy thing about this approach- I built from source without v4l support, but the existing 1.0.19 rpm had it, so now i get updated 1.1.0 backends, and the older v4l at the same time. Yep, nice feature I think since they are backwards compatible. I was seeing similar. allan
[sane-devel] [sane-commit] CVS update of sane-backends (37 files)
On Wed, Feb 25, 2009 at 11:08 PM, stef stef.dev at free.fr wrote: Hello, I would have preferred to ear of that change before. It comes at a wrong time since I'm doing and testing a non-trivial merge in the genesys backend. I didn't see any warning of such a global change. Did I miss an email ? Sorry about that... I bounced the idea off a few people but didn't submit to mailing list before I did it. I think running the following commands should allow you to recover relatively easy (also its the easy way to revert my commit if it comes to it). Run them should cause most the cvs update to say changes are already applied. Or at least it can be used to update your genesys files and let you drop into a new copy of CVS to skip update step. sed -i 's/u_int8_t/uint8_t/g' *.[ch] sed -i 's/u_int16_t/uint16_t/g' *.[ch] sed -i 's/u_int32_t/uint32_t/g' *.[ch] However the 'right' type to use is an interesting point, I've never been really convinced with the mix of SANE_Int, int and u_int16 variables. I'll not speak for SANE_Int as it may have a special purpose. For the rest, I usually don't mind to support a range of types that people are comfortable with. Its just the u_int*_t are a BSD-ism and have portability issues; whereas uint*_t are now defined by C standard and should be easier to port (although stdint.h does have a suprisingly large amount of baggage itself). I purposely left in the u_char_t, u_int_t, and u_long_t since they are not defined by same standard and do not have same portability issues for what ever reasons. Chris -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090226/690f5161/attachment.htm
[sane-devel] Build system issues.
m. allan noah wrote:
Actually chris asked for this previously, but it looks correct:
/bin/sh ../libtool --mode=install /usr/bin/install -c
'libsane-fujitsu.la' '/usr/lib/sane/libsane-fujitsu.la'
/usr/bin/install -c .libs/libsane-fujitsu.so.1.1.0
/usr/lib/sane/libsane-fujitsu.so.1.1.0
(cd /usr/lib/sane { ln -s -f libsane-fujitsu.so.1.1.0
libsane-fujitsu.so.1 || { rm -f libsane-fujitsu.so.1 ln -s
libsane-fujitsu.so.1.1.0 libsane-fujitsu.so.1; }; })
(cd /usr/lib/sane { ln -s -f libsane-fujitsu.so.1.1.0
libsane-fujitsu.so || { rm -f libsane-fujitsu.so ln -s
libsane-fujitsu.so.1.1.0 libsane-fujitsu.so; }; })
/usr/bin/install -c .libs/libsane-fujitsu.lai /usr/lib/sane/libsane-fujitsu.la
PATH=$PATH:/sbin ldconfig -n /usr/lib/sane
Now here's the crazy thing, if i go and run those commands directly,
they work properly, and both links are updated.
allan
And just to be sure; did you also run the ldconfig -n /usr/lib/sane
step to verify its not ldconfig doing the wrong thing?
I'm trying to find out more how it works but man page mentions looking
at header and filenames to know which versions should have their
symlinks updated. Not sure what header their talking about and if we
have something mislabelled in it.
Since we are playing the libtool games with soname as libsane instead
of libsane-fujitsu, I could envision some tools getting confused by
that. But I'm not up to speed yet on how that works.
Chris
[sane-devel] Build system issues.
m. allan noah wrote: On Thu, Feb 26, 2009 at 9:46 PM, Chris Bagwell chris at cnpbagwell.com wrote: And just to be sure; did you also run the ldconfig -n /usr/lib/sane step to verify its not ldconfig doing the wrong thing? now i did, and yes- that is the culprit. Hmmm, seems maybe its always been this way? Although on my system, I'm not seeing it. I think I at least now know where that mystery symlink of last backend comes from: /usr/lib/sane/libsane.so.1 - libsane-xerox_mfp.so.1.1.0 I see references on the net that ldconfig purposely does not update linker symlink (/usr/lib/sane/libsane-backend.so) if it already exists but that the soname (/usr/lib/sane/libsane.so.1 because of patched libtool) is updated to latest version of realname (/usr/lib/sane/libsane-backend.so.1.1.0 in CVS case) always. That correctly describes above symlink But your system seems to be not obeying the first part and updating the linker name to a realname that also has a matching soname. My system doesn't seem to be doing that for some reason (Fedora 10). Here is an idea to explore... Is there any change your RPM package is replacing ltmain.sh or libtool when it was compiled? I could see how ldconfig might behavior like your seeing if 1.0.19 backends were installed with soname's of the form libsane-backend.so.1 but your 1.1.0 backends were installed with soname's of the form libsane.so.1. Chris
[sane-devel] Build system issues.
Olaf Meeuwissen wrote:
m. allan noah kitno455 at gmail.com writes:
now i did, and yes- that is the culprit.
One should *not* run ldconfig on the directory holding the backends,
ie ${sanelibdir}. Frontends should link against libsane which is in
${libdir}. If one absolutely insists on running ldconfig it should be
run on ${libdir}.
IIRC, Mandrake (before it became Mandriva) and Turbolinux had bugs in
their %postinst sections that ran ldconfig on ${sanelibdir} and broke
their SANE installations.
Hope this helps,
Hmm, I'll have to look into this concept. Looks like we've always been
calling libtool with the --finish option at the end (1.0.19 anyways)
which will call ldconfig on $(prefix)/lib/sane.
It is probably what we want but it will be a change.
Also, now we are relying on automake's lib install rules which is hard
for me to change its behavior. Whats strange is searching in the
auto-generated backend/Makefile, I can't find any references to finish
so I'm not sure how its being invoked right now; but obviously it is.
Chris
[sane-devel] Build system issues.
On Thu, Feb 26, 2009 at 10:07 PM, m. allan noah kitno455 at gmail.com wrote: On Thu, Feb 26, 2009 at 11:00 PM, Chris Bagwell chris at cnpbagwell.com wrote: m. allan noah wrote: On Thu, Feb 26, 2009 at 9:46 PM, Chris Bagwell chris at cnpbagwell.com wrote: Here is an idea to explore... Is there any change your RPM package is replacing ltmain.sh or libtool when it was compiled? I could see how ldconfig might behavior like your seeing if 1.0.19 backends were installed with soname's of the form libsane-backend.so.1 but your 1.1.0 backends were installed with soname's of the form libsane.so.1. Its not 'my' rpm- it is the distro's rpm, which happens to be: Fedora 10, tada! Now you can test it too :) Yep, that appears to be the issue... at least at first glance. This line is in Fedora 10's spec file: # We patched configure.in, so regenerate configure. autoreconf --install --force They should remove that --force option so as not to overwrite our patched ltmain.sh. So using Fedora RPM's and then installing on top with source package will have the unwanted behavior you are seeing. I'll bugzilla that when I have a moment. Chris -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090228/d530d0dd/attachment.htm
[sane-devel] build system issue installing config files
On Sat, Feb 28, 2009 at 3:41 PM, Louis Lagendijk
louis at lagendijk.xs4all.nlwrote:
hi
In order to better keep track of what I installed, I am trying to build
an RPM package for Sane on my Fedora 10 box.
This fails as the config files do not get installed. This seems to be
caused by the install-becfg target in backend/Makefile.am
`/home/home1/louis/rpm/BUILD/sane-backends-1.1.0.cvs/backend'
rm
-f
/home/home1/louis/rpm/BUILDROOT/sane-backends-1.1.0.cvs-12.fc10.x86_64/usr/lib64/sane/libsane.*
test -z /etc/sane.d || /bin/mkdir -p /etc/sane.d
test -z /etc/sane.d/dll.d || /bin/mkdir -p /etc/sane.d/dll.d
NOT overwriting abaton.conf in /etc/sane.d...
NOT overwriting agfafocus.conf in /etc/sane.d...
NOT overwriting apple.conf in /etc/sane.d...
I have no idea where to look for the cause. Or am I missing something
obvious? In the makefile I see that the install-becfg is triggered by
install-dat-hook, which in its turn is called by install-data-am which
does $(MAKE) $(AM_MAKEFLAGS) install-data-hook. So is DESTDIR missing
from AM_MAKEFLAGS? I am afraid I do not know enough of autoconf to
understand all logic involved. Suggestions?
Hmmm, I've not had time to work on Fedora's spec file but it will need some
changes to work with at least this automake change. The recommended
practice is for the spec file to pass in the value of DESTDIR; its not
sane-backends that sets it. If Fedora spec would have done that then we'd
have been OK.
In their spec file look for:
%{makeinstall} docdir=%{buildroot}/%{_docdir}/%{name}-%{version}
replace that with more recommend practice of:
make DESTDIR=%{buildroo} docdir=%{buildroot}/%{_docdir}/%{name}-%{version}
install
If that gives you problems, then try the following:
%{makeinstall} configdir=%{docdir=%{buildroot}/%{_docdir}/%{name}-%{version}
configdir=%{buildroot}/etc/sane.d
As a side-note: RPM barfs when a package name has more than one dash in
it. Would it be possible to change the package version in configure.in
so it does not contain a dash, e.g. to 1.1.0cvs?
Yep, I run into the same issue. I tend to modify configure.in though and
change version # to 1.0.99 (and remove the -cvs) so that if/when Fedora
upgrades their RPM's, my custom RPM will not look newer.
Not sure if others on list feel its OK to remove the dash from -cvs to
help RPM people out in general though?
Chris
thanks in advance for the help
Louis/insta
--
sane-devel mailing list: sane-devel at lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject unsubscribe your_password
to sane-devel-request at lists.alioth.debian.org
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090228/2e1511d9/attachment-0001.htm
[sane-devel] broken sane-config in sane-backends version 1.1.0
Olaf Meeuwissen wrote: szukw000 at arcor.de writes: I had to make some changes to get a working 'sane-config'. The result: LIBS= -lgphoto2 -lgphoto2_port -lexif -lm -lusb -ldl @GPHOTO2_LDFLAGS@ is empty I do not know whether this is sufficient. sane-backends-1.0.19 has a longer list for LIBS: LIBS=-lusb -lpthread -lm -ljpeg -ltiff -lieee1284 -lgphoto2 -lgphoto2_port -lexif -lm -lusb -ldl OK, thanks for report... I submitted a version of your patches and now I get basically same as 1.0.19: LIBS= -ldl -lv4l1 -lv4l2 -lv4lconvert -lm -ltiff -ljpeg -lgphoto2 -lgphoto2_port -lexif -lm -lusb -lusb TODO: We should really strip out duplicates libraries... TODO2: I don't think that LIBS in most systems should really contain *ANY* values because libsane.so is just libsane-dll.so and doesn't contain any code that requires linking to that stuff. When you dlopen a backend, it also loads its dependencies that were linked into it as needed, right? In that case, sane-config's LIBS should be built based on only whats in PRELOAD_BACKENDS (normally nothing). Chris
[sane-devel] Segmentation Fault
2009/3/3 Russell King rjkfsm at gmail.com Well, I tried that and xsane now complains that it needs sane-backends 1.0.0 or higher. To get here, I had to unmerge sane-backends, sane-frontends and xsane, then to keep portage from bashing them, I masked them. I then downloaded the source for sane-backends and compiled it. That went fine and when I tried the same with xsane, I get: ERROR: SANE-1.0.0 or newer is needed for compiling xsane - if you installed SANE as rpm make sure you also included sane-devel I just did some limited testing with current CVS and xsane- 0.996 and had success. Note: I found an additional typo in sane-config and just submitted a fix to CVS. You'll want to update again. Your error message above is because xsane can not find the sane-config of your CVS sane-backends. Step I did are similar to following: cd sane-backend ./configure --prefix=/usr/local/sane make; make install export PATH=/usr/local/sane/bin:$PATH cd /path/to/src/xsane-0.996 cd src vi xsane-backend-gtk.c comment out all of if(SANE_CAPS_ALWAYS_SETTABLE) at lines 2615-2618 as its not documented by SANE1 API and not in current CVS... It was in sane-1.0.19 for what ever reasons but only used by qcam and v4l backends. I'm sure you'll not notice reduced functionality. cd .. ./configure --prefix=/usr/local/xsane LDFLAGS=-L/usr/local/sane/lib CPPFLAGS=-I/usr/local/sane/include make; make install /usr/local/xsane/bin/xsane -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090303/c081e1d2/attachment.htm
[sane-devel] Error during compile
[scratching my head] Hmmm, how'd that obvious issue not show up on my system? I've just committed to CVS a fix to stop looking at the template files when generating the HTML pages. Can you update and try again? Chris carterbueford at gmx.net wrote: Hi everybody, I get the following error during compiling the cvs-snapshot: Generating manpage scanimage.1... Generating manpage sane-config.1... Generating manpage sane-find-scanner.1... Generating manpage gamma4scanimage.1... Generating manpage sane.7... Generating manpage saned.8... make[1]: *** No rule to make target `descriptions/template.desc.', needed by `sane-backends.html'. Stop. make[1]: Leaving directory `/opt/saned/sane-backends/doc' make: *** [all-recursive] Error 1 Any idea what is meant by that?? Thank Oliver
[sane-devel] Mac OS X: configure script errors
Yes, I've seen similar issues in all autotools projects. I've seen it most on Mac's as well (don't know if its limited to just that platform though)... The configure scripts don't seem to cope well with spaces in directory names. Not much can be done about this short of fixing the autotools. Chris On Tue, Mar 24, 2009 at 10:58 AM, Peter Schoenrank peter at schoenrank.cawrote: I am using Mac OS X 10.5.6 on an Intel iMac. When I do $ mkdir ~/Desktop/scanning\ from\ the\ command\ line $ cd ~/Desktop/scanning\ from\ the\ command\ line $ curl 'http://alioth.debian.org/snapshots.php?group_id=30186' sane- scm-latest.tar.gz $ open sane-scm-latest.tar.gz $ cd sane-scm-2009-03-24/sane-backends $ export BACKENDS=pixma canon $ ./configure --build=x86-apple-osx I get checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes /bin/sh: /Users/cps/Desktop/scanning: No such file or directory configure: WARNING: `missing' script is too old or missing It would seem that some part of configure is not coping with ~/Desktop/scanning\ from\ the\ command\ line having spaces in its name. Peter - Peter Schoenrank mailto: peter at schoenrank.ca phone: 250-655-6753 -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090324/7ced72ed/attachment.htm
[sane-devel] Mac OS X: Report this ...
Based on your config.log from other email, its failing during check with this error message: configure:17246: checking IOKit/scsi/SCSITaskLib.h usability configure:17263: gcc -c -g -O2 -W -Wall -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -pedantic -ansi -D_REENTRANT conftest.c 5 In file included from /System/Library/Frameworks/IOKit.framework/Headers/scsi/SCSITaskLib.h:29, from conftest.c:136: /System/Library/Frameworks/IOKit.framework/Headers/scsi/SCSICmds_INQUIRY_Definitions.h:70: error: syntax error before string constant /System/Library/Frameworks/IOKit.framework/Headers/scsi/SCSICmds_INQUIRY_Definitions.h:80: error: syntax error before '}' token /System/Library/Frameworks/IOKit.framework/Headers/scsi/SCSICmds_INQUIRY_Definitions.h:81: error: syntax error before '*' token /System/Library/Frameworks/IOKit.framework/Headers/scsi/SCSICmds_INQUIRY_Definitions.h:91: error: syntax error before string constant /System/Library/Frameworks/IOKit.framework/Headers/scsi/SCSICmds_INQUIRY_Definitions.h:109: error: syntax error before '}' token In file included from conftest.c:136: /System/Library/Frameworks/IOKit.framework/Headers/scsi/SCSITaskLib.h:594: error: syntax error before 'SCSICmd_INQUIRY_StandardData' configure:17270: $? = 1 So it looks like that header file is not self-supporting. Don't know what else needs to be included first to get rid of failure. I have only occasional access to a Mac and developer docs so can't easily debug. For the most part, this message can be ignored though since its a warning. Chris On Tue, Mar 24, 2009 at 11:07 AM, Peter Schoenrank peter at schoenrank.cawrote: I am using Mac OS X 10.5.6 on an Intel iMac When I run the configure script, I get . . . configure: WARNING: IOKit/scsi/SCSITaskLib.h: present but cannot be compiled configure: WARNING: IOKit/scsi/SCSITaskLib.h: check for missing prerequisite headers? configure: WARNING: IOKit/scsi/SCSITaskLib.h: see the Autoconf documentation configure: WARNING: IOKit/scsi/SCSITaskLib.h: section Present But Cannot Be Compiled configure: WARNING: IOKit/scsi/SCSITaskLib.h: proceeding with the preprocessor's result configure: WARNING: IOKit/scsi/SCSITaskLib.h: in the future, the compiler will take precedence configure: WARNING: ## - ## configure: WARNING: ## Report this to sane-devel at lists.alioth.debian.org ## configure: WARNING: ## - ## . . . Peter - Peter Schoenrank mailto: peter at schoenrank.ca phone: 250-655-6753 -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090324/fd537459/attachment-0001.htm
[sane-devel] Mac OS X: make errors
OK, I have to stick with build issue myself... Sorry, can't help with USB issues. I have only 1 addition suggestion. Try running configure with --prefix=/usr/local/testsane to have it installed in a custom location. I've not fully followed in the other threads if you've ever install a previous copy of sane into the prefix /usr/local... but perhaps libsane is loading some older version of your backend that has these USB issues. Anyways, the --prefix idea can only help I think... but likely is not your issue. Chris On Tue, Mar 24, 2009 at 4:24 PM, Peter Schoenrank peter at schoenrank.cawrote: On 09-Mar-24, at 11:22, Chris Bagwell wrote: This still results in the warnings about IOKit/scsi/SCSITaskLib.h that I previously posted, but as Chris suggested, I ignored those because my scanner is USB not SCSI. $ make check makecheck.log $ make make.log $ sudo make install makeinstall.log $ sane-find-scanner sane-find-scanner.log found USB scanner (vendor=0x04a9 [Canon], product=0x172c [MX850 series]) at libusb:007:002-04a9-172c-00-00 $ scanimage -L scanimage-L.log device `pixma:04A9172C_21B0DA' is a CANON Canon PIXMA MX850 multi-function peripheral $ export SANE_DEBUG_SANEI_USB=255 $ export SANE_DEBUG=255 $ export SANE_DEBUG_PIXMA=20 $ scanimage -d pixma:04A9172C_21B0DA -T scanimage.log And now I am back to where I was on Saturday: scanimage hangs. For those who care, config.log configure.log makecheck.log make.log makeinstall.log sane-find-scanner.log scanimage-L.log scanimage.log are available at http://members.shaw.ca/schoenrank.ca/sane-scm-2009-03-24.2/ Peter - Peter Schoenrank mailto: peter at schoenrank.ca phone: 250-655-6753 -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090324/59b136b4/attachment.htm
[sane-devel] New build system: make dist fails
Technically, there is no failure listed below. It looks as if it
created the tar.gz file just fine. Those are just warning messages from
the java compiler.
But I see now that the way I did the makefiles that
backend/dll-preload.h gets needlessly created during make dist and
that the java class files get compiled; also needlessly.
The first item is probably not worth fixing but the second item is a
must fix since not everyone that may wish to run make dist will have
java compiler installed. I'll fix that asap.
On the topic of totally dropping japi, I can only provide one cent...
The pre-automake makefiles weren't able to compile on my box originally
so probably not many (anyone?) was really using it for a while. I had
to make a few trivial changes to specify classpath paths to get them to
work.
I also wasn't able to really test that the java apps were even working.
I could run them and see it was correctly initializing sane backend but
then it would error out and quit. Ultimately I couldn't figure out how
to make it use the test backend and I didn't have a real scanner set
up at the time.
Chris
m. allan noah wrote:
is it time to dump japi? comments anyone?
allan
On Sat, Feb 28, 2009 at 11:55 AM, Louis Lagendijk
louis at lagendijk.xs4all.nl wrote:
hi
Running a make dist on a freshly configured CVS tree bugs out with the
following:
bash-3.2$ make dist
{ test ! -d sane-backends-1.1.0-cvs || { find sane-backends-1.1.0-cvs
-type d ! -perm -200 -exec chmod u+w {} ';' rm -fr
sane-backends-1.1.0-cvs; }; }
test -d sane-backends-1.1.0-cvs || mkdir sane-backends-1.1.0-cvs
list='include lib sanei backend frontend tools doc po japi testsuite';
for subdir in $list; do \
if test $subdir = .; then :; else \
test -d sane-backends-1.1.0-cvs/$subdir \
|| /bin/mkdir -p sane-backends-1.1.0-cvs/$subdir \
|| exit 1; \
distdir=`CDPATH=${ZSH_VERSION+.}: cd sane-backends-1.1.0-cvs
pwd`; \
top_distdir=`CDPATH=${ZSH_VERSION+.}: cd
sane-backends-1.1.0-cvs pwd`; \
(cd $subdir \
make \
top_distdir=$top_distdir \
distdir=$distdir/$subdir \
am__remove_distdir=: \
am__skip_length_check=: \
distdir) \
|| exit 1; \
fi; \
done
make[1]: Entering directory
`/home/home1/louis/bjnp/sane-backends/include'
make[1]: Leaving directory
`/home/home1/louis/bjnp/sane-backends/include'
make[1]: Entering directory `/home/home1/louis/bjnp/sane-backends/lib'
make[1]: Leaving directory `/home/home1/louis/bjnp/sane-backends/lib'
make[1]: Entering directory `/home/home1/louis/bjnp/sane-backends/sanei'
make[1]: Leaving directory `/home/home1/louis/bjnp/sane-backends/sanei'
make[1]: Entering directory
`/home/home1/louis/bjnp/sane-backends/backend'
make[1]: Leaving directory
`/home/home1/louis/bjnp/sane-backends/backend'
make[1]: Entering directory
`/home/home1/louis/bjnp/sane-backends/frontend'
make[1]: Leaving directory
`/home/home1/louis/bjnp/sane-backends/frontend'
make[1]: Entering directory `/home/home1/louis/bjnp/sane-backends/tools'
make[1]: Leaving directory `/home/home1/louis/bjnp/sane-backends/tools'
make[1]: Entering directory `/home/home1/louis/bjnp/sane-backends/doc'
make[1]: Leaving directory `/home/home1/louis/bjnp/sane-backends/doc'
make[1]: Entering directory `/home/home1/louis/bjnp/sane-backends/po'
make[1]: Leaving directory `/home/home1/louis/bjnp/sane-backends/po'
make[1]: Entering directory `/home/home1/louis/bjnp/sane-backends/japi'
. javac -d .SaneDevice.java SaneOption.java SaneRange.java Sane.java
SaneParameters.java ScanIt.java ImageCanvas.java ImageCanvasClient.java
Test.java Jscanimage.java
--
1. WARNING in ImageCanvas.java (at line 57)
public class ImageCanvas extends Canvas
^^^
The serializable class ImageCanvas does not declare a static final
serialVersionUID field of type long
--
--
2. WARNING in Jscanimage.java (at line 50)
import java.awt.image.ImageConsumer;
The import java.awt.image.ImageConsumer is never used
--
3. WARNING in Jscanimage.java (at line 51)
import java.awt.image.ColorModel;
^
The import java.awt.image.ColorModel is never used
--
4. WARNING in Jscanimage.java (at line 63)
public class Jscanimage extends Frame implements WindowListener,
^^
The serializable class Jscanimage does not declare a static final
serialVersionUID field of type long
--
5. WARNING in Jscanimage.java (at line 103)
prog.show();
^^^
The method show() from the type Window is deprecated
--
6. WARNING in Jscanimage.java (at line 591)
dlg.show(); // Wait for result.
[sane-devel] sane-backends now in feature freeze
On Sun, Apr 19, 2009 at 2:49 PM, m. allan noah kitno455 at gmail.com wrote: It would also be helpful if folks could attempt to build the current sources on any uncommon platforms they have access to, so we can shake out any build system or compiler issues. FYI: I compiled latest CVS successfully with Fedora 11 (beta), Solaris 10+gcc, Cygwin, and Mac OSX (no libusb). Testing was limited to cd testsuite; make test.local. Chris -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090419/74800347/attachment.htm
[sane-devel] compile sane snapshot under Freebsd 7.1
I'm very glad to hear someone was able to test under FreeBSD. Thats the
main platform I do not have access to. Really need to set up a qemu
image some day.
Replies below.
On 05/02/2009 11:14 AM, m. allan noah wrote:
On Sat, May 2, 2009 at 11:49 AM, Louis Lagendijk
louis at lagendijk.xs4all.nl wrote:
- libgphoto2 is not found, solved it temporarily by adding
${GPHOTO2_LDFLAGS} to the end of the GPHOTO2_LIBS line. I know this is
an ugly hack
Maybe Chris can chime in on that one?
Agree its an issue. Got a working patch I'll submit. Also, need a
related update to sane-config.in. I'll test a little more and submit
tomorrow.
canon_dr.c picks the wrong saneopts.h (from /usr/local/sane). possibly
other sources do the same, but I for now simply removed the old sane
includes
most backends seem to include the system sane files instead of the src
ones. perhaps we should change that at some point?
I didn't worry about this because I assumed our -I options should always
force it to look for internal versions first.
AM_CPPFLAGS = -I. -I$(srcdir) -I$(top_builddir)/include
-I$(top_srcdir)/include -DLIBDIR=$(libdir)/sane
Somehow your still getting -I/usr/local/include with higher priority.
How was that specified? ./configure CPPFLAGS=-I/usr/local/include?
Can you look at what command line options are being used to compile?
You will need to edit backend/Makefile and remove the --silent from
$LIBTOOL.
tools/sane-find-scanner: -lcam missing (added a ${SCSI_LIB} to the LD
line
ok. Chris? :)
Agree its missing. I'll submit patch by tomorrow.
Chris
Please let me know if more information is needed
Louis
p.s. the pixma stuff works in first very quick test
allan
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090502/8a99125a/attachment.htm
[sane-devel] sane-backends 1.0.20 Released
On Mon, May 4, 2009 at 9:03 AM, Julien BLACHE jb at jblache.org wrote: Chris Bagwell chris at cnpbagwell.com wrote: Hi Chris, Are you referring to sane-backends? I can't find a --enable-pthreads option. Also, I tried for the first time the --enable-fork-process option but still had no compile issues. Yes, that's sane-backends and the option is actually --disable-fork-process (which does exactly what --enable-pthreads would do if it existed ;)) It switches sanei_thread from using fork() to using pthreads for reader processes. Ah, thats the part I was missing and can now reproduce. Some of that double negative logic in acinclude.m4 was confusing me and I thought my test on Darwin would have fully tested it. I can have a fix ASAP although I guess I'll need to hold off on submitting until git is ready. BTW, temporary work around for those that need it: ./configure --disable-fork-process LDFLAGS=-lpthread Chris -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090504/d66c8a8a/attachment.htm
[sane-devel] compile sane snapshot under Freebsd 7.1
On Mon, May 4, 2009 at 2:22 PM, Louis Lagendijk louis at lagendijk.xs4all.nlwrote: On Sat, 2009-05-02 at 15:59 -0500, Chris Bagwell wrote: canon_dr.c picks the wrong saneopts.h (from /usr/local/sane). possibly other sources do the same, but I for now simply removed the old sane includes most backends seem to include the system sane files instead of the src ones. perhaps we should change that at some point? I didn't worry about this because I assumed our -I options should always force it to look for internal versions first. AM_CPPFLAGS = -I. -I$(srcdir) -I$(top_builddir)/include -I $(top_srcdir)/include -DLIBDIR=$(libdir)/sane Somehow your still getting -I/usr/local/include with higher priority. How was that specified? ./configure CPPFLAGS=-I/usr/local/include? Can you look at what command line options are being used to compile? You will need to edit backend/Makefile and remove the --silent from $LIBTOOL. Generating umax1220u.conf from umax1220u.conf.in Generating umax.conf from umax.conf.in Generating umax_pp.conf from umax_pp.conf.in Generating v4l.conf from v4l.conf.in Generating xerox_mfp.conf from xerox_mfp.conf.in Generating dll.conf from dll.conf.in Generating saned.conf from saned.conf.in gmake all-am gmake[1]: Entering directory `/usr/ports/graphics/sane-backends/sane-backends/backend' rm -f dll-s.c ln -s ./stubs.c dll-s.c /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../include/sane -I/usr/local/include -I. -I. -I../include -I../include -DLIBDIR=/usr/local/lib/sane -DBACKEND_NAME=dll -D_REENTRANT -DPATH_SANE_CONFIG_DIR=/usr/local/etc/sane.d -DPATH_SANE_DATA_DIR=/usr/local/share -DPATH_SANE_LOCK_DIR=/usr/local/var/lock/sane -DV_MAJOR=1 -DV_MINOR=1 -g -O2 -W -Wall -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -pedantic -ansi -MT libsane_la-dll-s.lo -MD -MP -MF .deps/libsane_la-dll-s.Tpo -c -o libsane_la-dll-s.lo `test -f 'dll-s.c' || echo './'`dll-s.c mkdir .libs The above confirms we are setting up -I options correctly. I believe I see the issue now... We have 3 versions of including saneopts.h in various files. #include sane/getopts.h #include sane/getopts.h #include ../include/sane/getopts.h I had trouble finding an official definition of difference between and but I finally found in GNU's cpp manual that means look in -I places and then standard system header places as a fall back. It then says that looks in current directory but falls back to standard system header places. It makes no mention of referencing -I values. So that seems the issue. We need to get rid of all #include sane/getopts.h and also better to align with just 1 way to do it such as also getting rid of all #include sane/getopts.h as well. I can align this soon if someone else doesn't want to take that up themselves. -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090504/39b78925/attachment-0001.htm
[sane-devel] Git repositories are up
On Mon, May 4, 2009 at 12:02 PM, Julien BLACHE jb at jblache.org wrote: Hi, The git repositories for SANE are up and running on alioth. Just had to make a submission to have an excuse to try git for the first time. So far I'm really liking all those commands you can do without having to contact the server. Perhaps an additional set of tips for us first timers trying to simulate cvs operations. It may save you a few minutes of searching. - git pull is like cvs update. - The two step operation of git commit -a followed by git push is similar to cvs commit. - Seems the standard protocol for commit messages is: [ one line summary of change ] [ empty line ] [ multi-line description of change if required. ] And a few possible issue that I'm sure your aware of Julien. - I didn't receive a commit email. Could be mail server not sending to sender. - I went to sane-commit archive on web page to see if it was sent. The archive is shown as empty. - Sane webpage still points to cvs on download page. Chris -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090504/b279d712/attachment.htm
[sane-devel] sane-backends 1.0.20 Released
On Mon, May 4, 2009 at 10:06 AM, m. allan noah kitno455 at gmail.com wrote: On Mon, May 4, 2009 at 11:03 AM, Julien BLACHE jb at jblache.org wrote: Chris Bagwell chris at cnpbagwell.com wrote: Hi, It switches sanei_thread from using fork() to using pthreads for reader processes. Ah, thats the part I was missing and can now reproduce. Some of that double negative logic in acinclude.m4 was confusing me and I thought my test on Darwin would have fully tested it. Yes, it's a bit convoluted, isn't it? :) If you feel like adding a --enable-pthreads instead, feel free ;) yes- i was just going to say- lets drop --disable-fork and add --enable-pthreads instead. OK, thats what I did. Also, I changed things so that if --disable-pthread is specified that we do not needlessly link in -lpthread or set the CPPFLAGS to re-entrant. I would appreciate a quick glance by someone to make sure I didn't get any logic wrong. Here's to hoping my first commit with git went well. Chris -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090504/458e0321/attachment.htm
[sane-devel] [sane-commit] [SCM] SANE backends - scanner drivers branch, master, updated. gitconversion-23-g3ba5515
On 05/10/2009 01:28 PM, m. allan noah wrote: On Sun, May 10, 2009 at 2:22 PM, Julien BLACHEjb at jblache.org wrote: Ilia Sotnikovhostcc at gmail.com wrote: Hi, Could you please describe in what matter using relative paths to header files (eg. #include ../include/sane/sane.h) is better in comparision with -I../include command line option? Just to have cleaner picture... This way you don't pick up installed SANE include files in the standard include paths. see recent thread about freebsd build issues. allan A brief summary: Using #include sane/*.h and -I for header files that can also be found in /usr/include is not reliable as some cpp's will search -I paths as last option in that case; thus preferring the /usr/include version. So this is a problem with sane/sane.h and sane/saneopts.h but I also applied a chosen solution to all internal header files for consistency. Chris -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090510/f41c1ccf/attachment.htm
[sane-devel] [sane-commit] [SCM] SANE backends - scanner drivers branch, master, updated. gitconversion-23-g3ba5515
On 05/11/2009 12:12 AM, stef wrote: Le Sunday 10 May 2009 04:51:56 chris at cnpbagwell.com, vous avez ?crit : The following commit has been merged in the master branch: commit 3ba551592c3ad71f82f6b0b2e19c248cc8fe40c1 Author: chris at cnpbagwell.comchris at cnpbagwell.com Date: Sat May 9 21:50:35 2009 -0500 Adding changelog for recent commit. diff --git a/ChangeLog b/ChangeLog index 0146403..e68983f 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,6 @@ +2009-05-09 Chris Bagwellcbagwell-guest at users.alioth.debian.org +* */*.c: standardize including local sane include files. + 2009-05-09 Nicolas Martinnicols-guest at users.alioth.debian.org * backend/pixma_mp150.c, doc/descriptions/pixma.desc: Fixed Pixma MP600 and MP600R for 2400 dpi scan, updated their descriptions. Hello, I have a couple of problems with commits regarding this entry. First I don't find */*.c a useful changelog entry. Sorry, bit of laziness but hoped it read correctly in that every *.c file was touched in some way (at least by a sed script) and so this commit should be treated suspect as such. Second, I really think that active maintainers should be asked on the sane- devel list before changing the code they responsible for. Then go for the change if there is no answer in a decent amount of time. This is going to come up from time to time... There are housekeeping items I'd like to do such as these header bugfixes/cleanups (depending on file if its a bug), standardizing on stdint.h types when portability becomes an issue, etc. I'd think this particular patch would bore people to death reading it but if authors prefer a heads up then not much issue from my side to publish diff to mailing list first. BTW is there any way to include the diffstat in commit messages ? I think this would make them more readable. I second that... I preferred the diffstat over actual diffs if thats possible. Another would be to have the subject line contain diff summary instead of the current subject line its using. Chris Regards, Stef -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090511/4991afb8/attachment.htm
[sane-devel] [sane-commit] [SCM] SANE backends - scanner drivers branch, master, updated. gitconversion-23-g3ba5515
Yes, I would also appreciate if confirmation or clarification when a rebase can be used. I probably mis-interrepted Julien's useful email to mean a rebase only works when remote server has changes that do not affect your local commits; else a merge is needed. Chris On Mon, May 11, 2009 at 8:02 AM, m. allan noah kitno455 at gmail.com wrote: and here we have a merge commit like julien warned about, where my most recent (large) commit to canon_dr shows up again in this commit. IIRC, we should not use git pull, but instead, get fetch and git rebase to prevent this? not directed at chris particularly, git and i dont seem to get along yet, either allan On Sat, May 9, 2009 at 10:51 PM, chris at cnpbagwell.com chris at cnpbagwell.com wrote: The following commit has been merged in the master branch: commit 07c5723cab9571524db586c3319eb40a93568107 Merge: 4d9e8138af0f399e72599631854fa266cb18a4da 64621621c1e3b0163dbd62d3071df028d2cf0b34 Author: chris at cnpbagwell.com chris at cnpbagwell.com Date: Sat May 9 21:40:55 2009 -0500 Merge branch 'master' of ssh:// cbagwell-guest at git.debian.org/git/sane/sane-backends diff --combined backend/canon_dr.c index 44cd9f3,b5d5ab3..994ee0e --- a/backend/canon_dr.c +++ b/backend/canon_dr.c @@@ -56,8 -56,9 +56,9 @@@ Section 2 - sane_init, _get_devices, _open friends Section 3 - sane_*_option functions Section 4 - sane_start, _get_param, _read friends -Section 5 - sane_close functions -Section 6 - misc functions +Section 5 - calibration functions +Section 6 - sane_close functions +Section 7 - misc functions Changes: v1 2008-10-29, MAN @@@ -182,6 -183,19 +183,19 @@@ v26 2009-04-14, MAN (SANE 1.0.20) - return cmd status for reads on sensors - allow rs to adjust read length for all bad status responses + v27 2009-05-08, MAN + - bug fix in read_panel() + - initialize vars in do_usb_cmd() + - set buffermode off by default + - clear page counter during init and sane_start() + - eject previous page during init and sane_start() + - improved SSM_BUFF macros + - moved set_window() to after ssm-*() + - add coarse calibration (AFE offset/gain per-channel exposure) + - add fine calibration (per-cell offset/gain) + - free image and fine cal buffers in sane_close() + - compare page counter of small scanners only in non-buffered mode + - add back-side gray mirroring code for DR-2580C -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090511/b4edefd4/attachment.htm
[sane-devel] Warning during configuration of backends 1.0.20 on Mac OS X
I see the issue now but do not know a way to fix it. BTW, the issue is harmless but the scary looking message is built into the tools we use and not able to be disabled. Anyways, reviewing sane's OS X SCSI code, I see any time they compile something, there is a #undef VERSION that conflicts with the OS's header files. I don't know an easy way to undef before checking for header files. Chris On Tue, May 26, 2009 at 2:36 AM, George Katselis katselis at comcast.netwrote: Hi, Devs. I'm using Mac OS 10.5.7.9J61 on a Mac Book 2.16 C2D. I'm trying to compile the SANE Backends 1.0.20 from debian.org. During configure, this warning was displayed, with the message to report it to you. Hope it's helpful! If I can provide more info, please let me know. configure: WARNING: IOKit/scsi/SCSITaskLib.h: present but cannot be compiled configure: WARNING: IOKit/scsi/SCSITaskLib.h: check for missing prerequisite headers? configure: WARNING: IOKit/scsi/SCSITaskLib.h: see the Autoconf documentation configure: WARNING: IOKit/scsi/SCSITaskLib.h: section Present But Cannot Be Compiled configure: WARNING: IOKit/scsi/SCSITaskLib.h: proceeding with the preprocessor's result configure: WARNING: IOKit/scsi/SCSITaskLib.h: in the future, the compiler will take precedence configure: WARNING: ## - ## configure: WARNING: ## Report this to sane-devel at lists.alioth.debian.org ## configure: WARNING: ## - ## -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090527/bd70ee14/attachment.htm
[sane-devel] Epson PX700W/Artisan 700 network scanning
On Thu, May 28, 2009 at 2:46 PM, Dominik Wnek dominalien at netscape.netwrote: Alessandro Zummo pisze: On Thu, 28 May 2009 08:43:21 +0900 Alesh Slovak alesh.slovak at avasys.jp wrote: iscan limits itself to the epkowa backend, but Xsane was probably using the epson2 backend, which supports the necessary network protocol, but it seems like it doesn't have support for your particular model. Maybe Alessandro (epson2 backend developer) can help you here. If it has been detected by epson2 there are chances that we can make it work. I'd need a debug log. Hello, Thank you very much for your answer. I'll be more than happy to assist with this. Please tell me what to do. Best regards, Dominik Before running your application (xsane, scanimage, etc), run the following from a bash shell: export SANE_DEBUG_EPSON2=128 export SANE_DEBUG_EPSON2_NET=128 Then run something like following to capture debug logs: scanimage 2 scanning.log Chris -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090528/59b7f9e3/attachment.htm
[sane-devel] byteorder.h
If no one else gives it a go, I'll have a hand at updating the autoconf macro. I've not much experience with cross platform locations of those defines. I see in my Fedora 11 Linux box that alot of those duplicates are defined in endian.h (although perhaps hidden by some #ifdef's) and the closest the macro looks for them is in machine/endian.h. I don't know any history between those two locations or when a needed __USE_BSD is defined by compilers. Chris On 06/01/2009 05:00 PM, Alessandro Zummo wrote: it seems the autoconf generated byteorder.h overrides functions defined in the usual includes, generating messages like this one: ../include/byteorder.h:32:1: warning: htobe16 redefined In file included from /usr/include/sys/types.h:217, from /usr/include/sys/uio.h:24, from /usr/include/sys/socket.h:28, from /usr/include/netinet/in.h:25, from ../include/sane/sanei_tcp.h:23, from epson2_net.c:20: any suggestion?
[sane-devel] epson2 updated again
OK, I'm not exactly sure what is different from my last test but now latest update of git and I can network scan great with my Artisan 800. I just tried a hand full of resolutions and both flatbed and ADF. All looked visually fine. Thanks for your work on this! Now, I guess I should go off and figure out what I did to sanei_tcp_read() in return. Chris On 06/02/2009 06:28 PM, Alessandro Zummo wrote: Updated: - added more devices - updated description file - rescan devices on sane_get_devices Still in the pipeline: - color correction profiles - infrared support - support for warmup condition
[sane-devel] Sane Error
On Fri, Jun 26, 2009 at 10:55 AM, Michael Cronenworth mike at cchtml.comwrote: David Solomon on 06/26/2009 10:45 AM wrote: Is there any way to disable the usage globally for testing? If you search through the mailing list archives you should find my MinGW patches (still don't seem to be accepted by the maintainers?) and compile a native libsane.dll unless you require saned. Michael, I was going to attempt to submit at least non-issue chunks of your patches (for example, anything under lib/ which is to support multiple platforms anyways). Last email I saw from you, you mentioned going to re-update your patches so I held off. Mind resending the latest? I've also now installed mingw cross compiler on Fedora 11 box so can help verify things. Chris -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090626/5005df91/attachment.htm
[sane-devel] Sane Error
On Fri, Jun 26, 2009 at 10:45 AM, David Solomon dsolomon at rx30.com wrote: Is there any way to disable the usage globally for testing? David You can try to change to pthreads instead of fork as an easy test by using a configure option. Not sure if it will make a difference. Are you using 1.0.20 or git? For 1.0.20: configure --disable-fork-process For git: --enable-pthreads Chris -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090626/31017af2/attachment.htm
[sane-devel] Installing Problems
On 09/20/2009 11:19 AM, carterbueford at gmx.net wrote: Hi, I get the following error during installation of sane-server on my mashine: collect2: ld returned 1 exit status make[2]: *** [libsane-qcam.la] Error 1 make[2]: Leaving directory `/opt/install_dir/sane_install/sane-backends-1.0.20/backend' make[1]: *** [all] Error 2 make[1]: Leaving directory `/opt/install_dir/sane_install/sane-backends-1.0.20/backend' make: *** [all-recursive] Error 1 Any suggestions? Thanks. Oliver Probably some sort of unresolved symbols or libraries not found. What does the text before what you included say? Should mention the library/symbols having issues. Chris -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090920/509df3b1/attachment.htm
[sane-devel] Installing Problems
On Mon, Sep 21, 2009 at 9:03 AM, carterbueford at gmx.net wrote: Hi, please take a look at the attached logfile. There you?ll find the complete aoutput of the make-command. Thanks Oliver OK, based on your log, it can not find the definitions for inb and outb functions for the qcam backend. What OS are you compiling on? Also, can you send your config.log directly to me? It should be in the directory where you ran ./configure from. There is some logic in acinclude.m4 to disable qcam backend if ioperm() and portaccess() are not defined... but it looks slightly buggy how it was phrased (should have been an || I think). And it doesn't check specifically for inb and outb; which seems reasonable at least under Linux but perhaps not on other platforms. -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090921/df93caf2/attachment.htm
[sane-devel] Installing Problems
On Mon, Sep 21, 2009 at 9:17 AM, Chris Bagwell chris at cnpbagwell.com wrote: There is some logic in acinclude.m4 to disable qcam backend if ioperm() and portaccess() are not defined... but it looks slightly buggy how it was phrased (should have been an || I think). And it doesn't check specifically for inb and outb; which seems reasonable at least under Linux but perhaps not on other platforms. OK, the check in acinclude.m4 is correct (it is an either/or thing). I looks like its probably that qcam uses outb and inb but doesn't link in sanei_pio. That file appears to have some logic to handle platforms that do not define those functions. I'll submit a fix to backends/Makefile.am to start linking this in. Chris -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090921/74004fb5/attachment.htm
[sane-devel] Fwd: Fw: SANE compile problem on Solaris
Meant for this to go to the mailing list for future reference. -- Forwarded message -- From: Chris Bagwell ch...@cnpbagwell.com Date: Fri, Sep 25, 2009 at 10:04 AM Subject: Re: Fw: [sane-devel] SANE compile problem on Solaris To: David Price djprice at mindspring.com On Fri, Sep 25, 2009 at 9:43 AM, David Price djprice at mindspring.com wrote: Chris, Thanks for your reponse and suggestions. I have tried both suggestions, both I still cannot get it compiled but with different errors: First, I downloaded the latest backend version from git, it made it a lot further in the build but then failed with: make[2]: Entering directory `/export/home/price/download/sane/git/install.git20090925/sane-backends-git20090925/backend' /bin/bash ../libtool --silent --tag=CC --mode=link gcc -I/usr/sfw/include -W -Wall -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -pedantic -Wl,-z,defs -rpath '/opt/sane/lib/sane' -version-number 1:0:21 -module -L/usr/sfw/lib -o libsane-epjitsu.la libsane_epjitsu_la-epjitsu-s.lo ../lib/liblib.la libepjitsu.la../sanei/sanei_init_debug.lo ../sanei/sanei_constrain_value.lo ../sanei/sanei_config.lo sane_strstatus.lo ../sanei/sanei_usb.lo -lm Undefined first referenced symbol in file roundf ./.libs/libepjitsu.a(libepjitsu_la-epjitsu.o) ld: fatal: Symbol referencing errors. No output written to .libs/libsane-epjitsu.so.1.0.21 collect2: ld returned 1 exit status make[2]: *** [libsane-epjitsu.la] Error 1 make[2]: Leaving directory `/export/home/price/download/sane/git/install.git20090925/sane-backends-git20090925/backend' make[1]: *** [all] Error 2 make[1]: Leaving directory `/export/home/price/download/sane/git/install.git20090925/sane-backends-git20090925/backend' make: *** [all-recursive] Error 1 I ran into this myself as well. What I kinda remember was my LD_LIBRARY_PATH was set to something that was giving priority to libm.so.1; which doesn't defined roundf(); instead of libm.so.2. I think I had partially set up my environment to use an older SUNWspro (Sun's own compiler) and that was causing the issues; even though I was compiling with GCC. Try setting up a shell that doesn't have visibility to /opt/SUNWspro/lib or gives priority to /lib first (using LD_LIBRARY_PATH). Chris -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090925/d2a850bc/attachment-0001.htm
[sane-devel] Fwd: sane_read: Device busy with Canon PIXMA MX310 and sane 1.0.20-4ubuntu3
Sorry, meant to reply to mailing list. -- Forwarded message -- From: Chris Bagwell ch...@cnpbagwell.com Date: Wed, Dec 2, 2009 at 7:00 PM Subject: Re: [sane-devel] sane_read: Device busy with Canon PIXMA MX310 and sane 1.0.20-4ubuntu3 To: Rogier Eggers rogiereggers at gmail.com On Wed, Dec 2, 2009 at 5:37 PM, Rogier Eggers rogiereggers at gmail.comwrote: Hi Nicolas, Ok, so indeed, the git version without pthtread works flawlessy (see attached log). However, I so far didn't manage to build sane-backends with pthread. After exactly following your instructions, I get the message below. This is with no ubuntu sane packages installed. Can anybody tell me which dev package I miss to build sane with pthread? Sorry, I can't answer name of debian pthread-devel package but I think you also have some sort of configure error. I don't see the -lpthread during the link. Can you reverify that you did the following line? export LIBS=-lpthread If that doesn't work then try adding this after the make distclean step but before configure step: export PTHREAD_LIBS=-lpthread Nicolas, I'm curious why you didn't recommend the following instead: make distclean ./configure --enable-pthread Does that not work correctly under debian with git? Anything I can do to help get that working? Perhaps it was just some past confusion in debian from having to use --disable-fork to get pthread working and that not being obvious? Chris Regards, Rogier Error message during build process: [snip] rm -fr .libs/libsanei.a .libs/libsanei.la ar cru .libs/libsanei.a .libs/sanei_ab306.o .libs/sanei_constrain_value.o .libs/sanei_init_debug.o .libs/sanei_net.o .libs/sanei_wire.o .libs/sanei_codec_ascii.o .libs/sanei_codec_bin.o .libs/sanei_scsi.o .libs/sanei_config.o .libs/sanei_config2.o .libs/sanei_pio.o .libs/sanei_pa4s2.o .libs/sanei_auth.o .libs/sanei_usb.o .libs/sanei_thread.o .libs/sanei_pv8630.o .libs/sanei_pp.o .libs/sanei_lm983x.o .libs/sanei_access.o .libs/sanei_tcp.o .libs/sanei_udp.o .libs/sanei_magic.o .libs/sanei_jpeg.o ranlib .libs/libsanei.a creating libsanei.la (cd .libs rm -f libsanei.la ln -s ../libsanei.la libsanei.la) make[1]: Leaving directory `/home/rogier/Software/Src/sane-backends-git20091201/sanei' Making all in backend make[1]: Entering directory `/home/rogier/Software/Src/sane-backends-git20091201/backend' make all-am make[2]: Entering directory `/home/rogier/Software/Src/sane-backends-git20091201/backend' /bin/bash ../libtool --silent --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../include/sane -I/usr/local/include -I. -I. -I../include -I../include -DLIBDIR=/usr/lib/sane -DBACKEND_NAME=dll -DPATH_SANE_CONFIG_DIR=/etc/sane.d -DPATH_SANE_DATA_DIR=/usr/share -DPATH_SANE_LOCK_DIR=/var/lock/sane -DV_MAJOR=1 -DV_MINOR=0 -DUSE_PTHREAD -W -Wall -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -pedantic -ansi -MT libdll_la-dll.lo -MD -MP -MF .deps/libdll_la-dll.Tpo -c -o libdll_la-dll.lo `test -f 'dll.c' || echo './'`dll.c dll.c: In function ?load?: dll.c:535: warning: ISO C forbids conversion of object pointer to function pointer type dll.c:560: warning: ISO C forbids conversion of object pointer to function pointer type mv -f .deps/libdll_la-dll.Tpo .deps/libdll_la-dll.Plo /bin/bash ../libtool --silent --tag=CC --mode=link gcc -DUSE_PTHREAD -W -Wall -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -pedantic -ansi -Wl,-z,defs -o libdll.la libdll_la-dll.lo /bin/bash ../libtool --silent --tag=CC --mode=link gcc -DUSE_PTHREAD -W -Wall -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -pedantic -ansi -Wl,-z,defs -rpath '/usr/lib' -version-number 1:0:21 -o libsane.la -rpath /usr/lib libsane_la-dll-s.lo ../lib/liblib.la libdll.la sane_strstatus.lo ../sanei/sanei_init_debug.lo ../sanei/sanei_constrain_value.lo ../sanei/sanei_config.lo ../sanei/sanei_config2.lo ../sanei/sanei_usb.lo ../sanei/sanei_scsi.lo ../sanei/sanei_pv8630.lo ../sanei/sanei_pp.lo ../sanei/sanei_thread.lo ../sanei/sanei_lm983x.lo ../sanei/sanei_access.lo ../sanei/sanei_net.lo ../sanei/sanei_wire.lo ../sanei/sanei_codec_bin.lo ../sanei/sanei_pa4s2.lo ../sanei/sanei_ab306.lo ../sanei/sanei_pio.lo ../sanei/sanei_tcp.lo ../sanei/sanei_udp.lo -ldl -lm -lieee1284 -ltiff -ljpeg -lgphoto2 -lgphoto2_port -lexif -lm -lusb -lusb ../sanei/.libs/sanei_thread.o: In function `sanei_thread_kill': sanei_thread.c:(.text+0xe5): undefined reference to `pthread_cancel' ../sanei/.libs/sanei_thread.o: In function `sanei_thread_begin': sanei_thread.c:(.text+0x302): undefined reference to `pthread_create' ../sanei/.libs/sanei_thread.o: In function `sanei_thread_sendsig': sanei_thread.c:(.text+0x3ac): undefined reference to `pthread_kill
[sane-devel] Fwd: sane_read: Device busy with Canon PIXMA MX310 and sane 1.0.20-4ubuntu3
On Thu, Dec 3, 2009 at 3:34 PM, Nicolas Martin nicolas0martin at gmail.comwrote: Nicolas, I'm curious why you didn't recommend the following instead: make distclean ./configure --enable-pthread Yes Chris, you are right, I did not mention that, this adds the correct -lpthread option to the link statement, and should solve the problem hereunder. However, the export CFLAGS=-DUSE_PTHREAD statement is necessary for me, before running the ./configure ... , otherwise, it will compile with the forked option, as the USE_PTHREAD flag stays unset. So your saying that, for you, running make distclean; ./configure --enable-pthread; make doesn't correctly have USE_PTHREAD defined? If so, do you mind emailing me your config.log and include/src/config.h? I'll see what I can do to get it working. It works for me... a quick code review shows snapscan-usb.c a little suspicious because its not including ../include/sane/config.h but is checking for USE_PTHREAD. I didn't follow its include chain very closely though since we are talking about pixma. Thanks, Chris -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20091203/4d0c5b9d/attachment.htm
[sane-devel] why hasn't there been a release in a long time ?
I was going to wait a little closer to 1 year anniversary of last release before bringing it up but thats starting to creep up on us. I was also hoping we can get one out in time for Fedora 13 but their freeze is coming up pretty quick. I'll offer to help out as much as possible with the release. I can do my set of platform checks (cygwin, osx, solaris, pulling any Fedora patches that make sense, etc). Basically, I can make sure the steps in release.txt are pain free up to the Announcing Release step. I do not recall seeing any 1.1 API stuff being re-enabled although there was talk of it. Is there any work to be done in that area? Chris On Mon, Feb 8, 2010 at 8:16 AM, m. allan noah kitno455 at gmail.com wrote: I personally will take the great measure of responsibility for this problem. My time has become very limited since I took over the job of making releases. I have also allowed the confusion around a new API prevent us from moving forward with maintenance releases, even though that is an unrelated issue. If someone else wants to step up and schedule/make the release, I'd be happy for the help. Otherwise, let me look at a calendar, and come up with a plan. Thanks for the kick in the pants :) allan On Mon, Feb 8, 2010 at 6:39 AM, Julien BLACHE jb at jblache.org wrote: db db.pub.mail at gmail.com wrote: Hi, I know this is not the fault of sane, however this is causing a large distance between what sane can do and what sane 'does' as shipped. If there's no release, there's nothing new to package. As simple as that. So, yes, it is SANE's fault. I'm not packaging git snapshots because I cannot support them in a stable Debian release. I used to package CVS snapshots when I knew a release was coming up and would be out suited for Debian stable at a time where I could still push it into stable. With the 1.1 API stuff and no release schedule, I can't do that anymore. JB. -- Julien BLACHE ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? http://www.jblache.org jb at jblache.org ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?GPG KeyID 0xF5D65169 -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password ? ? ? ? ? ? to sane-devel-request at lists.alioth.debian.org -- The truth is an offense, but not a sin -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password ? ? ? ? ? ? to sane-devel-request at lists.alioth.debian.org
[sane-devel] scanimage 1.0.20 hangs on Solaris 10/SPARC (pixma backend)
The easy thing I can suggest is to try compiling with --enable-pthread. I recall a past discussion related to libusb and that sometimes causing it to work better. If that doesn't fix things for you then your going to have to debug this yourself. I do not think there are any active Solaris developers on the mailing list. See man san, man sane-usb, and man sane-backend (replace backend with real name) for information on what environment variables you can see to enable debug output. Chris On Sun, Feb 28, 2010 at 2:13 AM, Patrick Simmons linuxrocks123 at netscape.net wrote: Hello all, I'm trying to get SANE 1.0.20 working with a Canon MP210 USB scanner on Solaris/SPARC. ?I'm using the latest Solaris 10 build. ?However, I can't get it to scan. ?When I do scanimage -L, my scanner is shown correctly after a moderately long delay, but scanimage just hangs forever when I try to use it to scan. ?scanimage will also hang forever when run with the --help option, after printing out the help text. ?It's as if it's trying to print the scanner name but ran into trouble. I've followed README.Solaris to the letter, except that I also changed an include path in the Makefile from -I/usr/local/include to -I/usr/include because the md5.h in /usr/local/include won't compile on my machine for some reason. ?I experience the same behavior with the latest GIT snapshot. ?The same behavior happens whether I am root or a user. ?I have verified that the scanimage works with SANE 1.0.20 on Linux/AMD64; in addition, I until recently ran Linux/SPARC on the Solaris 10 machine. ?scanimage worked there with a development snapshot of SANE calling itself SANE 1.1.0. Does anyone know what could be wrong? Thanks, --Patrick
[sane-devel] Epson Perfection 610 Issue with 150 dpi scan
On Sun, Jan 3, 2010 at 7:01 AM, Rainer Dorsch rdorsch at web.de wrote: For the long options issue: I rebuild git sane on another machine (also Debian stable aka Debian 5.0) and the long options error is still there. Even --help has problems. Which library is sane using to process the command line options? Does Debian stable maybe ship with a different version than your system? After running configure, can you look at the file include/sane/config.h? Check if HAVE_GETOPT_H and HAVE_GETOPT_LONG are defined. On debian, I would expect them to be defined. In that case, it uses standard libc version of getopt. I do see one suspicious line in lib/getopt.c and lib/getopt1.c. They do a #include config.h instead of #include ../include/sane/config.h and so in certain cases it may be including the wrong config.h file. In that case, it would mistakenly compile a conflicting version of getopt_long() (which can explain the problem your seeing). Chris -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20100103/55a4b3f3/attachment.htm
[sane-devel] long option format not recognized (Was: Epson Perfection 610 Issue with 150 dpi scan)
There was a typo in first part of Rainer's email. Later on it shows its still not working although its safe fix I should probably submit. I've now been able to reproduce the issue with --help not working with the epson2 backend. The problem occurs when we reach driver specific help and so may be specific to epson2. The all_options doesn't seem to contain the --help option and probably anything from basic_options[] array. Since basic_options[] (which includes --help) is copied to all_options[] after filling in backend options, I suspect something returned by epson2 backend is causing a NULL to be placed in middle and causing getopt_long() to stop processing early. I couldn't find anything obvious like missing options inits from browsing the code. I guess it will need to be brute forced debugged to find where the NULL is coming from. Chris On Sun, Jan 3, 2010 at 5:06 PM, m. allan noah kitno455 at gmail.com wrote: good call chris- you want to submit a fix? allan On Sun, Jan 3, 2010 at 4:14 PM, Rainer Dorsch rdorsch at web.de wrote: Hi Chris, Am Sonntag, 3. Januar 2010 schrieb Chris Bagwell: On Sun, Jan 3, 2010 at 7:01 AM, Rainer Dorsch rdorsch at web.de wrote: For the long options issue: I rebuild git sane on another machine (also Debian stable aka Debian 5.0) and the long options error is still there. Even --help has problems. Which library is sane using to process the command line options? Does Debian stable maybe ship with a different version than your system? After running configure, can you look at the file include/sane/config.h? Check if HAVE_GETOPT_H and HAVE_GETOPT_LONG are defined. On debian, I would expect them to be defined. In that case, it uses standard libc version of getopt. As you expected, it is there: rd at blackbox:~/SW.nobackup/sane-backends$ grep HAVE_GETOPT include/sane/config.h #define HAVE_GETOPT_H 1 #define HAVE_GETOPT_LONG 1 rd at blackbox:~/SW.nobackup/sane-backends$ I do see one suspicious line in lib/getopt.c and lib/getopt1.c. They do a #include config.h instead of #include ../include/sane/config.h and so in certain cases it may be including the wrong config.h file. In that case, it would mistakenly compile a conflicting version of getopt_long() (which can explain the problem your seeing). Hmm...that does solve the problem: I did this modification rd at blackbox:~/SW.nobackup/sane-backends$ git diff diff --git a/lib/getopt.c b/lib/getopt.c index 9dabb82..b8715e3 100644 --- a/lib/getopt.c +++ b/lib/getopt.c @@ -20,7 +20,7 @@ License along with the GNU C Library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. */ -# include config.h +# include ../include/sane/config.h #if !defined(HAVE_GETOPT_H) || !defined(HAVE_GETOPT_LONG) ^L /* This tells Alpha OSF/1 not to define a getopt prototype in stdio.h. diff --git a/lib/getopt1.c b/lib/getopt1.c index 5ace00a..082998c 100644 --- a/lib/getopt1.c +++ b/lib/getopt1.c @@ -17,7 +17,7 @@ License along with the GNU C Library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. */ -#include config.h +#include ../include/sane/config.h #if !defined(HAVE_GETOPT_H) || !defined(HAVE_GETOPT_LONG) ^L #ifdef HAVE_CONFIG_H rd at blackbox:~/SW.nobackup/sane-backends$ recompiled, set the paths again rd at blackbox:~/SW.nobackup/sane-backends$ export |grep PATH declare -x LD_LIBRARY_PATH=/opt/sane-backends-091230/lib declare -x PATH=/opt/sane-backends-091230/bin:/usr/local/bin:/usr/bin:/bin:/usr/games rd at blackbox:~/SW.nobackup/sane-backends$ and --help is still not recognized rd at blackbox:~/SW.nobackup/sane-backends$ which scanimage /opt/sane-backends-091230/bin/scanimage rd at blackbox:~/SW.nobackup/sane-backends$ and --help is still not recogniced rd at blackbox:~/SW.nobackup/sane-backends$ scanimage --help Usage: scanimage [OPTION]... Start image acquisition on a scanner device and write image data to standard output. Parameters are separated by a blank from single-character options (e.g. -d epson) and by a = from multi-character options (e.g. --device-name=epson). -d, --device-name=DEVICE use a given scanner device (e.g. hp:/dev/scanner) --format=pnm|tiff file format of output file -i, --icc-profile=PROFILE include this ICC profile into TIFF file -L, --list-devices show available scanner devices -f, --formatted-device-list=FORMAT similar to -L, but the FORMAT of the output can be specified: %d (device name), %v (vendor), %m (model), %t (type), %i (index number), and %n (newline) -b, --batch[=FORMAT] working in batch mode, FORMAT is `out%d.pnm
[sane-devel] Has anyone managed to get Snapscan backend working with FreeBSD 8.0 (which uses libusb)?
On Tue, Jan 26, 2010 at 3:04 AM, Oliver Schwartz Oliver.Schwartz at gmx.dewrote: Hi all, On 25.01.2010, at 12:26, Torfinn Ingolfsen wrote: In the meantime, another FreeBSD user found a way to fix it, it is just a one-line patch: http://lists.freebsd.org/pipermail/freebsd-usb/2010-January/008172.html With Andrew's patch, my scanner now works: root at kg-v2# sane-find-scanner -q found USB scanner (vendor=0x03f0 [HP], product=0xc202 [Photosmart 8200 series]) at libusb:/dev/usb:/dev/ugen1.2 found USB scanner (vendor=0x06bd [AGFA], product=0x2061 [ Snapscan1212u_2]) at libusb:/dev/usb:/dev/ugen2.2 root at kg-v2# scanimage -L device `snapscan:libusb:/dev/usb:/dev/ugen2.2' is a AGFA SNAPSCAN 1212U_2 flatbed scanner Thanks for the pointer, I'll try to get this fixed in the backend. The code in question was added recently to fix another problem with calculating a unique identifier. Maybe one of the guys who's experienced with autoconf can give me a hint on how to do this the best way. Should I just use #ifdef BSD around the code in question or is there some autoconf magic that would allow me to do a more advanced query? I also have to retest this on OS X - the code in question looks very Linux specific. Kind regards, Oliver I don't think there is any autoconf stuff that can help you... or perhaps what you need is already there. A quick look at sanei_usb_init() and I think its the one generate 2 types of strings depending on if your using libusb 1.0 or not. So at least you should be able to reference HAVE_LIBUSB_1.0 but maybe better to update sanei_usb_init() code to always generate a consistent string? Chris -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20100126/36a9b0fe/attachment.htm
[sane-devel] Description file, Epson, and wildcards
Hi all, I'm reviewing Fedora patch set and notice an issue that I'm not sure how to handle within Sane. Has this been discussed in past? It looks like all 3 Epson backends can detect SCSI scanners based on scsi type being processor, vendor ID being EPSON, and the model/product name having 1 of 5 prefixes. This is good to know for next step. On Fedora, it seems its a common problem that hal or udev gets the permissions for scsi Epson scanners wrong and users can only scan as root. They generically fix permissions for scsi scanner class but not processor. Their work around is to edit entry for specific scanner in the epson2.desc file and a line as follows each time a user reports a problem: :scsi ESPON Exact Model Name Reported processor Once thats done, sane's tools will generate a libsane.fdi/libsane.rules that will set permissions correct. Sane is not providing enough details right now it seems. First option to help end users is to start providing that much details. Mostly, the epson2.desc values are driven by epkowa developers from their epkowa.desc. Would it be possible for epkowa developers to provide a :scsi line for all SCSI devices? Second option is to provide some kind of wild card support. For example: :scsi EPSON Perfection* processor This would be pretty difficult to convert into hal and udev yntax though. Its also will cause some confusion when a Perfection 636S rule matches a Perfection 636. A third option is to provide some sort of hard coded/hand written wild card rules that is added to libsane.fdi and libsane.rules for these special cases. This is probably the easiest. It looks like at east Epson and HP could benefit from this. Do people think this is worth addressing? Chris
[sane-devel] Description file, Epson, and wildcards
On Mon, Mar 1, 2010 at 11:36 PM, Olaf Meeuwissen olaf.meeuwissen at avasys.jp wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Bagwell wrote: On Fedora, it seems its a common problem that hal or udev gets the permissions for scsi Epson scanners wrong and users can only scan as root. ?They generically fix permissions for scsi scanner class but not processor. ?Their work around is to edit entry for specific scanner in the epson2.desc file and a line as follows each time a user reports a problem: :scsi ESPON Exact Model Name Reported processor The 2010-03-01 git snapshot has ?$ ?grep :scsi doc/descriptions*/ep*.desc ?doc/descriptions/epson.desc::scsi EPSON SCANNER GT-7000 processor ?doc/descriptions/epson.desc::scsi EPSON Perfection1200 processor ?doc/descriptions/epson.desc::scsi EPSON Perfection636 processor ?doc/descriptions/epson.desc::scsi EPSON Perfection1200 processor already. ?Are you talking about other models? Yes, they have a patch for Expression800 in addition. My assumption is it would be an issue with any SCSI-only EPSON scanner? Or is there a small subset of names all models use? Mostly, the epson2.desc values are driven by epkowa developers from their epkowa.desc. ?Would it be possible for epkowa developers to provide a :scsi line for all SCSI devices? Yes. ?No promises on a release time line but we could send a diff to the list and ask someone with the necessary privileges to commit. My understanding is that epson2.desc updates are automated based on epkowa.desc updates. So if you could send this updated file to list when its ready, I can submit it. That would be great! Its brute force fix but it will work nicely. A third option is to provide some sort of hard coded/hand written wild card rules that is added to libsane.fdi and ?libsane.rules for these special cases. ?This is probably the easiest. ?It looks like at east Epson and HP could benefit from this. Do people think this is worth addressing? Anything that makes out of the box scanner device detection and setup so you can scan without root privileges is worth addressing. I'll keep the third option in the back pocket... depending on what time line becomes for option one we can pull it out. Chris
[sane-devel] Description file, Epson, and wildcards
On Tue, Mar 2, 2010 at 5:42 PM, Olaf Meeuwissen olaf.meeuwissen at avasys.jp wrote: Yes, they have a patch for Expression800 in addition. ?My assumption is it would be an issue with any SCSI-only EPSON scanner? ?Or is there a small subset of names all models use? Hadn't heard about that one, I'll add that to epkowa.desc as well then. ?Assume it is for the Expression 800 only and not for its Japanese cousin the GT-9600. Sorry for not including that. The report was for Expression 800 entry. The following is bug report if interested. https://bugzilla.redhat.com/show_bug.cgi?id=456656 To be honest, I don't know what the various EPSON scanners with a SCSI interface report. ?Apparently, most advertise themselves as a scanner device so no special handling should be required. ?Some models however think that they are processors and need the :scsi entry. ?What names these models report, I don't know, so I will have to rely on whatever people report. Mostly, the epson2.desc values are driven by epkowa developers from their epkowa.desc. ?Would it be possible for epkowa developers to provide a :scsi line for all SCSI devices? Yes. ?No promises on a release time line but we could send a diff to the list and ask someone with the necessary privileges to commit. My understanding is that epson2.desc updates are automated based on epkowa.desc updates. As m. allen noah also pointed out, that's living life dangerously. If epkowa.desc can include those :scsi that are known, it would be great. Since the epkowa.desc is used in sane-backend build process, fedora would get your :scsi fixes when users install sane-backends and these reports would reduce some... maybe helping isane out in the process. The epson2.desc entries may need further discussion but it sounds like my initial wish of removing a downstream patch can be addressed sometime in near future via a epkowa.desc update. Chris
[sane-devel] sane-backends release 1.0.21
Thanks very much. Can I assume this patch will be included in your future releases of epkowa backend? Allan, are *.desc updates acceptable at this point of freeze? Thanks, Chris On Mon, Apr 19, 2010 at 6:30 PM, Olaf Meeuwissen olaf.meeuwissen at avasys.jp wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 m. allan noah wrote: [...] Please check your .desc files, and make sure they are up to date with all the scanners your backends support, and make sure none of your supported scanners are listed in unsupported.desc. Here's a diff for epkowa.desc based on the thread[1] started by Chris Bagwell regarding some SCSI models that needed some extra info. ?[1] http://lists.alioth.debian.org/pipermail/sane-devel/2010-March/026209.html Hope this helps, - -- Olaf Meeuwissen, LPIC-2 ? ? ? ? ? FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 ? ? ? ? ? ? ? Help support software freedom ? ? ? ? ? ? ? ? http://www.fsf.org/jf?referrer=1962 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvM56MACgkQt5qrxaZLMnLqQQCeJtdQMEErdmbJUtoIXRdVlwJF WpIAoIIdASCnZNKMLDxi5nNNpIpAnubh =x44g -END PGP SIGNATURE- -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password ? ? ? ? ? ? to sane-devel-request at lists.alioth.debian.org
[sane-devel] sane-backends release 1.0.21
On Mon, Apr 19, 2010 at 6:30 PM, Olaf Meeuwissen olaf.meeuwissen at avasys.jp wrote: Here's a diff for epkowa.desc based on the thread[1] started by Chris Bagwell regarding some SCSI models that needed some extra info. ?[1] http://lists.alioth.debian.org/pipermail/sane-devel/2010-March/026209.html Thanks for the information! The diff has been commited. Chris
