This will allow usb_modeswitch to be triggered automatically from udev for appropriate devices.
Created attachment 396178 [details] usb_modeswitch.spec Updated spec file to work with 1.1.0 and the udev rules integration. The upstream makefile is a bit quirky, the spec file somewhat reflects that. Also, the tarball has been renamed to usb-modeswitch-version.tar.gz Aside from the udev integration, the database for supported devices has been extended so many newer devices will work that previously haven't.
An additional Requires for tcl is needed as I found out yesterday when testing on a different box.
Hi Peter, I have taken over the usb_modeswitch. I have upgraded the rpm in devel. My approach is to split the package in two parts the modeswitch and the data rpms. Would be great if you could go through that. Thanks.
Hi Huzaifa, Peter, if you have comments or questions regarding the original source package of usb-modeswitch (Makefile etc.), don't hesitate to contact me. The source pack of version 1.1.0 was configured in close cooperation with the maintainer of the Debian package to minimize the need of tampering around with the 'upstream tarball' when packaging. I'm neither a deb nor a rpm guru, so I will gladly accept your advice. BTW, the Debian package does the same split between data and binary. Josua (Author USB_ModeSwitch)
(In reply to comment #3) > I have taken over the usb_modeswitch. > I have upgraded the rpm in devel. thank you! Note that I can't test the package since the 3G modem wasn't actually mine, I had to set it up for a friend. not sure when I get my hands on the modem again. Just a comments regarding the spec file: define should be global these days. other than that, it looks good to me. (In reply to comment #4) > if you have comments or questions regarding the original source package of > usb-modeswitch (Makefile etc.), don't hesitate to contact me. I think the easiest would be to autotool the lot, that way dependency checking and the paths to install everything can be tweaked through configure options. It may seem irritating at first, but once the setup is there it needs very little maintainance. I'll send you the patches once I've finished with it.
(In reply to comment #5) > I think the easiest would be to autotool the lot, that way dependency checking > and the paths to install everything can be tweaked through configure options. > It may seem irritating at first, but once the setup is there it needs very > little maintainance. I'll send you the patches once I've finished with it. Well, as you may have guessed, I was shying away from autotool for this tiny project. But if you think packaging will be easier this way, I'll give it a try.
Ew, please don't propagate autocrap -- it really shouldn't be necessary.
Please update the package on fedora 13 as well, it still ships 1.0.5 which doesn't work for my huwaei e122. It works nicelly using rawhide rpms (version 1.1.0).
Yes, it seems that F-13 got missed in all that. Its in F-12 and rawhide which will create upgrade path issues as well.
Hmm yeah , will do F-13 tomorrow then, sorry for that :)
Speaking about updating, looks like 1.1.2 is out, with data package separated directly upstream.
(In reply to comment #11) > Speaking about updating, looks like 1.1.2 is out, with data package separated > directly upstream. Yes, i spoke with upstream about it and it resulted in the packages being split, i am going to package that soon (perhaps today if i have time ? ).
usb_modeswitch-data-20100418-2.fc13,usb_modeswitch-1.1.2-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/usb_modeswitch-data-20100418-2.fc13,usb_modeswitch-1.1.2-1.fc13
usb_modeswitch-1.1.2-1.fc12,usb_modeswitch-data-20100418-2.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/usb_modeswitch-1.1.2-1.fc12,usb_modeswitch-data-20100418-2.fc12
usb_modeswitch-data-20100418-2.fc13, usb_modeswitch-1.1.2-1.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update usb_modeswitch-data usb_modeswitch'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/usb_modeswitch-data-20100418-2.fc13,usb_modeswitch-1.1.2-1.fc13
usb_modeswitch-1.1.2-1.fc12, usb_modeswitch-data-20100418-2.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update usb_modeswitch usb_modeswitch-data'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/usb_modeswitch-1.1.2-1.fc12,usb_modeswitch-data-20100418-2.fc12
I set EnableLogging=1 in /etc/usb_modeswitch.conf, and in /var/log/usb_modeswitch_5-2:1.0 see: checking config: /etc/usb_modeswitch.d/19d2:2000 ! matched, now switching (running command: /usr/sbin/usb_modeswitch -I -W -c /etc/usb_modeswitch.d/19d2: 2000) But there is no /usr/sbin/usb_modeswitch, it is /usr/bin/usb_modeswitch.
The following patch for /lib/udev/usb_modeswitch helps: --- usb_modeswitch.orig 2010-04-18 16:30:04.000000000 +0300 +++ usb_modeswitch 2010-04-22 22:01:00.808171059 +0300 @@ -49,7 +49,7 @@ eval file delete d [glob -nocomplain /tmp/gsmmodem_*] set dbdir /etc/usb_modeswitch.d -set bindir /usr/sbin +set bindir /usr/bin set devList1 {} set devList2 {}
I chose /usr/sbin in the original configuration (upstream). Here is why: Programs using libusb have to be run as superuser. There is no point making it available to the normal user. A quote from the "Filesystem Hierarchy Standard" [1]: "Utilities used for system administration (and other root-only commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin." Libusb usually sits in /usr/lib, so /usr/sbin was the logical choice. Josua Dietze [1] http://www.pathname.com/fhs/pub/fhs-2.3.html
Indeed. Huzaifa, please don't move things from where upstream put them without a _very_ good reason. Which I can't see in this case. If you drop the usb_modeswitch-dir.patch in the current package, everything should work fine.
The reason why it is in /usr/bin is due to the fact that it was previously in there, when i took the package. Anyways i removed the patch. Also am packaging /etc/usb_modeswitch.setup which is needed for manual modeswitching.
usb_modeswitch-1.1.2-3.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/usb_modeswitch-1.1.2-3.fc13
usb_modeswitch-1.1.2-3.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/usb_modeswitch-1.1.2-3.fc12
usb_modeswitch-1.1.2-3.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update usb_modeswitch'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/usb_modeswitch-1.1.2-3.fc13
usb_modeswitch-1.1.2-3.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update usb_modeswitch'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/usb_modeswitch-1.1.2-3.fc12
Works OK now, thanks.
usb_modeswitch-1.1.2-3.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
usb_modeswitch-1.1.2-3.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
When doing yum update on F12: --> Finished Dependency Resolution Error: Package: usb_modeswitch-1.1.2-3.fc12.i686 (updates) Requires: usb_modeswitch-data You could try using --skip-broken to work around the problem
oops i forgot to push the data rpm, will do that today, sorry :)
F12 now OK, F11 still not.
(In reply to comment #31) > F12 now OK, F11 still not. Should be fixed now.