According to bug 285016 "Since kernel-2.6.31, pci_find_device() is no longer available, even if PCI_LEGACY is used." emerge ltmodem These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] net-dialup/ltmodem-2.6.9-r1 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB >>> Verifying ebuild manifests >>> Emerging (1 of 1) net-dialup/ltmodem-2.6.9-r1 * ltmodem-2.6-alk-9.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found kernel object directory: * /lib/modules/2.6.31-gentoo-r6/build * Found sources for kernel version: * 2.6.31-gentoo-r6 * Checking for suitable kernel configuration options... [ ok ] >>> Unpacking source... >>> Unpacking ltmodem-2.6-alk-9.tar.bz2 to /var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/work * Applying ltmodem-2.6.9-kernel-2.6.27.patch ... [ ok ] >>> Source unpacked in /var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/work >>> Compiling source in /var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/work/ltmodem-2.6-alk-9 ... ln: creating symbolic link `Module.symvers': File exists * Preparing ltmodem module make HOSTCC=i686-pc-linux-gnu-gcc CROSS_COMPILE=i686-pc-linux-gnu- LDFLAGS= KERNEL_DIR=/usr/src/linux module make -C /usr/src/linux SUBDIRS=/var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/work/ltmodem-2.6-alk-9 modules make[1]: Entering directory `/usr/src/linux-2.6.31-gentoo-r6' CC [M] /var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/work/ltmodem-2.6-alk-9/lt_modem.o /var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/work/ltmodem-2.6-alk-9/lt_modem.c: In function 'lt_pcibios_read_config_byte': /var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/work/ltmodem-2.6-alk-9/lt_modem.c:68: error: implicit declaration of function 'pci_find_slot' /var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/work/ltmodem-2.6-alk-9/lt_modem.c:68: warning: initialization makes pointer from integer without a cast /var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/work/ltmodem-2.6-alk-9/lt_modem.c: In function 'lt_pcibios_read_config_word': /var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/work/ltmodem-2.6-alk-9/lt_modem.c:69: warning: initialization makes pointer from integer without a cast /var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/work/ltmodem-2.6-alk-9/lt_modem.c: In function 'lt_pcibios_read_config_dword': /var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/work/ltmodem-2.6-alk-9/lt_modem.c:70: warning: initialization makes pointer from integer without a cast /var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/work/ltmodem-2.6-alk-9/lt_modem.c: In function 'lt_pcibios_write_config_byte': /var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/work/ltmodem-2.6-alk-9/lt_modem.c:71: warning: initialization makes pointer from integer without a cast /var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/work/ltmodem-2.6-alk-9/lt_modem.c: In function 'lt_pcibios_write_config_word': /var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/work/ltmodem-2.6-alk-9/lt_modem.c:72: warning: initialization makes pointer from integer without a cast /var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/work/ltmodem-2.6-alk-9/lt_modem.c: In function 'lt_pcibios_write_config_dword': /var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/work/ltmodem-2.6-alk-9/lt_modem.c:73: warning: initialization makes pointer from integer without a cast make[2]: *** [/var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/work/ltmodem-2.6-alk-9/lt_modem.o] Error 1 make[1]: *** [_module_/var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/work/ltmodem-2.6-alk-9] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.31-gentoo-r6' make: *** [module] Error 2 * * ERROR: net-dialup/ltmodem-2.6.9-r1 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3455: Called linux-mod_src_compile * environment, line 2655: Called die * The specific snippet of code: * eval "emake HOSTCC=\"$(tc-getBUILD_CC)\" CROSS_COMPILE=${CHOST}- LDFLAGS=\"$(get_abi_LDFLAGS)\" ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS} " || die "Unable to emake HOSTCC="$(tc-getBUILD_CC)" CROSS_COMPILE=${CHOST}- LDFLAGS="$(get_abi_LDFLAGS)" ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS}"; * The die message: * Unable to emake HOSTCC=i686-pc-linux-gnu-gcc CROSS_COMPILE=i686-pc-linux-gnu- LDFLAGS= KERNEL_DIR='/usr/src/linux' module * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/log/portage/net-dialup:ltmodem-2.6.9-r1:20100107-143401.log'. * The ebuild environment file is located at '/var/tmp/portage/net-dialup/ltmodem-2.6.9-r1/temp/environment'. * >>> Failed to emerge net-dialup/ltmodem-2.6.9-r1, Log file: >>> '/var/log/portage/net-dialup:ltmodem-2.6.9-r1:20100107-143401.log' $ emerge --info Portage 2.1.6.13 (default/linux/x86/10.0/desktop, gcc-4.3.4, glibc-2.9_p20081201-r2, 2.6.31-gentoo-r6 i686) ================================================================= System uname: Linux-2.6.31-gentoo-r6-i686-Intel-R-_Pentium-R-_III_Mobile_CPU_1000MHz-with-gentoo-1.12.13 Timestamp of tree: Thu, 24 Dec 2009 20:30:02 +0000 app-shells/bash: 4.0_p35 dev-java/java-config: 2.1.9-r2 dev-lang/python: 2.6.4 dev-util/cmake: 2.6.4-r3 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.63-r1 sys-devel/automake: 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -Os -pipe -fomit-frame-pointer -mfpmath=sse" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=pentium3 -Os -pipe -fomit-frame-pointer -mfpmath=sse" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps y" FEATURES="distlocks fixpackages protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LDFLAGS="-Wl,-O1" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac aalib acpi alsa ass audiofile berkdb bwscheduler bzip2 cairo caps cdio cjk consolekit cracklib crypt css cups cxx dbus dga dhcp directfb downloadorder dri dvd dvdnav encode exif expat fam fbcon ffmpeg flac gcj ggi gif glibc-omitfp gmp gphoto2 gpm gstreamer hal handbook hardcoded-tables iconv idea imagemagick imap imlib infowidget ipfilter ipv6 jabber javascript jbig joystick jpeg kde lcms libcaca libnotify libwww live lm_sensors logviewer mad matroska mbox memlimit mmx mmxext mng mp3 mpeg mudflap mysql nas ncurses network nls no-old-linux nodrm nptl nptlonly ntp ogg opengl openmp oscar osdmenu pcre pdf perl pm-utils png qt3support quicktime readline rss rtc samba scanfolder scanner sdl search sensord shm silc smtp sndfile speex spell sse ssl stats svg sysfs tcpd theora threads threadsafe tiff timidity tremor truetype unicode upnp usb userlocales vcd vorbis webinterface wifi x86 xcb xinerama xml xorg xv xvid yahoo zlib zrtp" ALSA_CARDS="intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CAMERAS="ptp2" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="savage" Unset: CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Created attachment 215669 [details, diff] package of patches posted to linmodems.org mailing list Very coincidentally, I just discovered (on the mailing list) that someone has been working to update this driver. You can read about his efforts in the messages at the bottom of this page (the ones with the subject of [PATCH n/9]): http://linmodems.org/cgi-bin/ezmlm-cgi?1:iis:35527:201001 I have gathered up all of his patches, and will attach them to this bug.
Created attachment 215805 [details, diff] Updated patch Not paying enough attention when I originally did this. Two of the nine patches apply only to >=2.6.32 kernels, so I split the aggregate patch into two parts (and cleaned up the directories in the patch, as well).
Created attachment 215806 [details, diff] Updated patch (needed ONLY for 2.6.32 and later kernels).
Created attachment 215809 [details] Semi-working ebuild I have updated the ebuild so the modules at least compile and install. :) There are still a few problems: 1. No check for a 2.6.32 or later kernel (which requires the second patch). 2. The modem is now at /dev/ttySV0 (not /dev/ttySLTM0), which requires updates for the script checking for udev, the elog entry, and the ltmodem_udev file that gets put into /etc/udev/rules.d/ 3. The Makefile uses the running kernel "KRELEASE = $(shell uname -r)" instead of the one linked to /usr/src/linux.
Created attachment 215898 [details] ltmodem-20090420.ebuild The following check for for 2.6.32 and apply patch is now in this ebuild. 1. No check for a 2.6.32 or later kernel (which requires the second patch). The following are TODO: 2. The modem is now at /dev/ttySV0 (not /dev/ttySLTM0), which requires updates for the script checking for udev, the elog entry, and the ltmodem_udev file that gets put into /etc/udev/rules.d/ 3. The Makefile uses the running kernel "KRELEASE = $(shell uname -r)" instead of the one linked to /usr/src/linux The device udev naming of ttySV0 seems to be a ltmodem (upstream) source code issue, same with the Makefile using /usr/src/linux. I can also verify this driver seems to work fine & is ready to be pushed into Portage. (I'm sure if the above last two are really needed, others will chip-in & fix if they're really needed to be fixed... but I doubt it. ;-)
Additional Note: For some reason, could be just flaky h/w -- ie. works sometimes and sometimes doesn't work -- but this patched build ignores the kernel boot parameters "nosmp" and "maxcpus=0" entirely. (Already known, ltmodem fails to work with a SMP enabled kernel period.) In the past, I think I've been able to use those parameters into fooling ltmodem to work on my generic rolled kernel on my single CPU laptop. Then again, my memory could be flawed here and I rebuilt the kernel without SMP in the past to get it working.
Martian ebuild (Bug #285016) conflicts & seems to prevent ltmodem from finding & creating the the ttyS* device file. Seems like a nobrainer for a kernel dev, but likely overlooked. I also added "noapic" to kernel boot parameters and just rmmod martian_dev and then reloaded the ltmodem module and ltmodem found & created the /dev/ttyS* device file. I doubt "noapic" is needed, but won't be rebooting for sometime and wanted to make a note here for others with similar issues. Cheers. Seems ltmodem is up & running without having to rebuild my SMP generic rolled kernels.
(In reply to comment #5) > Created an attachment (id=215898) [details] > The device udev naming of ttySV0 seems to be a ltmodem (upstream) source code > issue, same with the Makefile using /usr/src/linux. Not sure how's it an 'issue', but it's clearly not udev involved here - see the ltmodem/v8250.c ;) Looks pretty much intended. <snip> dev_name = "ttySV", </snip>
BTW, some more complete patchset seems to be here: http://old.nabble.com/-PATCH-0-9--updates-for-ltmodem-20090420.tar.gz-td27022547.html; for 2.6.33+ this will likely need another patching for the moved autoconf.h stuff. Can't really check anything ATM though, since http://linmodems.technion.ac.il/ is unreachable.
OK, modified the martian-modem ebuild on Bug 285016 (added initscript etc.) - it compiles and works just fine on 2.6.32 and 2.6.33 kernels so you might give it a try. ;) Should work on multilib amd64 as well.
From my experience, martian only works with some modems from what I hear and not mine! (See supported device identification tags.) I have tried martian, and ltmodem is still my modem's method of choice for working. Although redundant, but this bug is a mess with unrelated items -- so opened Bug #308907 to isolate issues. So for kernel-2.6.32, we (Gentoo) should have the following files within Portage: net-dialup/files/ltmodem-20090420.patch net-dialup/files/ltmodem-20090420-kernel-2.6.32.patch net-dialup/ltmodem-20090420.ebuild Tested and works here on my Dell Inspiron 8100 modem. Bug #308907 takes care of kernel-2.6.33.
Created attachment 223093 [details] ltmodem-20090420.ebuild kernel_is doesn't like "> < =" symbols and only wants "ge, le, ..." letter evaluations. As such, a patch was only being applied to 2.6.32 and not >= 2.6.33 due to the symbols stated above. (Finicky kernel_is var check. Shouldn't we be using ${KV} instead?? Seems google doesn't find much on kernel_is and docs say more about ${KV}.)
Created attachment 223095 [details] ltmodem-20090420.ebuild Oops. Here's the *real* file with the *real* change mentioned within the last comment! (Geez. All this for changing two chars!)
Created attachment 223125 [details] ltmodem-20090420.ebuild Correct header.
I cant compile with the following bug: /var/tmp/portage/net-dialup/ltmodem-20090420/work/ltmodem/lib.c: In function 'memset': /var/tmp/portage/net-dialup/ltmodem-20090420/work/ltmodem/lib.c:14: error: implicit declaration of function '__memset' /var/tmp/portage/net-dialup/ltmodem-20090420/work/ltmodem/lib.c:14: warning: return makes pointer from integer without a cast /var/tmp/portage/net-dialup/ltmodem-20090420/work/ltmodem/lib.c: In function 'Get_PCI_BASE_ADDRESS_IO_MASK': /var/tmp/portage/net-dialup/ltmodem-20090420/work/ltmodem/lib.c:111: warning: large integer implicitly truncated to unsigned type make[2]: *** [/var/tmp/portage/net-dialup/ltmodem-20090420/work/ltmodem/lib.o] Error 1
Upstream looks dead and I cannot find any new version or it packaged on any recent distribution. Probably a candidate for removal. (Also would be nice to check if maybe recent kernels like 3.6 are already supporting this without external drivers)
I still have my Dell Inspiron 8100 laptop/notebook here, but rarely if ever use the modem. And when I do travel, am always struggling to use the @!#$@# modem. My only hope to use the modem is likely this package or martian. I don't think martian has also seen any activity. I would give this another 6-12 mos before removal as it's the only hope for modem users. If you've ever had to travel and stay at a motel without wifi with dialup the only choice, I'm sure you'll agree removing this too soon would be a bad idea. But you might be right, this package might be dieing or dead. Question is, when people go to hotels/motels without wireless, what do they use when the telephone is the only access to the Internet? Are laptop drivers for laptops now in the kernel? Is there another driver package?
Well, this is broken since a lot of older kernel versions, then, I think we have already waited enough time. Regarding alternatives to this driver, I have been googling a lot before commenting but couldn't obtain anything clear :S About what I do when I have no Wifi connection, I usually use my mobile phone network though bluetooth (and it's not a smartphone with Wifi ;))
Funny. My search results using Google were different then yours. ("laptop|notebook modem driver linux") Ltmodem was the 2nd returned result, aside from the LSI Modem driver which is likely for 64bit h/w while Ltmodem is for 32bit hardware. To conclude, it is likely people are now using a 64bit modem hardware vs. 32bit hardware. To also note, the linmodem/ltmodem is not completely dead as there is definitely mailing list activity as of this month describing "hsfmodem and hcfpcimodem drivers for Conexant chipsest modes are x86_64 competent" as dated the 2012.10.01 here: http://linmodems.org/cgi-bi/ezmlmcgi?1:mss:38259:201210:njaakgomacoikahkjdnf (or http://linmodems.org/cgi-bin/ezmlm-cgi/1) So, the reason this is still broken, is likely because $MS bought all 32bit hardware users to migrate to 64bit hardware, or were gamers wanting faster hardware. As for me, I'm just beginning to migrate to 64bit hardware due to all the scripting on the webpages, which noads/noscript plugins do not catch. Yanking packages that do not have maintainers, but still have users will have you loosing users. As for me, I just haven't had the time to fix the C code within this package. Also, if you'll notice, this package was broken since kernel-2.6.31 and vanilla-sources-2.6.16 is still in the Portage tree as stable, so this package is likely not broken if a user uses an older kernel. Might I suggest try yanking all kernels <2.6.31, and then try to close this bug?
Another option would be to push this ebuild to Sunrise along with any other questionable ebuilds. Bug #285016 details Martian as an option driver for these ltmodem based modem chips. Here's another solution to your delemma of trying to yank old/deprecated packages. Have the Portage package manager ping a server for counting number of "emerges per package" in order to more successfully detect dead packages. When a user emerges a package (remotely from developers server side), +1 for package_used. After ~360 days or MAX two years of a package (ie. package_used=0) not being emerged by any users, you can be 99.9% be assured of a package being officially dead and not being used. The only consideration would be for an admin not updating his/her system for more then that time -- which would be very very unlikely on Gentoo I think. I think this would require a separate database server side. The benefit, you'll close a whole lot more bugs automatically!
(In reply to comment #19) > Funny. My search results using Google were different then yours. > ("laptop|notebook modem driver linux") > Nice, you had more luck, I don't remember exact words I used for searching :S > Ltmodem was the 2nd returned result, aside from the LSI Modem driver which > is likely for 64bit h/w while Ltmodem is for 32bit hardware. To conclude, > it is likely people are now using a 64bit modem hardware vs. 32bit hardware. > > To also note, the linmodem/ltmodem is not completely dead as there is > definitely mailing list activity as of this month describing "hsfmodem and > hcfpcimodem drivers for Conexant chipsest modes are x86_64 competent" as > dated the 2012.10.01 here: > http://linmodems.org/cgi-bi/ezmlmcgi?1:mss:38259:201210:njaakgomacoikahkjdnf > (or http://linmodems.org/cgi-bin/ezmlm-cgi/1) Well, first link doesn't work for me, from the second, looks like we could download updates packages/sources from: http://www.linuxant.com/drivers/hsf/full/downloads.php right? > > So, the reason this is still broken, is likely because $MS bought all 32bit > hardware users to migrate to 64bit hardware, or were gamers wanting faster > hardware. As for me, I'm just beginning to migrate to 64bit hardware due to > all the scripting on the webpages, which noads/noscript plugins do not > catch. Yanking packages that do not have maintainers, but still have users > will have you loosing users. > But keeping broken packages in the tree can give even a worse appearance as people can think some package is supported while it's not ;) > As for me, I just haven't had the time to fix the C code within this > package. Also, if you'll notice, this package was broken since > kernel-2.6.31 and vanilla-sources-2.6.16 is still in the Portage tree as > stable, so this package is likely not broken if a user uses an older kernel. > > Might I suggest try yanking all kernels <2.6.31, and then try to close this > bug? No because, if I don't misremember, we are only supporting (for security updates and so) kernels newer than 3.0.x now (gentoo-sources), also running kernel-2.6.16 on a recent system will have multiple problems (for example, I think that you couldn't even run a recent udev version), but will CC kernel team to clarify why we are still providing such old vanilla-sources (In reply to comment #20) > Another option would be to push this ebuild to Sunrise along with any other > questionable ebuilds. > The point is not so where this package should live, the problem is that it doesn't compile/work with recent kernels (since 2.6.31). If somebody is able to provide patches or updated package to fix that problem, I could even proxy maintain him and keep the package in the tree with no problems: http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml > Bug #285016 details Martian as an option driver for these ltmodem based > modem chips. > > Here's another solution to your delemma of trying to yank old/deprecated > packages. > > Have the Portage package manager ping a server for counting number of > "emerges per package" in order to more successfully detect dead packages. > When a user emerges a package (remotely from developers server side), +1 for > package_used. After ~360 days or MAX two years of a package (ie. > package_used=0) not being emerged by any users, you can be 99.9% be assured > of a package being officially dead and not being used. The only > consideration would be for an admin not updating his/her system for more > then that time -- which would be very very unlikely on Gentoo I think. > Portage doesn't count that, but this enforces my point that it's even worse to offer a package to people that is broken for more than 2 years. > I think this would require a separate database server side. > > The benefit, you'll close a whole lot more bugs automatically!
Also, if you are able to find a package for a recent distribution with this bugs fixed, please don't hesitate to put the link here to try to see how are they fixing it
(In reply to comment #22) >> (or http://linmodems.org/cgi-bin/ezmlm-cgi/1) > Well, first link doesn't work for me, from the second, looks like we could Try the second link stated above. Should lead you to the index of October 2012's email list. > download updates packages/sources from: > http://www.linuxant.com/drivers/hsf/full/downloads.php Well, that's for hsfmodem (and hcfpcimodem) modem packages which are also in the main Portage tree and likely see much more use. However, they don't work for some modems such as mine (Agree Sys from memory here). Another simple fix, patch the ebuild (or somebody) to 2.6.9-r2 and require it to use <kernel-2.6.31 with a warning that the package is broken for >=kernels-2.6.31 and that it is a binary driver, pointing to this Bug #300047. Also, if a package is broken, it should be keyworded and with the associated Bug #.
For modems not supported by the hsf/hcf modem drivers, martian (found in a subdirectory of ltmodem's download) is a substitute. Looks like Ubuntu and Debian both have packages for martian available, Ubuntu looks to have the most recent activity as of 2012.05.10: https://launchpad.net/ubuntu/+source/martian-modem/20080625-2 And debian: http://packages.debian.org/squeeze/martian-modem-source (I used google to search "ltmodem|martian 2012 modem driver" without quotes. Seems like a really reliable search recipe to get the best most recent hits. ;-) So, *if* do get time, I'll try building something. (Usually I wait until I have to reside in a motel/hotel before tinkering with modem code and build scripts though.)
Regarding martian, I could be a proxy maintainer: http://www.gentoo.org/proj/en/qa/proxy-maintainers/ if anyone volunteers to maintain it
martian-modem ebuild, Bug 285016, has been updated and works on x86 here.
dropped
