Re: libc borked
On Thu, Mar 13, 2008 at 02:00:03AM -0400, Scott Kitterman wrote: On Wed, 12 Mar 2008 23:30:14 -0400 Todd Deshane [EMAIL PROTECTED] wrote: Cory, Please read: http://www.ubuntu.com/community/conduct Also, you didn't provide any useful information. Bug reports, versions, etc. If it is hardy then you should expect things to break from time to time. If it is a stable release, then you should report bugs appropriately. The developers work hard and they don't need such a negative response and shouldn't be expected to drop everything and fix your problem. Please provide useful information and I am sure if it is a critical bug, it will be fixed in due time. Are you paying for support? or are you demanding things from volunteers? Would you treat providers of other services that you get such as Internet or Phone, etc. the same way? Best Regards, Todd Todd, I don't know who you are or what your involvement with Ubuntu is, but anyone who is involved in Ubuntu development (as Cory is) and has been on IRC in the last several hours is well aware of exactly what is wrong. None of those details are particularly needed. One thing this, and some other events, has made me think about is - how are new community members supposed to know who someone is and what their contributions to Ubuntu have been? We have a developer responsibilities wiki page[1] perhaps we should publicize it more and flesh it out. As I personally have a hard time keeping people's irc nicks, launchpad usernames and real names connected, I'm adding irc nicks to that page too. What other ways can we help new community members identify people involved in Ubuntu development? [1] https://wiki.ubuntu.com/DeveloperResponsibilities -- Brian Murray @ubuntu.com 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: libc borked
On Mon, Mar 17, 2008 at 11:40 AM, Brian Murray [EMAIL PROTECTED] wrote: One thing this, and some other events, has made me think about is - how are new community members supposed to know who someone is and what their contributions to Ubuntu have been? We have a developer responsibilities wiki page[1] perhaps we should publicize it more and flesh it out. As I personally have a hard time keeping people's irc nicks, launchpad usernames and real names connected, I'm adding irc nicks to that page too. What other ways can we help new community members identify people involved in Ubuntu development? senders email signature line ... short description of responsibilities and area of expertise - this will help all list members place value on the reply [1] https://wiki.ubuntu.com/DeveloperResponsibilities -- Brian Murray @ubuntu.com -rich -- 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: libc borked
Hi, Richard Mancusi wrote: On Mon, Mar 17, 2008 at 11:40 AM, Brian Murray [EMAIL PROTECTED] wrote: One thing this, and some other events, has made me think about is - how are new community members supposed to know who someone is and what their contributions to Ubuntu have been? We have a developer responsibilities wiki page[1] perhaps we should publicize it more and flesh it out. As I personally have a hard time keeping people's irc nicks, launchpad usernames and real names connected, I'm adding irc nicks to that page too. What other ways can we help new community members identify people involved in Ubuntu development? senders email signature line ... short description of responsibilities and area of expertise - this will help all list members place value on the reply For what? Hello, I'm this guy, who does that and now you have to respect my mail, because I'm someone who is doing a lot more for Ubuntu then you? Actually this occasion happened in a development cycle which is intended to break. Everbody who is using a development relase knows exactly that this can happen always until release. So there is no need for fingerpointing...We found the bugger, the solution is quite clear and for the next time, we know now what we have to do (as Colin and I were discussing). Yes, we all make mistakes, so what. To identify who is who doesn't help with all that. 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: libc borked
hi Colin, Colin Watson wrote: On Thu, Mar 13, 2008 at 12:55:47PM +0100, Stephan Hermann wrote: The package is not at fault... The fault was to upload dpkg (2008-02-11 imho) with https://wiki.ubuntu.com/DistCompilerFlags this in mind. Setting those flags is not good without a bunch of testing. I only discovered today that wine broke a few weeks ago due to this change, and that you applied the same kind of fix to wine last week as has since been applied to glibc. I'm curious whether you escalated this anywhere at the time, and if so where? If it was escalated but not dealt with, that's something we should look at too. Well, when I upload 0.9.54 of wine, this problem wasn't arising. After this date, a new dpkg was uploaded with a change of behaviour for CFLAGS etc. This wasn't clear, just beacuse the changelog only mentioned this, without noticing WHAT actually was changed. (no clue about the difference of LDFLAGS we were passing on now) Others and I were tracking down the problem, but that the problem was with ldflags wasn't quite known until one contributor pointed us to the LDFLAGS issue. I was asking about differences between a normal manual build and our sbuilds...but actually Scott Ritchie and I (and other contributors) were quite alone with this. I can understand this, because wine is in universe and not sooo important. But a better communication or at least a mentioning in the changelog, what actually was changed (e.g. New behaviour: ldflags now brings insert our flags here, please be careful) I for myself wasn't quite sure, if the new behaviour was tested beforehand, or just that wine was broken by some things. The funny part, this misbehaviour with our new ldflags was mentioned in a bug report from 2007 which was set invalid/closed in wines bugzilla. Fact, rebuilding the archive won't show any build failures, but running those rebuilt apps would have shown the evilness of this change. Rebuilding the archive against the output of the rebuild in progress would have shown it up very quickly; note that glibc 2.7-9ubuntu2 itself failed to build (without hand-holding) due to upgrading to libc6 2.7-9ubuntu1 at the start of the build, and many packages would have failed in the same way. The problem I see here is: When we upload something new e.g. toolchain, glibc, dpkg-buildpackage changes etc. we are not automatically rebuilding our archive against those new versions. Which would be quite helpful if we did. Fun part, a change in LDFLAGS won't obviously shown up during the build process (as we saw with wine), but during runtime..(which is quite hard for devs who are running the devel release on their WS, I know, but why not use vmware ;)). I was mad. I'm human. I'm over it. Time to spend the day rebuilding 3 machines. ;) Repeat with us: You should not use Development Releases on production machines, until you know that it can break (badly) ! This is definitely worth noting, but it's also clearly true that breakage should be minimised where possible. This is a reminder that the fact that development releases are generally not actually all that bad doesn't mean that they'll never break spectacularly, while also serving as a demonstration of various problems in our processes. TBH, I'm always ready and waiting for any breakage during development..this is nothing new, and this should be known to everybody. Development releases are not intend for the normal audience, and everybody who runs a development release has to know for sure, that at some time everything breaks. I don't blame anybody...we just need to fix some processes, e.g. describing a bit more what the change is (not only : ok we intrdoduced new cflags,ldflags handling and passing some sane/insane flags via dpkg-buildpackage towards our buildsystems). Well, my fault was not to escalate this issue to the right people, just because I thought, those changes were already tested. 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: libc borked
Hi Colin, Colin Watson wrote: Fact, rebuilding the archive won't show any build failures, but running those rebuilt apps would have shown the evilness of this change. Rebuilding the archive against the output of the rebuild in progress would have shown it up very quickly; note that glibc 2.7-9ubuntu2 itself failed to build (without hand-holding) due to upgrading to libc6 2.7-9ubuntu1 at the start of the build, and many packages would have failed in the same way. The problem I see here is: When we upload something new e.g. toolchain, glibc, dpkg-buildpackage changes etc. we are not automatically rebuilding our archive against those new versions. Which would be quite helpful if we did. It isn't practical for us to upload the entire archive when the toolchain changes; we would rapidly lose mirrors if we started doing things like that. No, that I don't mean/want either...but an internal test rebuild of the archive should be possible without injecting any new packages to the archive/mirros. Just for QA purposes. However, we can and do perform test rebuilds that don't end up in the archive; in fact, such a test rebuild was performed after dpkg was changed, but unfortunately did not make use of its own output so this problem didn't show up. We'll fix that for the next test rebuild. We may also try to construct a CD image from the output of the test rebuild, which would allow us to discover more subtle problems; although we'd have to be very careful about labelling these. I'm not sure if any of this would have shown up the wine problem, unless lmms would have encountered it via its build-dependency on wine-dev. Automatic tests in the package itself are probably the best chance we have here. TBH, the break of wine was just a coincidence...as I already said on IRC, I tested the wine 0.9.55 before I uploaded it, but to my fault I didn't update my personal ubuntu mirror to the latest state, and sadly on my system it worked, but not for others after upload. this has been fixed on my site with a 0,6,12,18 interval of mirror_hardy.sh ; update_chroots.sh via cron :) More sad is, that this bug was known to wine devs, but the corresponding bug report was set to invalid/closed which wasn't in my search query. I don't blame anybody...we just need to fix some processes, e.g. describing a bit more what the change is (not only : ok we intrdoduced new cflags,ldflags handling and passing some sane/insane flags via dpkg-buildpackage towards our buildsystems). I still think that in general this is a sane flag (and so far it's broken fewer packages than -fstack-protector did), but more work is clearly needed on spotting the exceptions. Yepp..even with glibc working now, it can happen that some apps (like wine) are breaking during runtime (which can't be catched during the build). those buggers needs to be catched during testing the CDs, or universe archives from testers...or we find an automatic way of running the packages after building (which could be a cool project for SoC students or mad mans task ;)) Anyhow, I think we know now what went wrong, and we do better in the future :) \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: libc borked (and I stop testing)
Vincenzo Ciancia a écrit : A possible idea to improve the situation is to have a regression tag, and to mark high priority all regressions. Say what you want, but this is *exactly* the behaviour that one would expect from any software distributor: things works, you break it, I tell you as soon as I discover it, you fix it as soon as possible because the bug is in the change you just made, so your change has to be fixed. If you let the regression there for three years, you'll have hysterical raisins when you put your hands back on that code. +1 Would somebody that can set up new rules for Bug Squad, QA, Bug Control and so on teams add the tag regression in the list of tags to use, and shift policy so that every regression is marked as High priority? This would at least help to sum up what should really be fixed, because often these bugs are forgotten. Cheers -- 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: libc borked
On Wed, 12 Mar 2008 23:30:14 -0400 Todd Deshane [EMAIL PROTECTED] wrote: Cory, Please read: http://www.ubuntu.com/community/conduct Also, you didn't provide any useful information. Bug reports, versions, etc. If it is hardy then you should expect things to break from time to time. If it is a stable release, then you should report bugs appropriately. The developers work hard and they don't need such a negative response and shouldn't be expected to drop everything and fix your problem. Please provide useful information and I am sure if it is a critical bug, it will be fixed in due time. Are you paying for support? or are you demanding things from volunteers? Would you treat providers of other services that you get such as Internet or Phone, etc. the same way? Best Regards, Todd Todd, I don't know who you are or what your involvement with Ubuntu is, but anyone who is involved in Ubuntu development (as Cory is) and has been on IRC in the last several hours is well aware of exactly what is wrong. None of those details are particularly needed. Cory's comment was a bit intemperate, but I feel your response was not at all helpful and that it really minimized Cory's extensive contributions to Ubuntu developmen. In theory who says something shouldn't affect how it gets responded to, but in real life it does. On a developer's list, I think people who are making substantial contributions should get a little slack. 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: libc borked
On Thu, 13 Mar 2008 09:29:16 +0100 Soren Hansen [EMAIL PROTECTED] wrote: On Thu, Mar 13, 2008 at 02:00:03AM -0400, Scott Kitterman wrote: Cory's comment was a bit intemperate, but I feel your response was not at all helpful and that it really minimized Cory's extensive contributions to Ubuntu developmen. But it's cool for Cory to flame doko because Cory's a developer? Interesting. No, not cool. I just didn't like the response. We all write things we shouldn't every now and then. It doesn't mean we need to have random strangers sending us form letters. 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: libc borked
Moins, Cory K. wrote: Soren Hansen wrote: On Thu, Mar 13, 2008 at 02:00:03AM -0400, Scott Kitterman wrote: Cory's comment was a bit intemperate, but I feel your response was not at all helpful and that it really minimized Cory's extensive contributions to Ubuntu developmen. But it's cool for Cory to flame doko because Cory's a developer? Interesting. If you think that was a flame then I would say you're a tad sensitive. :P It comes down to why would a package be uploaded at this stage in the cycle that renders systems unbootable? The package is not at fault... The fault was to upload dpkg (2008-02-11 imho) with https://wiki.ubuntu.com/DistCompilerFlags this in mind. Setting those flags is not good without a bunch of testing. At least, we should have rebuilt the supported archive and generate an not official released test release, just for developers, to see if something breaks (which is usally the case). Actually, there is noone to blame/flame, but this upload, with such a little change, breaks more then just glibc. Fact, rebuilding the archive won't show any build failures, but running those rebuilt apps would have shown the evilness of this change. Carelessness? No, just normal developer business, new stuff is good...always ;) I could completely see if this were months ago but a day before beta freeze? 4 weeks 'till release? I do understand sh*t happens but something this major now shouldn't. Of course it has to happen, because without those happenings, noone would learn from it. For the future, this is a reference that even a bag of rice, which drops on the floor of a house, could break something somewhere I was mad. I'm human. I'm over it. Time to spend the day rebuilding 3 machines. ;) Repeat with us: You should not use Development Releases on production machines, until you know that it can break (badly) ! But you are a developer and you know that, and you can deal with it :) \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: libc borked
On Thu, Mar 13, 2008 at 07:14:23AM -0400, Scott Kitterman wrote: Cory's comment was a bit intemperate, but I feel your response was not at all helpful and that it really minimized Cory's extensive contributions to Ubuntu developmen. But it's cool for Cory to flame doko because Cory's a developer? Interesting. No, not cool. I just didn't like the response. We all write things we shouldn't every now and then. It doesn't mean we need to have random strangers sending us form letters. Ok, so Cory sends an e-mail to a public mailing list in an intemperate tone. Todd finds this inapproriate, and shares this feeling with Cory and the rest of us, in a tone this is the diametrically opposite of intemperate. And you decide to tell *Todd* off due to his tone, because Cory has done more work on Ubuntu than him? Well, as dholbach so nicely put it, if people are regular contributors to Ubuntu, they should be setting a good example, so if I were to tell one of Todd or Cory off, it'd most certainly be Cory. I would have done so, but Todd did it just fine, IMO, and applying your logic, since I've been a core-dev longer than you, my opinion is better than yours, right? -- Soren Hansen | Virtualisation specialist | Ubuntu Server Team Canonical Ltd. | http://www.ubuntu.com/ 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: libc borked
On Thu, Mar 13, 2008 at 07:29:57AM -0400, Cory K. wrote: Cory's comment was a bit intemperate, but I feel your response was not at all helpful and that it really minimized Cory's extensive contributions to Ubuntu developmen. But it's cool for Cory to flame doko because Cory's a developer? Interesting. If you think that was a flame then I would say you're a tad sensitive. I'm sure you meant it as a helpful and friendly assessment of the quality of the work of one of our fellow developers../sarcasm It comes down to why would a package be uploaded at this stage in the cycle that renders systems unbootable? Remind me: At exactly which stage in the cycle is it appropriate to wilfully upload things to Ubuntu that renders systems unbootable? I could completely see if this were months ago but a day before beta freeze? 4 weeks 'till release? I do understand sh*t happens but something this major now shouldn't. I was mad. I'm human. I'm over it. Time to spend the day rebuilding 3 machines. ;) It's funny how your being human seems to excuse you from being pointlessly difficult towards others when they've exercised their humanity in an unfortunate way. -- Soren Hansen | Virtualisation specialist | Ubuntu Server Team Canonical Ltd. | http://www.ubuntu.com/ 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: libc borked
On Thu, Mar 13, 2008 at 01:43:41PM +0100, Daniel Holbach wrote: https://launchpad.net/bugs/201673 has information about what happened and how to fix it. Semi-official workaround instructions will be added there too. Have a nice day, Daniel YAY Daniel - here's a hug for finally adding some *helpful* content to this discussion. A bug reference - just what Todd so nicely asked for!! And thanks to all the developers who got us this far, and who make things happen, and who try to learn from the past. Yeah, we're all human. Neal McBurnett http://mcburnett.org/neal/ -- 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: libc borked
YAY Daniel - here's a hug for finally adding some *helpful* content to this discussion. A bug reference - just what Todd so nicely asked for!! BTW this is also a very good example of why LP should have a bypass (or whatever you want to name it) field/link. With the amount of comments, finding the bypasses get slightly more arduous. ..hggdh.. 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: libc borked
On Thursday 13 March 2008 08:31:59 Soren Hansen wrote: On Thu, Mar 13, 2008 at 07:14:23AM -0400, Scott Kitterman wrote: Cory's comment was a bit intemperate, but I feel your response was not at all helpful and that it really minimized Cory's extensive contributions to Ubuntu developmen. But it's cool for Cory to flame doko because Cory's a developer? Interesting. No, not cool. I just didn't like the response. We all write things we shouldn't every now and then. It doesn't mean we need to have random strangers sending us form letters. Ok, so Cory sends an e-mail to a public mailing list in an intemperate tone. Todd finds this inapproriate, and shares this feeling with Cory and the rest of us, in a tone this is the diametrically opposite of intemperate. And you decide to tell *Todd* off due to his tone, because Cory has done more work on Ubuntu than him? Well, as dholbach so nicely put it, if people are regular contributors to Ubuntu, they should be setting a good example, so if I were to tell one of Todd or Cory off, it'd most certainly be Cory. I would have done so, but Todd did it just fine, IMO, and applying your logic, since I've been a core-dev longer than you, my opinion is better than yours, right? I've thought about this some more and I think I understand my negative reaction to Todd's mail better. The problem wasn't that he responded or that he's not a developer. What bothered me was that it sounded like a standard stock response. This is supposed to be Linux for human beings and I didn't feel like Todd's mail took into account the unique human things that would have caused Cory to write such a mail. Cory certainly should (IMO) have expressed his understandable frustration with the situation in a more positive/better way and it was appropriate of Todd to point that out (developer or not). I just wish he'd been less impersonal about it. Thanks for pushing back on my response. I learned something from it. 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: libc borked (and I stop testing)
I'm in the same boat as you Vincenzo. Kind of the last straw for myself also. Been trying for a while now to test and get fixes into Hardy so that the Thinkpad T61 whould work out of the box (pretty much perfectly). As this is they laptop I now use on a daily basis, and I was going to try and start average users on the same platform with Ubuntu. But there is an extreme problem with Ubuntu developers ignoring bugzilla and straight up breaking stuff. In all my bugzillas I try to include fixes, but even with fixes...no love. As of late there have been big regressions and it seems futile to file a bugzilla as it appears nobody is going to give it any attention. Lately Hardy has been so badly breaking, during a time when time where this shouldn't happen. I think Cory was dead on about libc though. How can this of all packages break now! I'm joining you to just going back to being a user for myself.. and stop having these lofty ideas that things can work perfectly. On Thu, Mar 13, 2008 at 7:03 AM, Vincenzo Ciancia [EMAIL PROTECTED] wrote: Il giorno mer, 12/03/2008 alle 23.20 -0400, Cory K. ha scritto: Thanx to the genius who let the libc update through and rendered 3 systems unbootable here. I look forward to your visit to my home to fix them. Frustrated and pissed, Cory K. Even though the tone of the mail is angry, it's really bad that things like this libc update happen - I personally don't understand how this is possible at all, if developers test their packages. A revert system after upgrade mode should be designed and implemented to the benefit of testers (unionfs plus a commit operation to the main filesystem seems to me like an implementable solution). Would not be efficient but would be a bit safer - you already have unionfs in the livecd so you have some expertise. I am sad to say that my hardy testing experience stops here - I wanted to make my experience as a free software user, and as a developer, available to ubuntu community as a form of payment for such a good distribution. Problem is not the libc bug by itself of course. If you want to know read below - but it's not necessary at all. Problem is that I should waste hours fixing the libc bug, and I am doing this just to let the world benefit from fixes I can already install and hack up locally on my pc. The balance between costs and benefits is dropping down too quick. Many regressions I've personally been trying to help sorting out have a fix, signaled by one of the testers (usually not me since I am not that smart, but I usually took the time to test the fix and reported) and the fix is not being applied, and developers are waiting for *users* to UVFE. I am more and more being convinced that testing new ubuntu is a complete waste of time for me. The main point that, to my eyes, the ubuntu upload-enabled community seems not to be understanding, is that one should try to re-use people's expertise. You can't ask a person that already can debug a kernel module to also learn to package debs and all the ubuntu burocracy. That's a problem of developers. If you have a clever user (I am *not* talking about me :) ) that provides a fix and explains how he/she got there, you can't ask for more. You are the developer, you have the expertise to fix bugs in ubuntu, the tester provided the fix, having the expertise to test it, why not joining forces? personal story follows, the main point of the e-mail is what you already read Next LTS won't have proper support for my tablet. I surrender. It's two years I have been waiting the day I can advice ubuntu to people who have the same laptop as mine, and still nobody cares. Next year I will have to return this laptop to university, and I'll perhaps buy a different tablet. With different problems. And I've never seen ubuntu working out of the box there - even though there always was a well-known and signaled to developers way to make it work. I've seen things stopping working, nobody cared in the world. For example, my sd card reader worked in edgy and will never work in any future ubuntu release. I opened a bug *during feisty beta* - it used to work in some feisty alpha but don't know which one, then it was marked as duplicate of another bug, which after months was fixed and was not a dupe of mine, I then had to reopen a new bug, and *nobody cared anymore*. Don't bull*hit on me. The problem I am pointing out is real. There is a regression from previous releases and nobody cares, because few users have it. But that's a regression. Ok, few users have it because the vaste majority of tablet users don't even consider the crazy idea of running that hacky linux on it. Accept this and if and when ubuntu will work on tablets really out of the box, you'll see how many users are affected by such regressions. I've followed bug reports, provided requested information, tried to
Re: libc borked
On Thu, Mar 13, 2008 at 10:13:03AM -0500, HggdH wrote: BTW this is also a very good example of why LP should have a bypass (or whatever you want to name it) field/link. With the amount of comments, finding the bypasses get slightly more arduous. You mean workaround? The appropriate place for that is the bug description, and shortly after you sent your mail I completed local testing of some workarounds and edited the bug description to document these. Cheers, -- Colin Watson [EMAIL PROTECTED] -- 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: libc borked
On Wed, Mar 12, 2008 at 11:20:22PM -0400, Cory K. wrote: Thanx to the genius who let the libc update through and rendered 3 systems unbootable here. I look forward to your visit to my home to fix them. I've posted a message to ubuntu-devel-announce with full workaround instructions, which you should be able to apply to your broken systems given at most a Hardy desktop CD; in some circumstances you may be able to do it without that. https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-March/000401.html This was, of course, treated as absolute top priority for the members of the Ubuntu team involved in the cleanup process. I don't think it's productive to point fingers, as there were various failings involved. We're doing a full analysis of the incident and I expect that we'll make some changes as a result. Thanks, -- Colin Watson [EMAIL PROTECTED] -- 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: libc borked
On Thu, Mar 13, 2008 at 12:55:47PM +0100, Stephan Hermann wrote: The package is not at fault... The fault was to upload dpkg (2008-02-11 imho) with https://wiki.ubuntu.com/DistCompilerFlags this in mind. Setting those flags is not good without a bunch of testing. I only discovered today that wine broke a few weeks ago due to this change, and that you applied the same kind of fix to wine last week as has since been applied to glibc. I'm curious whether you escalated this anywhere at the time, and if so where? If it was escalated but not dealt with, that's something we should look at too. Fact, rebuilding the archive won't show any build failures, but running those rebuilt apps would have shown the evilness of this change. Rebuilding the archive against the output of the rebuild in progress would have shown it up very quickly; note that glibc 2.7-9ubuntu2 itself failed to build (without hand-holding) due to upgrading to libc6 2.7-9ubuntu1 at the start of the build, and many packages would have failed in the same way. I was mad. I'm human. I'm over it. Time to spend the day rebuilding 3 machines. ;) Repeat with us: You should not use Development Releases on production machines, until you know that it can break (badly) ! This is definitely worth noting, but it's also clearly true that breakage should be minimised where possible. This is a reminder that the fact that development releases are generally not actually all that bad doesn't mean that they'll never break spectacularly, while also serving as a demonstration of various problems in our processes. Cheers, -- Colin Watson [EMAIL PROTECTED] -- 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: libc borked
*[quote]HARDY HERON SHOULD NOT BE USED FOR YOUR DESKTOP UNTIL IT IS RELEASED IN APRIL 2008* If you decide to use Hardy Heron now, then you are doing so at your own risk, and with the risk of major breakage and possible data loss.[/quote] Cory, hardy is alpha software.There is always going to be breakages, otherwise it would defeat the point of a dev os.Running 3 comps on hardy isnt very sensible even running hardy on a system that has any data that you need isnt a good idea. -- 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: libc borked (and I stop testing)
On Thursday 13 March 2008 08:03:32 Vincenzo Ciancia wrote: Il giorno mer, 12/03/2008 alle 23.20 -0400, Cory K. ha scritto: Thanx to the genius who let the libc update through and rendered 3 systems unbootable here. I look forward to your visit to my home to fix them. Frustrated and pissed, Cory K. Even though the tone of the mail is angry, it's really bad that things like this libc update happen - I personally don't understand how this is possible at all, if developers test their packages. I've uploaded stuff that turned out to be broken. There are many possible reasons for this. It's not feasible to do full regression testing for every upload. Not just due to time, but because of the wide range of hardware used for Ubuntu. A revert system after upgrade mode should be designed and implemented to the benefit of testers (unionfs plus a commit operation to the main filesystem seems to me like an implementable solution). Would not be efficient but would be a bit safer - you already have unionfs in the livecd so you have some expertise. This is the sort of thing that should be proposed as a specification and decided on at UDS. It sounds like a nice idea. I'm not qualified to have an opinion on how feasible it is. I am sad to say that my hardy testing experience stops here - I wanted to make my experience as a free software user, and as a developer, available to ubuntu community as a form of payment for such a good distribution. Problem is not the libc bug by itself of course. If you want to know read below - but it's not necessary at all. Problem is that I should waste hours fixing the libc bug, and I am doing this just to let the world benefit from fixes I can already install and hack up locally on my pc. The balance between costs and benefits is dropping down too quick. Many regressions I've personally been trying to help sorting out have a fix, signaled by one of the testers (usually not me since I am not that smart, but I usually took the time to test the fix and reported) and the fix is not being applied, and developers are waiting for *users* to UVFE. I am more and more being convinced that testing new ubuntu is a complete waste of time for me. I've found just the opposite. I've found as I got more and more involved in first testing and then development I've been able to get more and more of my personal pain points dealt with. Also, keep in mind that most developers are volunteers. Volunteer work gets done on the basis of interest. If a user wants a problem solved, I've got neither the time nor interest in being their personal UVFe (now FFe) writer. I'm glad to help them figure out how to do it, but I'm fully busy working on the problems that I'm trying to solve. The main point that, to my eyes, the ubuntu upload-enabled community seems not to be understanding, is that one should try to re-use people's expertise. You can't ask a person that already can debug a kernel module to also learn to package debs and all the ubuntu burocracy. That's a problem of developers. If you have a clever user (I am *not* talking about me :) ) that provides a fix and explains how he/she got there, you can't ask for more. You are the developer, you have the expertise to fix bugs in ubuntu, the tester provided the fix, having the expertise to test it, why not joining forces? This is certainly ideal, but it's not like the developer is sitting around waiting for more to work on. What we need are more people working on all levels of the problem. It is a general case that we could use more people who know packaging working on packaging up available fixes. I think there have been some recent initiatives to encourage this. personal story follows, the main point of the e-mail is what you already read Next LTS won't have proper support for my tablet. I surrender. It's two years I have been waiting the day I can advice ubuntu to people who have the same laptop as mine, and still nobody cares. Next year I will have to return this laptop to university, and I'll perhaps buy a different tablet. With different problems. And I've never seen ubuntu working out of the box there - even though there always was a well-known and signaled to developers way to make it work. I've seen things stopping working, nobody cared in the world. For example, my sd card reader worked in edgy and will never work in any future ubuntu release. I opened a bug *during feisty beta* - it used to work in some feisty alpha but don't know which one, then it was marked as duplicate of another bug, which after months was fixed and was not a dupe of mine, I then had to reopen a new bug, and *nobody cared anymore*. Don't bull*hit on me. The problem I am pointing out is real. There is a regression from previous releases and nobody cares, because few users have it. But that's a regression. Ok, few users have it because the vaste majority of tablet users don't even
libc borked
Thanx to the genius who let the libc update through and rendered 3 systems unbootable here. I look forward to your visit to my home to fix them. Frustrated and pissed, Cory 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: libc borked
Cory, Please read: http://www.ubuntu.com/community/conduct Also, you didn't provide any useful information. Bug reports, versions, etc. If it is hardy then you should expect things to break from time to time. If it is a stable release, then you should report bugs appropriately. The developers work hard and they don't need such a negative response and shouldn't be expected to drop everything and fix your problem. Please provide useful information and I am sure if it is a critical bug, it will be fixed in due time. Are you paying for support? or are you demanding things from volunteers? Would you treat providers of other services that you get such as Internet or Phone, etc. the same way? Best Regards, Todd On Wed, Mar 12, 2008 at 11:20 PM, Cory K. [EMAIL PROTECTED] wrote: Thanx to the genius who let the libc update through and rendered 3 systems unbootable here. I look forward to your visit to my home to fix them. Frustrated and pissed, Cory 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 -- 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
