[gentoo-dev] RTL8187B don't work on 2.6.26, but worked on 2.6.24
Hi, I just want to know, what happen with 2.6.26 kernel sources? I've installed (compiled and copy all KO's to kernel modules directory, run init script loading modules) of RTL-8187B Wireless Card but error occured: * Loading REALTEK Wireless (8187b) drivers ... Loading modules insmod: error inserting '/lib/modules/2.6.26-gentoofbscreen/kernel/net/ieee80211_crypt_wep-rtl.ko': -1 Unknown symbol in module insmod: error inserting '/lib/modules/2.6.26-gentoofbscreen/kernel/net/ieee80211_crypt_tkip-rtl.ko': -1 Unknown symbol in module insmod: error inserting '/lib/modules/2.6.26-gentoofbscreen/kernel/net/ieee80211_crypt_ccmp-rtl.ko': -1 Unknown symbol in module insmod: error inserting '/lib/modules/2.6.26-gentoofbscreen/kernel/net/ieee80211-rtl.ko': -1 Unknown symbol in module insmod: error inserting '/lib/modules/2.6.26-gentoofbscreen/kernel/net/r8187.ko': -1 Unknown symbol in module Starting network interface WLAN0 wlan0: ERROR while getting interface flags: No such device Scanning networks to connect wlan0 Interface doesn't support scanning. This things started after updating to 2.6.26 from 2.6.24. My last kernel used this drivers without any errors. What's wrong? MESSAGES: -- Aug 31 13:30:08 thea r8187: Unknown symbol ieee80211_wx_get_mode Aug 31 13:30:08 thea r8187: Unknown symbol ieee80211_wx_set_mode Aug 31 13:30:08 thea r8187: Unknown symbol ieee80211_wx_get_essid Aug 31 13:30:08 thea r8187: Unknown symbol ieee80211_get_beacon Aug 31 13:30:08 thea r8187: disagrees about version of symbol dev_kfree_skb_any Aug 31 13:30:08 thea r8187: Unknown symbol dev_kfree_skb_any Aug 31 13:30:08 thea r8187: Unknown symbol ieee80211_wpa_supplicant_ioctl Aug 31 13:30:08 thea r8187: Unknown symbol ieee80211_wx_get_scan_rtl Aug 31 13:30:08 thea r8187: disagrees about version of symbol register_netdev Aug 31 13:30:08 thea r8187: Unknown symbol register_netdev Aug 31 13:30:08 thea r8187: disagrees about version of symbol dev_alloc_skb Aug 31 13:30:08 thea r8187: Unknown symbol dev_alloc_skb Aug 31 13:30:08 thea r8187: Unknown symbol ieee80211_wx_set_rawtx Aug 31 13:30:08 thea r8187: Unknown symbol ieee80211_softmac_stop_protocol Aug 31 13:30:08 thea r8187: Unknown symbol ieee80211_stop_queue_rtl Aug 31 13:30:08 thea r8187: Unknown symbol ieee80211_is_54g Aug 31 13:30:08 thea r8187: Unknown symbol ieee80211_wx_get_rate Aug 31 13:30:08 thea r8187: Unknown symbol ieee80211_wx_set_scan Aug 31 13:30:08 thea r8187: Unknown symbol ieee80211_wx_get_wap Aug 31 13:30:08 thea r8187: Unknown symbol ieee80211_wx_get_name_rtl Aug 31 13:30:08 thea r8187: disagrees about version of symbol netif_carrier_off Aug 31 13:30:08 thea r8187: Unknown symbol netif_carrier_off Aug 31 13:30:08 thea r8187: Unknown symbol ieee80211_is_shortslot Aug 31 13:30:08 thea r8187: Unknown symbol ieee80211_rx_rtl Aug 31 13:30:08 thea r8187: Unknown symbol ieee80211_wake_queue_rtl Aug 31 13:30:08 thea r8187: Unknown symbol ieee80211_wlan_frequencies Aug 31 13:30:08 thea r8187: Unknown symbol free_ieee80211_rtl Aug 31 13:30:08 thea r8187: Unknown symbol ieee80211_softmac_start_protocol Aug 31 13:30:08 thea r8187: Unknown symbol ieee80211_wx_get_freq Aug 31 13:30:08 thea /etc/init.d/realtek[6519]: ERROR: realtek failed to start signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] What are blocks used for?
Donnie Berkholz pisze: On 06:24 Wed 16 Apr , Ciaran McCreesh wrote: What all are blocks used for? a) Marking that two unrelated packages are mutually incompatible at runtime because they happen to collide, for example on a commonly named executable. b) Marking that two related implementations are mutually incompatible at runtime because they both provide the same binary. c) Marking that a file that used to be provided by one package is now provided by another package that is either depending upon or depended upon by the original package. d) Marking that a package has been moved into another package. Are there any other uses? A slight tweak that you may have already considered: a single package is split into multiple packages with a metabuild (named the same as the original single package) in a newer version -- for example, modularized X. For future EAPIs, being able to tell the package manager that your block is of one of the types above will help the package manager smooth out the upgrade path for users. For example, for class d) blocks such as the recent coreutils / mktemp mess, the package manager can suggest to the user to install the new package and then uninstall the old package, rather than forcing the user to uninstall the old package by hand (possibly leaving their system without critical utilities) and then install the new package. I strongly suspect that in many (but not all) cases the package manager could be making users' lives a lot easier than it currently is... Sounds like a great idea. Thanks, Donnie My Prof from US used to say - if something is working good why we should replace it? When we do that we can be sent to the tree with bananas straighting proposition by OS. In PL: możemy być wysłani na drzewo z propozycją prostowania bananów. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] What are blocks used for?
Bo Ørsted Andresen pisze: On Wednesday 16 April 2008 09:56:04 Mateusz A. Mierzwiński wrote: My Prof from US used to say - if something is working good why we should replace it? When we do that we can be sent to the tree with bananas straighting proposition by OS. I think it has been made quite clear in this thread that the current solution isn't working good. Look at the cases where people mistakenly uninstalled coreutils instead of mktemp. Not to mention the fact that uninstalling mktemp before upgrading coreutils is indeed the wrong solution. So why not to send on screen info about what to do rather then ERROR? This will only make problem with question What to install to get working gentoo?. Maybe emerge should be updated by something like INFO about error? Like that - If emerge found TXT/HTML/MAN file in package directory in portage it should display it when error occurred. This makes more easy to get some help without package granulation changes. like: TREE: /usr/portage/net-misc/asterisk-chan_unicall +- asterisk-chan_unicall-0.0.3_pre9.ebuild +- ChangeLog +- Manifest +- metadata.xml +- errorhelp-info.bz2 Where errorhelp-info.bz2 is manpage with errors information and repair infos. I think this is good idea. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] What are blocks used for?
Ciaran McCreesh pisze: On Wed, 16 Apr 2008 09:56:04 +0200 Mateusz A. Mierzwiński [EMAIL PROTECTED] wrote: My Prof from US used to say - if something is working good why we should replace it? When we do that we can be sent to the tree with bananas straighting proposition by OS. Blocks do not work: * It's often not obvious what the user's supposed to do to resolve a block. * Once the user has worked out how to resolve the block correctly, it's often hard to do so since resolving some blocks is best done by forcibly ignoring the block, doing the install and then doing the uninstall. * It's often not obvious why a block is even there. * They force the user to do a lot of work that isn't really necessary. The package manager can be told how to resolve the block in many cases, and the package manager can, with the user's permission, do all the work is itself. Yes, You have right but I have thinking about something like OPTION for emerge or switch to enable that function. Emerge could provide two options of working - with replace and with sending error. Maybe switch like --force-install? -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: What are blocks used for?
Duncan pisze: Mateusz A. Mierzwiński [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 16 Apr 2008 10:18:37 +0200: Yes, You have right but I have thinking about something like OPTION for emerge or switch to enable that function. Emerge could provide two options of working - with replace and with sending error. Maybe switch like --force-install? RTFM as they say, and ask on the user list if you still don't understand. This is a devel list not a user help list. The option (in portage anyway) has been there for some time. And what user list will make if this is post for adding something to emerge mechanism? Users should do that or devs? -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: What are blocks used for?
Marijn Schouten (hkBst) pisze: Hello Mateusz A. MierzwiDski, I really appreciate your trying to help, but your command of the English language is such that I and others have a lot of trouble making sense out of what you write. Perhaps you should consider that you also have problems understanding Ciaran's proposal because of this and refrain from commenting further. Distrowatch page rankings are essentially noise. We continue to have between 900 and 1000 users in #gentoo. Try ranking that. Thank you, Marijn Hi Marijn, I just want to know that Gentoo will be usable for me and my client's that I provide Gentoo Linux support. I recommending Gentoo whatever I can, but when I see what happens than I starting to worry. Mateusz M. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] What are blocks used for?
Richard Freeman pisze: Bo Ørsted Andresen wrote: On Wednesday 16 April 2008 10:15:16 Mateusz A. Mierzwiński wrote: So why not to send on screen info about what to do rather then ERROR? Please reread this entire thread. That's exactly what is being proposed. I'd go one step further. Don't tell the user what to do - just do it (when this is safe). Maybe have a REPLACES=app-foo/bar variable in ebuilds. That tells the package manager that the new package supersedes the old one - any version of the new package is considered higher in version than any version of the old package. Any cases where the new package overwrites files belonging to the old package are not detected as collisions. If set to auto-clean the package manger unmerges the old package after merging the new one. If the package manager sees the old package in world it will act like the new package is in world. Basically you treat it like an upgrade. This isn't always desirable, and in those cases you wouldn't use this functionality. Having an ebuild output a list of steps telling the user how to work around a package manager limitation is really a non-ideal solution. If a defined set of steps will always fix the issue, why not just do them? And maybe have an option/FEATURE to disable this behavior, just as you can disable auto-cleaning in portage. We don't tell users to manually clean out old versions of software, so why tell them to manually resolve other issues? Again, I'm not proposing this as a fix to ALL blocks. However, something like this could have made the mktemp mess a lot simpler. There would have been no issues to end users if the new coreutils silently collided with mktemp and triggered auto-removal of mktemp when the upgrade was done. This are good idea's. But i think about what You have written - when this is safe. I think this could make some troubles... -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Problem with latest portage!!!
Verifying ebuild Manifests... !!! Digest verification failed: !!! /usr/portage/sys-apps/net-tools/files/1.60_p20071202044231/0010-Patch-by-Tom-Duffy-tduffy-sun.com-to-teach-ifconfi.patch !!! Reason: Filesize does not match recorded size !!! Got: 5946 !!! Expected: 5932 -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Problem with latest portage!!!
Mike Frysinger pisze: On Monday 14 April 2008, Mateusz A. Mierzwiński wrote: Verifying ebuild Manifests... !!! Digest verification failed: !!! /usr/portage/sys-apps/net-tools/files/1.60_p20071202044231/0010-Patch-by-To m-Duffy-tduffy-sun.com-to-teach-ifconfi.patch !!! Reason: Filesize does not match recorded size !!! Got: 5946 !!! Expected: 5932 the gentoo-dev mailing list is not a place for reporting bugs. we have a bugzilla for that; use it. -mike This should be sent to portage (as portage tree) mail group. I don't know what's address so I sent here with hope someone correct checksum's. To remove this problem need to delete (rm -Rv) /usr/portage/sys-apps/net-tools -- gentoo-dev@lists.gentoo.org mailing list
