Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
Moins, On Tue, 2008-11-11 at 02:27 +, Vincenzo Ciancia wrote: > On 11/11/2008 Scott Kitterman wrote: > > > > I would encourage you (and others, you certainly aren't the only one) > > to hold > > your temper and if you can't say something helpful, just take your > > hands off > > the keyboard. Being angry, contemptuous, and disrespectful won't get > > your > > bugs fixed faster. What it will get you is yet another list with no > > developers on it and you upset you can't get in touch with them. > > > You are perfectly right, this went out of my control, and I appreciated > a lot the responses I got on various other issues in the past. I stop > now on the topic. > > The only seriously valid point for you developers in my e-mails - I > think - and the one I wanted to expose in the first e-mail I wrote - is > that we users really need a seriously maintained hardware database, and > a serious attention to all hardware related regressions, because you > can't change your hardware like you can change your software. This is > what from times to times leads me to a complete demotivation on keeping > supporting ubuntu - and I bet you as a developer care, not of me in > particular, but of the numbers. Ubuntu is so popular because developers > care about usability and understand what it is, but also because users > are openly advertising and supporting it as if it was The Salvation from > the Evil Microsoft. Don't loose this important advantage. Advocating Ubuntu doesn't mean you need to support it. Advocating in a company and propose a switch from MS Windows XP/Vista to Canonical+Ubuntu means, that you should have a point doing so. Software in general is not bug free, so mostly you need commercial support for your OS or other Software you are using. Canonical does provide Support for Ubuntu for You, when you want to pay it. If not, fix it yourself, or help us fixing it e.g. join the irc and point people to it. If people can't help you directly, because of not having the broken hardware, you can try to provide this hardware to the people (that's an example, and hey, this you can't do when you use MS Windows). > > If you start an officially endorsed hardware database with a forum for > comments and user-to-user support in launchpad etc, and keep an eye open > on regressions in hardware support, that should promptly be acknowledged > and put aside the relevant entries in the hardware database itself, and > that ideally should never be propagated to stable releases, but > _usually_ do, I am sure your user community will make a great job in > populating it. If you don't do that because of lack of manpower... I > understand and accept the reality. You know, there is more and more hardware on the market, old and new. And I never saw any hardware working out of the box which is quite new, not even on Windows. Most drivers for new hardware on Windows are broken...and believe me, asking the hardware vendor or creator, doesn't help to fix those drivers in time, not if you don't want to pay them. BTW, I do advocate Ubuntu in every company I'm working. And mostly I'm the cursed guy who is doing the support, too. You know what? If I can't fix it in time, I'll file a bug and I'm waiting. In the meantime, there are workarounds (e.g. using an external wifi card, using another graphics card driver etc.pp.) and most people are happy when they can use their computers, it doesn't matter how. Actually most people don't care about their special hardware they have in their laptops or desktop...they just want to work. TBH, if I really want to deploy Ubuntu as Desktop replacement, I'll call Canonical or one of their partners and order some special support contracts with developer support...it costs money, yes, but this should be in your budget for such a project. But in general, you shouldn't advocate things you can't handle. If you are not able to help people out of a bad situation, don't switch them..most likely people will not only hate the new OS, but they will hate you. If you really want to know which hardware is supported, you should read the vanilla kernel mailing list, because this is the most valuable source of finding out which hardware does work out of the box. If a distributor adds more goodies to the kernel, then be happy, but that doesn't mean, that it really works...even when the distributor puts the hardware on the list of supported hardware. Regards, \sh -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Anyone else lost hardware buttons after update from intrepid-proposed?
2008/11/13 (``-_-´´) -- Fernando <[EMAIL PROTECTED]> > Olá Mario e a todos. > > ===snip=== > > I never understood why the proposed rep is not pined down/back... > > -- > BUGabundo :o) > (``-_-´´) http://LinuxNoDEI.BUGabundo.net > Linux user #443786GPG key 1024D/A1784EBB > My new micro-blog @ http://BUGabundo.net > ps. My emails tend to sound authority and aggressive. I'm sorry in advance. > I'll try to be more assertive as time goes by... > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > > Because people that have enabled them have already taken the decision that they want to be guinea pigs for SRU's, and run software that might break their system. The same goes for backports (people that have enabled them have taken the decision themselves that they want to run the latest and greatest software). Pinning the repository is unnecessary because they are disabled by default anyway. It would make it practically useless to those of us who want to help test these packages in *-proposed, as we wouldn't automatically be notified of the updates which need testing. That would mean that people who wanted to help test would have to enable the repository, and then un-pin it too (or manually search for packages that need testing). Regards Chris -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
> If a distributor adds more goodies to the kernel, then be happy, but > that doesn't mean, that it really works...even when the distributor puts > the hardware on the list of supported hardware. > I hope this is not really the idea of the ubuntu developers on this topic, because if so, then I can really, really forget all my bugs, and go home happy. If the idea is that a trial-and-error process should be the normal way of using ubuntu (it is the way I use it every time I install it to other people), then just tell me. I think it's unbelievable how far things went in this direction. If this is considered normal and unharmful, there's clearly something that I didn't understand here. Vincenzo -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
Hi, On Thu, 2008-11-13 at 09:00 +, Vincenzo Ciancia wrote: > > If a distributor adds more goodies to the kernel, then be happy, but > > that doesn't mean, that it really works...even when the distributor puts > > the hardware on the list of supported hardware. > > > > I hope this is not really the idea of the ubuntu developers on this > topic, because if so, then I can really, really forget all my bugs, and > go home happy. If the idea is that a trial-and-error process should be > the normal way of using ubuntu (it is the way I use it every time I > install it to other people), then just tell me. I think it's > unbelievable how far things went in this direction. If this is > considered normal and unharmful, there's clearly something that I didn't > understand here. This is reality :) Really. Example: I bought an USB DTV Stick for terrestrial signals. The product I bought is supported regarding all sources I read (linuxdvb, kernel...) So, I bought my hardware, regarding all infos I had access to. What was the result? In Hardy, this stick didn't work, just because the hardware vendor changed one single chip revision. And what now? Regarding the Ubuntu Kernel + all other infos, I bought a product, which just had to work out of the box. But reality told me different. Good, that upstream (those guys from linuxdvb) heard about this issue, and some guy also had this stick at home and they produced a new driver release, but this wasn't in time for Hardy. So, even if you buy hardware which should be supported by any linux distro out there, because someone put it on a list, you can't be sure, that it's actually working. Noone can and will add all different revisions of hardware chip infos on a list. What you mostly get is: ATI Graphics Card -> supported NVidia Graphics Card -> Supported USB DTV Stick Made FooBar -> Supported And then you will realize, that your very old card is not really supported anymore, even if it's an ATI or Nvidia...You will even realize that the new NVidia GeForce 10 with 8TB of RAM won't be supported, because the drivers were not finished in time... And this is nothing which only happens on Ubuntu...this happens all the time with any other distro, too. Most likely, if you use server hardware, which doesn't change so many times over three years than desktop hardware, you will be more happy. That's why most distros are not supporting a desktop version of their enterprise release. Because Desktops are really a pain for users and devs regarding hardware support. Regards, \sh -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
RE: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
Apologies for breaking threading, i'm not subscribed to this list anymore, as the S/N ratio was too low. However, this part is interesting. Please CC me on any responses to this mail. Vincenzo writes: "2) Another bug affected me at random (WIFI), and there was nothing I could do about that, and it happened to me other times with other intel cards. I've not been clear perhaps, but the problem is that I was used to have my network card functioning, and one day it just left me without connection - after I moved abroad for one month, not after I upgraded. This is because intel's drivers mostly suck, there is no simpler explanation. They have tons of bugs and corner cases (I can support this by pointing at the number and gravity of LP bugs for them). I want to be able to rely and let others rely on ubuntu so we need to know what works and what not. 3) There are plenty of other hardware regressions by which I am affected and I feel like these should be a bit more acknowledged by developers. Because I can't be the only one." What I'd like to raise - how does one write such a database, when there is no clear-cut answer on whether this card, with this driver, works? Take the intel 3945 card, for example. Vincenzo says it doesn't work for him, under various modes. Various users on the forums have also mentioned that their systems don't work with these cards. However, other users on the forums, mailing lists, and a whole lot of the developers, including myself, have this card, and see that it works for them. I personally haven't seen this break since I upgraded to gutsy back at the UDS in Sevilla, 2007 (ie, pre-alpha 1), and I use WPA, which seems to be one of the areas of complaint, otherwise without problems. The bugs that affect everyone with a particular chipset are often acknowledged, particularly in the release notes. Maybe it would be nice to acknowledge that some people have problems with this card- but that's only some people. You'd be telling a whole lot of other people that their cards may not work, when they actually work just fine. Also, I'd be willing to bet that at least one person has a problems with *every* card in Ubuntu. Does it really make sense to acknowledge them all? How does one generalise that, in a paragraph or two, and it still be useful? Arguably, it would help if the relevant (i presume kernel) developers had access to some of these faulting cards - the ones that do break where people can reproduce it on site seem to get fixed quite quickly. But it's very hard to debug something where you don't have access (and it's quite hard to buy hardware to try to fix it, if only a smallish percentage of cards actually exhibit this buggy behaviour!) Thoughts? Just my 2c. Hobbsee signature.asc Description: OpenPGP digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
Sarah - this should make sense on its own, but it builds on an idea I suggested in https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-November/006250.html which you might provide a little background to this post. > 3) There are plenty of other hardware regressions by which I am affected > and I feel like these should be a bit more acknowledged by developers. > Because I can't be the only one." > > What I'd like to raise - how does one write such a database, when there > is no clear-cut answer on whether this card, with this driver, works? Since we're talking about regressions here, one solution would be to make downgrading as easy as upgrading, and to request an optional hardware profile immediately before a user up/downgrades. Spotting problematic hardware then becomes a relatively simple statistical problem: when a user gives their hardware profile ready for an upgrade, they can be informed "you have , users with were n% more likely than average to downgrade. Are you sure you want to continue?". - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
> Canonical does provide Support for Ubuntu for You, when you want to > pay > it. If not, fix it yourself, or help us fixing it e.g. join the irc > and > point people to it. If people can't help you directly, because of not > having the broken hardware, you can try to provide this hardware to > the > people (that's an example, and hey, this you can't do when you use MS > Windows). Nailed it. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
Am 13.11.2008 um 10:32 schrieb Stephan Hermann: > But reality told me different. Stephan, your points about the unfortunate truth are valid. Nevertheless, software quality is one of the keys to success. I've just filed the second bug where one of the Gnome applets segfaults in a standard situation. Many developers obviously code really sloppy, a la "it worked once in my situation, so it works always in all situations". Some developers even consider a segfault as a normal way to end the execution of an application. This is a more general observation of mine, this is ridiculous. While we can't "fix" developers, we can put more automatic helpers into place: - Keep Apport enabled even on stable releases. Hiding bugs doesn't help. While this doesn't fix bugs by it's self, it greatly helps to fix them after the fact (and timely educate developers about their practices). Additionally, this opens the door to get some automatic measure about the quality of drivers or other software. Count open bugs and you know what you roughly can expect. If you count too many of them, drop the hardware in the compatibility list. To keep more users happy: - Allow downgrades. This should help narrowing potential causes of the trouble. Ideally, there would be a big regression testing facility, like Wine has one. Each time a Wine developer fixes a bug, he's pushed to create a test for his case. These test cases are run automatically for each commited patch and pretty well avoid introducing a bug a second time. to add my $o.o2, MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Hardware regressions was (Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions))
On Thu, 13 Nov 2008 09:00:36 + Vincenzo Ciancia <[EMAIL PROTECTED]> wrote: > >> If a distributor adds more goodies to the kernel, then be happy, but >> that doesn't mean, that it really works...even when the distributor puts >> the hardware on the list of supported hardware. >> > >I hope this is not really the idea of the ubuntu developers on this >topic, because if so, then I can really, really forget all my bugs, and >go home happy. If the idea is that a trial-and-error process should be >the normal way of using ubuntu (it is the way I use it every time I >install it to other people), then just tell me. I think it's >unbelievable how far things went in this direction. If this is >considered normal and unharmful, there's clearly something that I didn't >understand here. Part of what goes on is that the details of a product change over time, where a specific part was made, or any number of things. So when one person says (to pick one example, this is true for all vendors) IW 3945 is broken and another says it's not, they probably don't have identical cards. We also have more than one kernel. Maybe it works with i386, but is broken with amd64. Use cases differ too. I have a laptop with IW 4965 and it works great for me. A lot of people reported problems on Intrepid with this card. As it happens, I am mostly (maybe always) on 802.11G networks. People with the problems have 802.11N (mostly anyway - see the other factors). Part of the trouble with a hardware database is what to put in it to make it reliable, yet searchable. So this is not an easy problem. Back in Edgy I remember spending a lot of time digging through wiki pages trying to figure out wifi. Clearly we need to do better with this, but I'm not sure exactly how. I think this may be a topic to take up with the QA team. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
Hi Markus, On Thu, 2008-11-13 at 11:56 +0100, Markus Hitter wrote: > Am 13.11.2008 um 10:32 schrieb Stephan Hermann: > > > But reality told me different. > > Stephan, your points about the unfortunate truth are valid. Sad, but true. > Nevertheless, software quality is one of the keys to success. > I've just filed the second bug where one of the Gnome applets > segfaults in a standard situation. Many developers obviously code > really sloppy, a la "it worked once in my situation, so it works > always in all situations". Some developers even consider a segfault > as a normal way to end the execution of an application. This is a > more general observation of mine, this is ridiculous. > > While we can't "fix" developers, we can put more automatic helpers > into place: > > - Keep Apport enabled even on stable releases. Hiding bugs doesn't > help. > > While this doesn't fix bugs by it's self, it greatly helps to fix > them after the fact (and timely educate developers about their > practices). Yes...this can help us, to shape applications which are running actually on the user's desktops, but doesn't prevent it from happening. If the bug is found after a release, it's already too late. Well, not too late to fix it in an upcoming release, but too late today. But here is a point: Why did the bug occur after the release first, or when it occurred during development, why nobody took care to fix it? And here are some answers (hopefully not all, but some, and mostly not correct): 1. The bug occurred after the release: a) The application in question is not used by a wide range of users. If it would have been used by a broader community, the bug would have occurred during development b) Nobody, using this software before release, was actually able to file a bug report to the distro bug tracker. That's not good. And this starts another flow of questions, but those I won't raise here. 2. The bug occurred during development, why wasn't it fixed by someone? a) There was no bug report, look at 1.b) b) Most likely the application package waits in the Universe/Multiverse pocket, and no non-paid/paid dev took care, because it's not important for the release goal and nobody was interested, because it's unsupported. c) The application is in one of the supported pockets (main/restricted), the core devs had it on the radar, but decided to take it as a regression which could be fixed later, and is not so important for the release in general. d) the bug is so difficult and non-trivial to reproduce, or to fix, and the bug was pushed upstream, and the distro team just have to wait for a fix or an answer. This is belongs to the application level so far. Coming to the more delicate kernel level: > > Additionally, this opens the door to get some automatic measure about > the quality of drivers or other software. Count open bugs and you > know what you roughly can expect. If you count too many of them, drop > the hardware in the compatibility list. As said in one of my mails: The problem here is, that some users with the hardware on a list don't have problems, but others have. Now, how can we determine what the difference between the hardware is, between those with and those without problems? This task is not easy. There needs to be input from the users with the non-working hardware. Most likely, that this information can be gathered with some magic commands on CLI, which is also provided by a nice developer. But user thinks: "Damn, this takes more time, more that I want to invest in this...this OS is crap...the devs are lazy bastards, because the hardware is on the list...but as I can see, it doesn't work, wait I'll tell them that on the ML or whereever". So, for the kernel devs or other devs in other parts of the distro, it's quite difficult sometimes to get the necessary infos, when people are not coming back and providing the infos about the hardware, or if they did, then they won't come back to test the fix, because they already installed another OS or switched back to something else. There are so many variables, which are playing a part, starting from non-working hardware revision to the decision: "Ok, this card is only 10 days old, most likely that there are not many people who are using it, we need to forget about this, during this release cycle, and yes, we screw the people who have this card, but the majority is not affected at all." to "Shit, we didn't even know that this wasn't working, yeah there was a report, but we didn't get the infos back we needed to investigate..shit happens, but shit happens all the time, let's document it". And in reality, only one or two newer revisions of chipset are not working anymore...but to get this revision it takes time to get the right info from the users. > > To keep more users happy: > > - Allow downgrades. This should help narrowing potential causes of > the trouble. This is something I don't understand. When I upgrade to a new
Apport in stable releases [was: Re: Do you really want developers to be on this list]
Markus Hitter [2008-11-13 11:56 +0100]: > While we can't "fix" developers, we can put more automatic helpers > into place: > > - Keep Apport enabled even on stable releases. Hiding bugs doesn't > help. We don't disable Apport in stable releases because we want to hide bugs. The reasons are, in descending importance: * core dumps potentially contain a lot of private/sensitive information which is almost impossible to check for a casual user. Yes, apport points out to not send a report if you did something private, and bugs are private by default, but still.. * During testing the development release we already get tons of crash reports, so we should already know (or even have fixed) the most common crashes. The others aren't really common, and hard to reproduce, etc., which is why we would not fix them in stable releases *anyway* (both from an SRU policy perspective, as well as being a manpower issue). * Collecting crash information and sending it to LP takes a lot of CPU, IO, and network bandwidth, and it doesn't make sense to waste all this, and create a sense of expectation that the crash will be fixed in a stable release, when we know upfront that it won't. > While this doesn't fix bugs by it's self, it greatly helps to fix > them after the fact (and timely educate developers about their > practices). Right, but we have more crashes in LP than we can ever keep up with, so there's enough fodder to report to upstreams, debug, and fix. :-) > Additionally, this opens the door to get some automatic measure about > the quality of drivers or other software. Count open bugs and you > know what you roughly can expect. If you count too many of them, drop > the hardware in the compatibility list. Hardware bugs are not automatically reported. Filing bugs manually (Help -> Report a bug, or using ubuntu-bug) still works normally in stable releases. We didn't disable that, nor was it ever discussed to do so. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
Stephan Hermann wrote: > > On Thu, 2008-11-13 at 11:56 +0100, Markus Hitter wrote: >> >> - Allow downgrades. This should help narrowing potential causes of >> the trouble. > > This is something I don't understand. > When I upgrade to a new release, I always think (or is it knowing): "Ok, > for the next 4 hours I'll sit in front of this computer, and I expect > something to break...because it's software made by people". If nothing > breaks, then I'm really surprised and happy. But when something breaks, > I already expected that. And when I find the cause for the breakage, > I'll try to fix it, AND/OR file a bug report about that issue. That's commendable practice, but the problem in Vincenzo's case was a hardware regression that would require upstream developer time in order to write a fix. An easy downgrade path would give users in that situation the opportunity to use a system that works while they're waiting. It also gives a communication channel to users that aren't technical enough to describe hardware problems - if we log hardware profiles when users up/downgrade, we can see which profiles correlate most strongly with downgrades, and use that to help guess which bug reports are one guy with a dodgy graphics card, and which are something more general. - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
2008/11/13 Andrew Sayers <[EMAIL PROTECTED]> > Stephan Hermann wrote: > > > > On Thu, 2008-11-13 at 11:56 +0100, Markus Hitter wrote: > >> > >> - Allow downgrades. This should help narrowing potential causes of > >> the trouble. > > > > This is something I don't understand. > > When I upgrade to a new release, I always think (or is it knowing): "Ok, > > for the next 4 hours I'll sit in front of this computer, and I expect > > something to break...because it's software made by people". If nothing > > breaks, then I'm really surprised and happy. But when something breaks, > > I already expected that. And when I find the cause for the breakage, > > I'll try to fix it, AND/OR file a bug report about that issue. > > That's commendable practice, but the problem in Vincenzo's case was a > hardware regression that would require upstream developer time in order > to write a fix. An easy downgrade path would give users in that > situation the opportunity to use a system that works while they're > waiting. It also gives a communication channel to users that aren't > technical enough to describe hardware problems - if we log hardware > profiles when users up/downgrade, we can see which profiles correlate > most strongly with downgrades, and use that to help guess which bug > reports are one guy with a dodgy graphics card, and which are something > more general. > >- Andrew > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > Surely trying to make a safe downgrade path risks introducing even more regressions on top of the original ones, and could be a significant amount of effort - effort that is better spent on fixing the original regressions. Creating a downgrade path seems like a lot of work for very little gain IMO. Regards Chris -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Anyone else lost hardware buttons after update from intrepid-proposed?
On Thu, 2008-11-13 at 00:07 +, (``-_-´´) -- Fernando wrote: > There is an huge risk in running with proposed. Well, "huge" might be overstating it a little bit > Those who run with them enable, should be also tracking them on LP. Thanks for the heads-up, but I know what I am doing :) I run proposed because I have no problem digging myself out of a hole and specifically to be able to help with issues before they hit users who are less experienced with shovels. If nobody ran proposed, its existence would not help much ... -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
On Thursday 13 November 2008 05:13, Andrew Sayers wrote: > Sarah - this should make sense on its own, but it builds on an idea I > suggested in > https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-November/006250 >.html > > which you might provide a little background to this post. > > > 3) There are plenty of other hardware regressions by which I am affected > > and I feel like these should be a bit more acknowledged by developers. > > Because I can't be the only one." > > > > What I'd like to raise - how does one write such a database, when there > > is no clear-cut answer on whether this card, with this driver, works? > > Since we're talking about regressions here, one solution would be to > make downgrading as easy as upgrading, and to request an optional > hardware profile immediately before a user up/downgrades. Spotting > problematic hardware then becomes a relatively simple statistical > problem: when a user gives their hardware profile ready for an upgrade, > they can be informed "you have , users with were n% > more likely than average to downgrade. Are you sure you want to > continue?". > Downgrading an entire system is never going to be reliable. It might be possible to take a snapshot of the system onto a suitable storage medium that one could restore to if needed. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
RE: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
On Thu, 2008-11-13 at 20:36 +1100, Sarah Hobbs wrote: > Take the intel 3945 card, for example. Vincenzo says it doesn't work > for him, under various modes. Various users on the forums have also > mentioned that their systems don't work with these cards. > > However, other users on the forums, mailing lists, and a whole lot of > the developers, including myself, have this card, and see that it works > for them. I personally haven't seen this break since I upgraded to > gutsy back at the UDS in Sevilla, 2007 (ie, pre-alpha 1), and I use WPA, > which seems to be one of the areas of complaint, otherwise without problems. In my experience, it does work fine with WPA. It's WEP that's the issue. It only works with WEP (properly) using iwconfig. If you use NetworkManager, the key will *never* be accepted. And if you use network-admin (gone in Intrepid), the key will be accepted, but it won't get an IP address. And yes, you're of course right about the issues with not having access to the hardware to fix it. I've overheard someone mutter "well if you'd send me some hardware, sure I could make it work..." I recall that the day I met Daniel Chen, he was showing up to an installfest so he could fix any sound bugs with actual, physical access to the hardware. -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
dissappearing sym link
Hi all , I've doned the asbestos pants On an upgrade from 8.04 to 8.10 the symlink from /usr/bin/gcc to /usr/bin/gcc-4.3 is not made. on a clean install of 8.10 its made. I verified it as well by reloading 8.04 and upgrading, and then do a clean install of 8.10. If I put that on the forums it will never get picked up and if its not a funny with this machine, carry to Ubuntu 10.0 -- Best wishes Richard Bown # Registered Linux User 36561 OS: Ubuntu 8.10, Intrepid, on AMD Dual Athlon 64 +4400: 8 GB RAM DDR2 Ham Call: G8JVM , QRA IO82SP, Interests Microwave # -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
On Thu, Nov 13, 2008 at 8:55 PM, Mackenzie Morgan <[EMAIL PROTECTED]> wrote: > On Thu, 2008-11-13 at 20:36 +1100, Sarah Hobbs wrote: >> Take the intel 3945 card, for example. Vincenzo says it doesn't work >> for him, under various modes. Various users on the forums have also >> mentioned that their systems don't work with these cards. >> >> However, other users on the forums, mailing lists, and a whole lot of >> the developers, including myself, have this card, and see that it works >> for them. I personally haven't seen this break since I upgraded to >> gutsy back at the UDS in Sevilla, 2007 (ie, pre-alpha 1), and I use WPA, >> which seems to be one of the areas of complaint, otherwise without problems. > > In my experience, it does work fine with WPA. It's WEP that's the > issue. It only works with WEP (properly) using iwconfig. If you use > NetworkManager, the key will *never* be accepted. And if you use > network-admin (gone in Intrepid), the key will be accepted, but it won't > get an IP address. And yet, my intel 3945 works fine with me with WEP & NetworkManager both in Hardy and Intrepid. Don't forget there are multiple "sub-models" of a given model. Please report your detailled hardware information (lspci -vvnn) on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/253697 (Intel 3945 Wireless in Hardy cannot negotiate WEP or WPA Keys) or/and https://bugs.launchpad.net/ubuntu/+source/linux/+bug/223174 (Intel WLAN, 3945 (a/b/g) - low performance). -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
On Thu, 2008-11-13 at 21:58 +0100, Nicolas Deschildre wrote: > On Thu, Nov 13, 2008 at 8:55 PM, Mackenzie Morgan <[EMAIL PROTECTED]> wrote: > > On Thu, 2008-11-13 at 20:36 +1100, Sarah Hobbs wrote: > >> Take the intel 3945 card, for example. Vincenzo says it doesn't work > >> for him, under various modes. Various users on the forums have also > >> mentioned that their systems don't work with these cards. > >> > >> However, other users on the forums, mailing lists, and a whole lot of > >> the developers, including myself, have this card, and see that it works > >> for them. I personally haven't seen this break since I upgraded to > >> gutsy back at the UDS in Sevilla, 2007 (ie, pre-alpha 1), and I use WPA, > >> which seems to be one of the areas of complaint, otherwise without > >> problems. > > > > In my experience, it does work fine with WPA. It's WEP that's the > > issue. It only works with WEP (properly) using iwconfig. If you use > > NetworkManager, the key will *never* be accepted. And if you use > > network-admin (gone in Intrepid), the key will be accepted, but it won't > > get an IP address. > > And yet, my intel 3945 works fine with me with WEP & NetworkManager > both in Hardy and Intrepid. Don't forget there are multiple > "sub-models" of a given model. > Please report your detailled hardware information (lspci -vvnn) on > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/253697 (Intel > 3945 Wireless in Hardy cannot negotiate WEP or WPA Keys) or/and > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/223174 (Intel > WLAN, 3945 (a/b/g) - low performance). I think I'm already on the first bug, but I'll check again. -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
On Thu, 2008-11-13 at 21:58 +0100, Nicolas Deschildre wrote: > On Thu, Nov 13, 2008 at 8:55 PM, Mackenzie Morgan <[EMAIL PROTECTED]> wrote: > > On Thu, 2008-11-13 at 20:36 +1100, Sarah Hobbs wrote: > >> Take the intel 3945 card, for example. Vincenzo says it doesn't work > >> for him, under various modes. Various users on the forums have also > >> mentioned that their systems don't work with these cards. > >> > >> However, other users on the forums, mailing lists, and a whole lot of > >> the developers, including myself, have this card, and see that it works > >> for them. I personally haven't seen this break since I upgraded to > >> gutsy back at the UDS in Sevilla, 2007 (ie, pre-alpha 1), and I use WPA, > >> which seems to be one of the areas of complaint, otherwise without > >> problems. > > > > In my experience, it does work fine with WPA. It's WEP that's the > > issue. It only works with WEP (properly) using iwconfig. If you use > > NetworkManager, the key will *never* be accepted. And if you use > > network-admin (gone in Intrepid), the key will be accepted, but it won't > > get an IP address. > > And yet, my intel 3945 works fine with me with WEP & NetworkManager > both in Hardy and Intrepid. Don't forget there are multiple > "sub-models" of a given model. > Please report your detailled hardware information (lspci -vvnn) on > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/253697 (Intel > 3945 Wireless in Hardy cannot negotiate WEP or WPA Keys) or/and > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/223174 (Intel > WLAN, 3945 (a/b/g) - low performance). Ah, looking again, I'm subscribed to the first, but it's not what I'm describing. That one is that both WEP and WPA fail. In my case, it just fails with NetworkManager with WEP. WPA is fine. There's a bug sitting around for that too, though. https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.22/+bug/139080 It's filed in Feisty and Gutsy, but it still exists with Hardy and iwl3945. With that laptop, WEP went like this: Dapper + ipw3945 + network-admin = works Feisty, Gutsy + ipw3945 + NM = fail...WEP key not accepted Hardy + iwl3945 + NM = fail...WEP key not accepted Hardy + iwl3945 + network-admin = fail...WEP key accepted, no ip address Hardy + iwl3945 + iwconfig + dhclient = works I haven't bothered trying to use the GUI with my iwl4965 and WEP. I just expect NM to not work when it comes to WEP. -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
On Thu, 13 Nov 2008 16:14:31 -0500 Mackenzie Morgan <[EMAIL PROTECTED]> wrote: >I haven't bothered trying to use the GUI with my iwl4965 and WEP. I >just expect NM to not work when it comes to WEP. I have 4965 and it worked fine for me with KNetworkManager and WEP in Hardy. I have't had a need for WEP since I upgraded to Intrepid. As an aside, if people are truly concerned about privacy/security, they should be on WPA. WEP is trivial to break. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Apport in stable releases [was: Re: Do you really want developers to be on this list]
On Thu, 13 Nov 2008 12:48:40 +0100 Martin Pitt <[EMAIL PROTECTED]> wrote: >Markus Hitter [2008-11-13 11:56 +0100]: >> While we can't "fix" developers, we can put more automatic helpers >> into place: >> >> - Keep Apport enabled even on stable releases. Hiding bugs doesn't >> help. > >We don't disable Apport in stable releases because we want to hide >bugs. The reasons are, in descending importance: > > * core dumps potentially contain a lot of private/sensitive > information which is almost impossible to check for a casual user. > Yes, apport points out to not send a report if you did something > private, and bugs are private by default, but still.. > > * During testing the development release we already get tons of crash > reports, so we should already know (or even have fixed) the > most common crashes. The others aren't really common, and hard to > reproduce, etc., which is why we would not fix them in stable > releases *anyway* (both from an SRU policy perspective, as well as > being a manpower issue). > > * Collecting crash information and sending it to LP takes a lot of > CPU, IO, and network bandwidth, and it doesn't make sense to waste > all this, and create a sense of expectation that the crash will be > fixed in a stable release, when we know upfront that it won't. > I think these are all good reasons. I have heard people discuss post-release regressions due to SRU/security updates. I was chatting with another developer last night who said he'd found Hardy very stable at release and less so as it got updated. Perhaps Apport could be taught to roll the dice and return crash reports in some fraction of cases post-release (perhaps 5 or 10 percent). This would help us catch regressions. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
On Thu, 2008-11-13 at 21:12 -0500, Scott Kitterman wrote: > On Thu, 13 Nov 2008 16:14:31 -0500 Mackenzie Morgan <[EMAIL PROTECTED]> > wrote: > > >I haven't bothered trying to use the GUI with my iwl4965 and WEP. I > >just expect NM to not work when it comes to WEP. > > I have 4965 and it worked fine for me with KNetworkManager and WEP in > Hardy. I have't had a need for WEP since I upgraded to Intrepid. > > As an aside, if people are truly concerned about privacy/security, they > should be on WPA. WEP is trivial to break. I know that, but until about two months ago, the network in the computer science department at school (yeah, go figure) was WEP, so it was a sort of "not-by-choice" thing for me. And visiting other people's houses, WEP is often something you need to deal with. -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
On Thursday 13 November 2008 22:43, Mackenzie Morgan wrote: > On Thu, 2008-11-13 at 21:12 -0500, Scott Kitterman wrote: > > On Thu, 13 Nov 2008 16:14:31 -0500 Mackenzie Morgan <[EMAIL PROTECTED]> > > > > wrote: > > >I haven't bothered trying to use the GUI with my iwl4965 and WEP. I > > >just expect NM to not work when it comes to WEP. > > > > I have 4965 and it worked fine for me with KNetworkManager and WEP in > > Hardy. I have't had a need for WEP since I upgraded to Intrepid. > > > > As an aside, if people are truly concerned about privacy/security, they > > should be on WPA. WEP is trivial to break. > > I know that, but until about two months ago, the network in the computer > science department at school (yeah, go figure) was WEP, so it was a sort > of "not-by-choice" thing for me. And visiting other people's houses, > WEP is often something you need to deal with. Right. It's not always a choice. I didn't mean to imply it didn't matter if WEP worked because people shouldn't use it. It ought to work. I know my 4965 laptop worked with WEP in Hardy because I was working on site at a customer for a while and the employee wireless network was WPA and the visitor's network was WEP. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Apport in stable releases [was: Re: Do you really want developers to be on this list]
On Fri, Nov 14, 2008 at 2:25 AM, Scott Kitterman <[EMAIL PROTECTED]> wrote: > I have heard people discuss post-release regressions due to SRU/security > updates. I was chatting with another developer last night who said he'd > found Hardy very stable at release and less so as it got updated. > > Perhaps Apport could be taught to roll the dice and return crash reports in > some fraction of cases post-release (perhaps 5 or 10 percent). This would > help us catch regressions. Would enabling it in -proposed help with that? -- Matthew East http://www.mdke.org gnupg pub 1024D/0E6B06FF -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
