I'm Tom Poplawski, I've built many of the ltmodem rpm's for mandrake prior to mandrake 9.0 (when I switched to Gentoo!) I'm familiar with the requirements to get the ltmodem working and do have a laptop which I test and depend on the ltmodem driver. I tried my hand at a ltmodem ebuild. This is ebuild works for me. Since gentoo is not supported by the build some compromises have to be made. I will feedback these changes to the developers so ltmodem will directly support gentoo in the future. The module will build properly with ./configure make make install, but the ltinst2 script and build_module fails to do the right thing so that has to be done manually. My changes License - I didn't change this but made a comment that the binary lt_modem module is Agere Sys Inc proprietary. All else is GPL. Added Depend - virtual/linux-sources - Sources must be configured and present in order to build the module. src_compile - ./build_module is the proper way to build the module. Can be bypassed but you will risk the wrath of the developers fielding the same bug reports this script was designed to prevent. Two changes made to build_module - changed make -e to make or else won't build on gentoo because of the environment overrides. Exporting FAST=1 means not having to press enter during the build. Except for a recent warning that if you build the kernel with one gcc ver and build the module with another you may crash your system because of the gcc 3.x/2.x incompatability. The developers feel this warning shouldn't be bypassed. I left in the replacement of read -p -> echo to bypass this one pause. I left these changes separate to make it obvious and allow easy removal of either as the build script version updates. src_install - copied two files into etc/modules.d and etc/devfs.d that automate the insertion of modules on demand and the creation of the symlink to /dev/modem on demain. This is the best part of my changes. Everything should just work with out any setup besides your isp details. pkg_postinstall - Sent -HUP to devfsd to reread new config. Run update-modules to add alias for ltmodem modules. Set einfo to let user know to use /dev/modem to access modem. Post install doc needed only if probelms. Not needed for normal installs now. pkg_postrm - Added for consistency. Send -HUP to devfsd and run update-modules after removal of ltmodem config files. But config files not removed because of config protection in /etc/ directory. Leaving these in the system could cause problems in rare cases - if user gets new normal modem but leaves old ltmodem installed. LTmodem will still take /dev/modem. Removing them during a version update could also cause problems. I don't know how to solve this. I feel the /etc changes should be removed during unmerge unless just a version upgrade. Since most user won't have two modems installed this shouldn't be much of a problem in the field. TODO - Remove all previous ltmodem versions. Previous versions of ltmodem are not gcc 3.0 compatible. Yes, they do work but could cause system crashes. This new version contains gcc 3.x and gcc 2.x binary modules and selects the proper one to use. Also - Could add depend for ppp and make sure kernel config has proper ppp options to prevent many bug reports.
Created attachment 7619 [details] ltmodem-8.26_alpha9-r1.ebuild
glad to know some of it was correct ;) i havent had a modem to test with ... ive added your changes to cvs, thanks http://cvs.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-x86/net-dialup/ltmodem/ltmodem-8.26_alpha9-r1.ebuild?rev=1.1&content-type=text/vnd.viewcvs-markup
Ebuild doesn't work, missed a change - maybe I rambled on too much last time :-) In pkg_postinst() left out HUP to devfsd. Without the HUP devfsd won't read config files untill next reboot - therefore, ltmodem won't work untill next reboot. The only way to get devfsd to re-read config that I'm aware of is to send HUP signal using "killall -HUP devfsd". From the devfsd man SIGNALS devfsd responds to signals in a variety of ways: SIGHUP The configuration file is re-read and any shared objects are reloaded. Then the mounted device tree is scanned and synthetic REGISTER events are generated for each leaf node. From man killall killall sends a signal to all processes running any of the specified commands. If no signal name is specified, SIGTERM is sent. Signals can be specified either by name (e.g. -HUP) or by number (e.g. -1). Therefore, "killall -HUP devfsd" will send the signal HUP to devfsd causing it to re-read config files. Works for me. Without the HUP, I get the error "/dev/modem doesn't exist" untill I reboot or send the HUP signal to devfsd myself. Please fix this. Thanks again for the quick response, glad I could help. Tom
what I don't understand is: what is your ebuild doing that mine (7805) wasn't already doing at least as well if not better (eg HUP). This is not meant in an unfriendly way. I just don't get it.
i didnt add the killall since current kernmodules dont use it ... refer to nvidia-kernel, emu10k1, and alsa-driver ... ill look at it some more when i have some free time
Denys, I never looked at your ebuild since its for an older ltmodem (ltmodem-8.22) and a newer ebuild existed in portage. If I'd known your ebuild was still maintained I would have started there. Why didn't you update to the later build scripts? I realize that the core code may not have changed, but I've worked with the developers in the past and updates to there build scripts are important to keep bug reports down. -------------------------------------------------------------------------- SpanKY The killall is needed by the device filesystem driver (devfs). My ebuild drops new config files for devfs but they won't be read until devfs is restarted by reboot or -HUP. See copy of man file in my above comment. With these config files, devfs will create the link from the ltmodem to /dev/ltmodem on demand. Without the killall, The ebuild doesn't work untill you reboot... Most users will have given up by then. I'll look at deny's build and see what the difference is. Thanks for the reply's, I'm just trying to help out and I appreciate everyone here!
*** This bug has been marked as a duplicate of 7805 ***
just for information, my ebuild (7805) is not for an older release of ltmodem, rather it started with an older release and a new ebuild was added as a newer attachment for the newer release of ltmodem. Thus the original title of the submission may now be misleading. Cheers,
4 months with no bug reports or other reported problems with ltmodem ebuild - could this be marked stable? Tom
done
