Bug#457378: sane-backends: FTBFS on hurd-i386
Samuel Thibault [EMAIL PROTECTED] wrote: Hi, There is parport access in GNU Mach, but only as a printer. There isn't yet an interface to more closely drive the port. That said, you could just use ioperm() and sys/io.h macros (work just like in Linux). That's one of the access methods offered by libieee1284. As for the plustek_pp backend, I don't know why it's been written the way it is, but I suspect there's a reason :) JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457378: sane-backends: FTBFS on hurd-i386
457378 tags + patch
thanks
Hi,
Julien BLACHE, le Sat 22 Dec 2007 10:33:07 +0100, a écrit :
Sorry, no way. Your patch will also disable the plustek_pp backend on
kfreebsd, where that backend builds successfully.
ERf.
It's not tied to Linux-specific ioctls.
But it's tied to the way the non-standard _IOR() macro works, and I
thought that was exactly that which is tested by the autoconf code, and
that it would work on BSD too.
You'll have to find another way, properly porting the backend is the
preferred way as far as I'm concerned.
The problem is that at least the SET_ENV and SETMAP ioctls can not be
defined on GNU/Hurd because they pass a pointer within the structure,
which is not supported by ioctls on GNU/Hurd (since the actual parallel
port driver may not be in the kernel but a userland process). So that
backend just can't work as such.
A solution for now is to disable it for host_os matching gnu*, as the
attached patch does.
You should really cross-check with kfreebsd before sending that kind
of patches.
Yep, that episode decided me to install one.
Samuel
--- configure.in.orig 2007-12-13 20:16:17.0 +
+++ configure.in2007-12-23 15:01:43.0 +
@@ -364,11 +364,20 @@
canon630u cardscan coolscan coolscan2 dc25 dmc \
epson fujitsu genesys gt68xx hp leo lexmark matsushita microtek \
microtek2 mustek mustek_usb nec pie pixma plustek \
- plustek_pp ricoh s9036 sceptre sharp \
+ ricoh s9036 sceptre sharp \
sp15c st400 tamarack test teco1 teco2 teco3 umax umax_pp umax1220u \
artec_eplus48u ma1509 ibm hp5400 u12 snapscan niash sm3840 hp4200 \
sm3600 hp3500 stv680 epson2 hp5590 hp3900
+ case $host_os in
+gnu*)
+ echo *** disabling PLUSTEK_PP backend (GNU/Hurd not supported)
+ ;;
+*)
+ BACKENDS=${BACKENDS} plustek_pp
+ ;;
+ esac
+
if test ${sane_cv_use_libjpeg} != yes; then
echo *** disabling DC210 backend (failed to find JPEG library)
echo *** disabling DC240 backend (failed to find JPEG library)
Bug#457378: sane-backends: FTBFS on hurd-i386
Samuel Thibault [EMAIL PROTECTED] wrote: Hi, It's not tied to Linux-specific ioctls. But it's tied to the way the non-standard _IOR() macro works, and I Well, no, not really. Those macros are only used because the backend includes a low-level driver that can also be built as a kernel driver (pretty ugly, yes). So it could be rewritten not to use it or they could be redefined. (but I'm unsure the resulting backend would work on Hurd anyway). which is not supported by ioctls on GNU/Hurd (since the actual parallel port driver may not be in the kernel but a userland process). So that Speaking of parport access, a port of libieee1284 on Hurd would be nice to have, if there's any facility for parport access on Hurd. A solution for now is to disable it for host_os matching gnu*, as the attached patch does. I'll apply it upstream and it'll be in 1.0.19-1 or any upload that goes in before that. You should really cross-check with kfreebsd before sending that kind of patches. Yep, that episode decided me to install one. Now that we have a full non-Linux port, I think it's a useful tool for you :) Thanks, JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457378: sane-backends: FTBFS on hurd-i386
Hi, Julien BLACHE, le Sun 23 Dec 2007 20:33:07 +0100, a écrit : But it's tied to the way the non-standard _IOR() macro works, and I Well, no, not really. Those macros are only used because the backend includes a low-level driver that can also be built as a kernel driver (pretty ugly, yes). So it could be rewritten not to use it or they could be redefined. (but I'm unsure the resulting backend would work on Hurd anyway). It wouldn't work indeed, because of the pointer thing in the structure. port driver may not be in the kernel but a userland process). So that Speaking of parport access, a port of libieee1284 on Hurd would be nice to have, if there's any facility for parport access on Hurd. There is parport access in GNU Mach, but only as a printer. There isn't yet an interface to more closely drive the port. A solution for now is to disable it for host_os matching gnu*, as the attached patch does. I'll apply it upstream and it'll be in 1.0.19-1 or any upload that goes in before that. Ok thanks! You should really cross-check with kfreebsd before sending that kind of patches. Yep, that episode decided me to install one. Now that we have a full non-Linux port, I think it's a useful tool for you :) ? I mean, it happened to me for several other packages to have to ask somebody else checking how it would work on BSD, so eventually I can now make the tests myself. Samuel
Bug#457378: sane-backends: FTBFS on hurd-i386
Samuel Thibault, le Sun 23 Dec 2007 21:23:19 +0100, a écrit : Speaking of parport access, a port of libieee1284 on Hurd would be nice to have, if there's any facility for parport access on Hurd. There is parport access in GNU Mach, but only as a printer. There isn't yet an interface to more closely drive the port. That said, you could just use ioperm() and sys/io.h macros (work just like in Linux). Samuel
Bug#457378: sane-backends: FTBFS on hurd-i386
tags 457378 - patch thanks Samuel Thibault [EMAIL PROTECTED] wrote: Hi, sane-backends currently FTBFS on hurd-i386 because the plustek_pp backend defines its own ioctls calls which interact with a kernel module. That however can't compile as such when the linux ioctl defines are not available, thus the attached patch which disables the plustek_pp in that case. Of course, autoconf has to be rerun to get the patch actually have effect. Sorry, no way. Your patch will also disable the plustek_pp backend on kfreebsd, where that backend builds successfully. It's not tied to Linux-specific ioctls. You'll have to find another way, properly porting the backend is the preferred way as far as I'm concerned. You should really cross-check with kfreebsd before sending that kind of patches. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457378: sane-backends: FTBFS on hurd-i386
Package: sane-backends
Severity: important
Tags: patch
Hello,
sane-backends currently FTBFS on hurd-i386 because the plustek_pp
backend defines its own ioctls calls which interact with a kernel
module. That however can't compile as such when the linux ioctl defines
are not available, thus the attached patch which disables the plustek_pp
in that case. Of course, autoconf has to be rerun to get the patch
actually have effect.
Samuel
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.23
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
--
Samuel
RR Ce que je cherche à démontrer, c'est qu'il est injuste de faire
RR l'amalgame entre du bulk mail et du courrier non-solicité très ciblé
un suppositoire non reclamé, meme tres bien ciblé, reste un suppositoire.
-+-OS in : Guide du Neuneu d'Usenet - Plein le cul de la pub à neuneu -+-
--- configure.in.orig 2007-12-21 20:35:34.0 +
+++ configure.in2007-12-21 20:37:28.0 +
@@ -365,11 +365,17 @@
canon630u cardscan coolscan coolscan2 dc25 dmc \
epson fujitsu genesys gt68xx hp leo lexmark matsushita microtek \
microtek2 mustek mustek_usb nec pie pixma plustek \
- plustek_pp ricoh s9036 sceptre sharp \
+ ricoh s9036 sceptre sharp \
sp15c st400 tamarack test teco1 teco2 teco3 umax umax_pp umax1220u \
artec_eplus48u ma1509 ibm hp5400 u12 snapscan niash sm3840 hp4200 \
sm3600 hp3500 stv680 epson2 hp5590 hp3900
+ if test ${have_linux_ioctl_defines} != yes; then
+echo *** disabling PLUSTEK_PP backend (Cannot find Linux ioctl interface)
+ else
+BACKENDS=${BACKENDS} plustek_pp
+ fi
+
if test ${sane_cv_use_libjpeg} != yes; then
echo *** disabling DC210 backend (failed to find JPEG library)
echo *** disabling DC240 backend (failed to find JPEG library)
