Hardware Support
Hello! My apologies if this is the wrong email to contact for my issue. I would absolutely love to use Debian. I cannot do this however. The problem I am having is that you guys do not support my Wireless card. I went to the wiki and the wireless section and saw my wireless card on the list of supported cards, but I can't get any internet on my computer. I would just like if you guys could give support to the wireless card for the Asus X401U laptop. When I run it in a live CD, the command lspci reads back: *Network controller: Ralink corp. RT5390 Wireless 802.11n 1T/1R PCIe* If you guys could please give support for this card, I would be grateful and consider finally donating to you. Thank you. PS. I can't just install it via an Ethernet connection, I do not have access to an Ethernet connection. Thank you. -Sincerely, Ryan
Re: Hardware Support
On Tue, 19 Aug 2014 14:49:42 -0600 Ryan Burchett yurofspr...@gmail.com wrote: Hello! My apologies if this is the wrong email to contact for my issue. debian-u...@lists.debian.org would have been better. I would absolutely love to use Debian. I cannot do this however. The problem I am having is that you guys do not support my Wireless card. I went to the wiki and the wireless section and saw my wireless card on the list of supported cards, but I can't get any internet on my computer. I would just like if you guys could give support to the wireless card for the Asus X401U laptop. When I run it in a live CD, the command lspci reads back: *Network controller: Ralink corp. RT5390 Wireless 802.11n 1T/1R PCIe* You card is in fact already supported. The problem is, that the needed firmware to run it is not available during the installation. The only way I know around this is using a non-official installation image, with non-free firmware included. You can find them on http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current/. So if you have AMD64 you would need to use http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current/amd64/iso-cd/firmware-7.6.0-amd64-netinst.iso. Regards Sven signature.asc Description: PGP signature
Re: Hardware Support
On Tue, Aug 19 2014, Ryan Burchett wrote: Hello! My apologies if this is the wrong email to contact for my issue. I would absolutely love to use Debian. I cannot do this however. The problem I am having is that you guys do not support my Wireless card. I went to the wiki and the wireless section and saw my wireless card on the list of supported cards, but I can't get any internet on my computer. I would just like if you guys could give support to the wireless card for the Asus X401U laptop. When I run it in a live CD, the command lspci reads back: *Network controller: Ralink corp. RT5390 Wireless 802.11n 1T/1R PCIe* This seems to be supported by the Linux kernel out of the box. Which Debian version do you use? Why do you think that the card is not supported? Maybe you need to install additional packages such as firmware-ralink. Does dmesg command print something about that card? Best regards, -Michal -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878umknp70@steelpick.2x.cz
Re: Hardware Support
Sven Bartscher sven.bartsc...@weltraumschlangen.de (2014-08-19): On Tue, 19 Aug 2014 14:49:42 -0600 Ryan Burchett yurofspr...@gmail.com wrote: Hello! My apologies if this is the wrong email to contact for my issue. debian-u...@lists.debian.org would have been better. I would absolutely love to use Debian. I cannot do this however. The problem I am having is that you guys do not support my Wireless card. I went to the wiki and the wireless section and saw my wireless card on the list of supported cards, but I can't get any internet on my computer. I would just like if you guys could give support to the wireless card for the Asus X401U laptop. When I run it in a live CD, the command lspci reads back: *Network controller: Ralink corp. RT5390 Wireless 802.11n 1T/1R PCIe* You card is in fact already supported. The problem is, that the needed firmware to run it is not available during the installation. The only way I know around this is using a non-official installation image, with non-free firmware included. You can find them on http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current/. So if you have AMD64 you would need to use http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current/amd64/iso-cd/firmware-7.6.0-amd64-netinst.iso. See the installation manual: https://www.debian.org/releases/stable/amd64/ch02s02.html Beware, this feature is currently (known-)broken for the Jessie Alpha and Beta installers. Fixes are work in progress, though. Mraw, KiBi. signature.asc Description: Digital signature
Re: Etch and a half ( was Re: Bugfix/hardware support updates to stable releases?)
Tim Hull wrote: Anyway, I'm curious - is this still a legitimate consideration within Debian? Yes. If it were to be done, it would have to be December/Januaryish (any That's the plan. Thus, one wouldn't HAVE to upgrade, but new users and anyone standing to benefit from a new X/kernel (and possibly some other bugfixes) would want to consider using the new etch and a half. That's the plan. I think this idea would definitely benefit Debian - more people would be able to use it, and it would remain quite stable while still supporting the latest hardware. Yes. However, I think it's worth consideration - in my mind, this would fix Debian's greatest flaw Yes. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Etch and a half ( was Re: Bugfix/hardware support updates to stable releases?)
Hi all, The idea (mentioned in the prior thread) of having an Etch and a half release with an updated X/kernel/installer sounds EXACTLY like what I was hinting at. Backports are great, but having a supported, Debian-tested release that Debian can give to users with new/exotic hardware (which has better support in newer kernels/X releases) would be much better. I've been wrestling with Etch this summer on my MacBook (first generation!), and such a release would probably eliminate 99% of my complaints. Many Debian users are probably in the same boat - they don't mind having an old GNOME/Emacs/coreutils, but do mind being stuck with a kernel/X/installer that doesn't fully support their hardware. Anyway, I'm curious - is this still a legitimate consideration within Debian? If it were to be done, it would have to be December/Januaryish (any later and it would be too close to Lenny, unless of course Lenny is late). I figure that this would be a new branch - much in the same sense as sarge, etch, lenny, and sid are. Thus, one wouldn't HAVE to upgrade, but new users and anyone standing to benefit from a new X/kernel (and possibly some other bugfixes) would want to consider using the new etch and a half. I think this idea would definitely benefit Debian - more people would be able to use it, and it would remain quite stable while still supporting the latest hardware. Obviously, there are issues with the whole plan. For one, Debian would effectively have one more development branch - at least while any such and-a-half releases are developed. Effectively, this may end up looking like FreeBSD if such releases ever became common - albeit with less updates to the -stable branch. Furthermore, that would mean one more branch to support with security updates, upgrades to lenny (or lenny+1 if a lenny-and a half or a lenny-and-two-thirds are ever made), etc. These are all legitimate concerns. However, I think it's worth consideration - in my mind, this would fix Debian's greatest flaw in a way that's much better than the Ubuntuish we must release the full distro every 6 months approach. I'm curious to hear what everybody thinks regarding this whole concept, and I'd love to see Debian seriously consider this. Tim P.S. I know I am not a Debian developer, and I don't even have a package in the archive. I totally understand if you feel like it's a bit overreaching for me to bring things like this up. Rest assured that I appreciate everything Debian does, and I don't mean to detract from that AT ALL. I will say that I'd definitely test any and-a-half release if this ever came to fruition, and I'd work to help make it work out as I could. Heck, I've already been trying to work on making my own and-a-half to make Etch work fully on my MacBook :)
Re: Bugfix/hardware support updates to stable releases?
Le Fri, Aug 31, 2007 at 01:45:40AM +0100, Ben Hutchings a écrit : Only release-critical bugs are fixed in a stable release. You can get non-critical fixes for some packages by selective use of backports.org. Actually, I would be happy to hear opinions (in private if you think the question was trivial) on the follwing bug : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425508 Basically, IBM does not distribute anymore the tarballs supported by Etch's `java-package', wich means that the package becomes much less useful on powerpc. Would this kind of problem be enough for a stable update? My gut feeling is that if in order to use Etch one has to know how to use backports.net, it is not really Etch anymore... Have a nice say, -- Charles Plessy Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bugfix/hardware support updates to stable releases?
[Charles Plessy] Actually, I would be happy to hear opinions (in private if you think the question was trivial) on the follwing bug : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425508 Basically, IBM does not distribute anymore the tarballs supported by Etch's `java-package', wich means that the package becomes much less useful on powerpc. If the package is totally broken because it can't download an external file it needs, then that would be an RC bug, appropriate to fix in an etch point release. It looks as though only part of the functionality is broken, though, in that there are multiple tarballs you can download with java-package and only one fails, so the situation is less clear. I'd still consider it something fixable in etch, but I'm neither a RM nor a java-package maintainer. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Bugfix/hardware support updates to stable releases?
Hi, About a month ago I inquired here as to what Debian is doing regarding backported updates for stable releases. I did get some good responses to that thread, and I see why Debian doesn't expend too much energy making significant updates (like new GNOME, Xorg, etc etc) to *stable* releases - it would make them *un*stable. However, this still leaves the question of bugfixes and hardware support updates - things that, while not necessarily new-toolchain complexity, are mostly excluded by the current updates policy. As of now, there is no way for stable users to get many bugfixes or support for hardware released recently (basically anything since fall of last year) without resorting to installing testing/unstable packages or unsupported packages, all of which are not security supported. In my case, this has been quite a pain, as I have had to backport the kernel and about 5 auxiliary packages from testing/unstable to get reasonable functionality on my machine (a MacBook). I've also had to backport libgksu to get a fix for a problem which causes there to be an extremely high amount of CPU wakeups when gksu is used (as that kills battery life). Is there any plans to work on supporting such issues in the stable release, either through -volatile or the release updates? It would be nice to be able to - for instance - easily install using a new kernel with better driver support when running on a recent machine. This may not be a HUGE issue now, but it will be a year from now - witness the issues with Sarge and various SATA chipsets to see what can happen. If developers are working on this, I'd love to help as I can - it's by far the most significant issue holding me back from using any form of (GNU/)Linux. Yes, I know that users can always run testing or unstable, but not everybody wants that - things *do* break, and you end up with large-scale upgrades to the toolchain and core packages occurring quite often. That's fine for a Debian developer or power user, but not for everyone. Personally, *I* can run unstable, but would prefer to have a stable OS in addition to a development machine. Anyway, I'd love to hear what developers have to think on this Thanks once again for the great distribution, Tim
Re: Bugfix/hardware support updates to stable releases?
On Thu, 30 Aug 2007, Tim Hull wrote: I've also had to backport libgksu to get a fix for a problem which causes there to be an extremely high amount of CPU wakeups when gksu is used (as that kills battery life). The best thing for this is to use backports.org, and in the cases where a package isn't available (and you've made one) consider asking the maintainer to upload a backport (possibly using the patches you've already made). It would be nice to be able to - for instance - easily install using a new kernel with better driver support when running on a recent machine. The (continued?) ability of the development version of d-i to install stable would be very useful in allowing this to happen. [Though I suppose some machinations are required to get a kernel that actually works installed if the one distributed doesn't work.] Don Armstrong -- The game of science is, in principle, without end. He who decides one day that scientific statements do not call for any further test, and that they can be regarded as finally verified, retires from the game. -- Sir Karl Popper _The Logic of Scientific Discovery_ §11 http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Bugfix/hardware support updates to stable releases?
There are plans for an etch + 1/2 release which would update the kernel and X server to support newer hardware. I don't what the status or timetable for this is.\ This would be great. I'm curious who is working on it... Why not use backports.org? Well, none of what I need is there. (I guess the kernel is, but it's only 2.6.21 and I *need* 2.6.22). It's also unofficial, so it's not something that a user buying a new machine would really want to use as a long term solution. Only release-critical bugs are fixed in a stable release. You can get non-critical fixes for some packages by selective use of backports.org. It seems like it would be good to have all fixes that can be done without disruption... Ben. -- Ben Hutchings When you say `I wrote a program that crashed Windows', people just stare ... and say `Hey, I got those with the system, *for free*'. - Linus Torvalds
Re: Bugfix/hardware support updates to stable releases?
On Thu, 2007-08-30 at 20:05 -0400, Tim Hull wrote: Hi, About a month ago I inquired here as to what Debian is doing regarding backported updates for stable releases. I did get some good responses to that thread, and I see why Debian doesn't expend too much energy making significant updates (like new GNOME, Xorg, etc etc) to *stable* releases - it would make them *un*stable. However, this still leaves the question of bugfixes and hardware support updates - things that, while not necessarily new-toolchain complexity, are mostly excluded by the current updates policy. As of now, there is no way for stable users to get many bugfixes or support for hardware released recently (basically anything since fall of last year) without resorting to installing testing/unstable packages or unsupported packages, all of which are not security supported. There are plans for an etch + 1/2 release which would update the kernel and X server to support newer hardware. I don't what the status or timetable for this is. In my case, this has been quite a pain, as I have had to backport the kernel and about 5 auxiliary packages from testing/unstable to get reasonable functionality on my machine (a MacBook). Why not use backports.org? I've also had to backport libgksu to get a fix for a problem which causes there to be an extremely high amount of CPU wakeups when gksu is used (as that kills battery life). Is there any plans to work on supporting such issues in the stable release, either through -volatile or the release updates? snip Only release-critical bugs are fixed in a stable release. You can get non-critical fixes for some packages by selective use of backports.org. Ben. -- Ben Hutchings When you say `I wrote a program that crashed Windows', people just stare ... and say `Hey, I got those with the system, *for free*'. - Linus Torvalds signature.asc Description: This is a digitally signed message part
Re: Bugfix/hardware support updates to stable releases?
On Thu, Aug 30, 2007 at 09:02:32PM -0400, Tim Hull wrote: There are plans for an etch + 1/2 release which would update the kernel and X server to support newer hardware. I don't what the status or timetable for this is.\ This would be great. I'm curious who is working on it... There was a BOF about it at debconf this year where we discussed a lot of the details. The video of that BOF is located at [0]. I haven't heard anything about it since then though. - David Nusinow [0] http://meetings-archive.debian.net/pub/debian-meetings/2007/debconf7/low/273_Etch_and_12_BOF.ogg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376347: ITP: ctserver and vpb-driver -- Voicetronix telephony hardware support and ctserver middleware
Package: wnpp Severity: wishlist Owner: Ron [EMAIL PROTECTED] * Package names : ctserver and vpb-driver Upstream Author : Voicetronix [EMAIL PROTECTED] * URL : http://www.voicetronix.com.au/ * License : (GPL, LGPL) Programming Lang: (C, C++, Perl) Description : Voicetronix telephony hardware support and ctserver middleware I'm presently preparing packages to support voicetronix hardware, and the (generic) computer telephony libraries developed on top of it. Take control of your phone from software, or your software from a phone. See the url above for the full blurb. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
