[00:41] BigPick: A good place to start is to play with the video restore settings in /etc/default/acpi-support. [01:28] So does Michael use IRC ever? [01:28] BigPick: Which Michael? [01:28] Vogt [01:28] yes [01:28] Ah, he's mvo, and is often here. [01:29] Sweet. I hoping to get some input from him. [01:31] I may have some helpful information on the update-manager crashes. [01:51] BigPick: attach any information to a bug, to prevent the data getting lost [01:55] Already done. I've submitted full information and serveral experimental patches to both the update-manager and the python-apt packages. [02:01] cool [02:03] The problems arise from an odd anomally in the handling of the kubuntu-desktop metapackage. [02:03] And wind up causing 2 different memory leaks. [02:04] Its not one big problem, but several minor errors that compound. [02:05] I haven't been able to determine what causes the initial anomally, but I have been able to patch the memory leaks, both of which are caused by accidental infinite loops. [02:08] Aren't all infinite loops 'accidental'? [02:09] not the ones that the kernel can do in 5s [02:10] Isn't 5s finite? [02:10] HAHA, well I guess except when considering things such as graphics and events. In those cases the loops are expected to infinite until a wakeup call. [02:11] BigPick: key word "until" ;-) [02:11] Indeed :P [02:11] I understand your point though :-) [02:12] Hey, I was trying not to point any fingers :-D [02:13] I was just emphasizing the "accidental", instead of like "negligent" or "incompotent" or something. [02:16] BigPick: Actually, it's often intentional: the "main loop" design strategy, where the loop should continue until the process is stopped (usually through throwing an exception) [02:17] Exactly. [02:18] However I am more comforitable thinking of it in terms of thread "waits" and such. Even though the implementation is probably similar if not identical :P [02:24] So.... ever since I installed gutsy (and with it, compiz fusion), I've been noticing that every so often while c-f is running, x will just suddenly, for no apparent reason, *die*, returning me to the gdm prompt. [02:24] Sometimes its days, [02:24] but certain conditions make it happen frequently [02:24] for instance, [02:24] If I'm running mencoder, [02:24] it takes about 5 minutes. [02:24] which is very, very annoying. [02:24] Have other people been reporting this behavior, or am I special? :P [02:25] actually, on second thought, this would probably be better suited for #ubuntu [02:26] sorry for bothering you guys. Keep up the good work! [02:27] pipegeek, this is usually not the best place to ask, checking out bugs reported in Launchpad is probably the best way [02:27] thank you. [02:27] heading there right now [02:27] or opening threads in forums, this channel is specifically for development jiberish :D [02:27] pipegeek, :D [02:27] * Fujitsu notes that Ubuntu mencoder doesn't actually link against any X libraries. [02:28] Fujitsu: should it? [02:30] ... [02:30] Fujitsu: I don't know if mencoder is doing something directly to x, or if it's just that compiz will tend to die when the system's under load [02:30] kees cook? [02:30] keescook: ping [02:30] Fujistu: I should try compiling something big [02:35] Nafallo: No, it's meant to not have anything to do with X. [02:35] Fujitsu: all good then? :-) [02:36] Fujitsu: aha. you answered something above :-P [02:43] Could I ask a general question of the devs here? I'm just curious about something. [02:43] pipegeek: Sure. [02:44] (though most of the main devs are likely not here) [02:44] So, my understanding of the way ubuntu (and debian) releases are handled, [02:44] (that's ok, I figured :^) ) [02:44] is that, once a release is final, the only changes that make it in are security fixes. [02:44] What I don't understand, [02:45] Not quite. Important bugfixes can also be made after appropriate QA procedures. [02:45] is why it is that fixes to program features which are discovered to be broken don't make it in as well. I don't get the logic behind having it such that broken code is knowingly being distributed as part of ubuntu for six months [02:45] aaah [02:45] so what's that process? [02:45] !sru | pipegeek [02:45] pipegeek: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates [02:46] thanks, persia [02:47] I should think my compiz thing, if it's common (and anecdotally it is, as a friend of mine with a fresh install on completely different hardware is experiencing the same thing) should qualify [02:47] There probably already is a bug for it [02:47] I should go comment on it [02:48] * Fujitsu has found Compiz to be completely stable since late in Gutsy cycle. [02:48] pipegeek: Crashes generally do, the difficulty is in determining the specific cause, and testing to verify that it doesn't break a working setup. [02:48] represents a possibility for data loss, and it directly affects desktop, non technical users [02:48] righto [02:49] I am curious :^) I'm just not sure I dare start pulling x apart and running pieces of it in strace, etc. x.org is so bloody huge and arcane... >.< [02:49] but then, it does have to get done.... [02:50] Thanks, all. I hope I haven't been too obnoxious... [02:52] pipegeek: Thanks for digging into the issue. Please make sure there is a bug, and post your findings there. [02:57] meh @ .gtkrc [02:58] can't work out how to make the treeview expander things visible [03:08] HAHAHA [03:08] gcc developers rock [03:08] "in fact, assuming almost anything where a reasonable implementation could change, is not a good idea" [03:09] (googleing to see whether alloca() works inside inline functions :p) [03:10] Keybuk: what gtk thing are you trying to work on [03:10] ? [03:11] Burgundavia: running darklooks but with white input boxes [03:11] the triangle thing inside them is also white [03:11] and I can't figure out how to make it black [03:12] right [03:14] Okay... well... we all have out little battles I guess. [03:49] I think there should be a moratorium on the use of the word "Manager" for program names [03:49] agree [03:49] s/Manager/Kit/g [03:49] should we write a Word Manager to implement that? [03:49] maybe UI Manager [03:50] Agreed. [03:50] Network Manager, Power Management, Restricted Drivers Manager [03:50] LaserJock: WordKit [03:50] heh [03:50] I don't want to manage any of those things, I want to *use* them [03:50] NetworkKit, PowerKit, RestrictedDriversKit [03:50] Bootloader Manager [03:50] No not kit. [03:50] Kit is Maccy [03:51] BootKit [03:51] mpt: you ever give that SoC student a review of Bootloader Manager? [03:51] LaserJock, I thought I did and CCed you [03:51] ok [03:51] or did I just imagine I did? [03:51] How about we get everything name * Manager to work correctly. :-D [03:52] you did early on I remember [03:52] Pete Savage should have named his new thingy MessageKit [03:52] haha [03:52] Notification Manager? [03:52] So far things named "Manager" are causing me no end of pain. [03:52] NotificationKit [03:54] http://web.archive.org/web/20051124192442/www.blakeross.com/images/splash-manager.gif [03:54] SplashKit [03:54] so we just need an UbuntuKit and UbuntuManager to wrap it all up and go home [03:55] LaserJockKit [03:55] noooooooo === Keybuk is now known as KeybukKit [03:55] although a LaserJock Manager sounds good [03:55] but that position's already been taken by my wife I think ;-) [03:58] ah, http://web.archive.org/web/20050912102712/http://www.blakeross.com/images/refcnt.gif [03:59] Those were the days [03:59] mpt: http://www.kde.org/ [04:00] http://amarok.kde.org/ [04:00] now we just need PittiManager [04:01] ah, found it [04:01] the list of managers Mozilla used to have [04:01] you want to manage pitti? [04:02] Cookie Manager, Image Manager, Popup Manager, Form Manager, Password Manager, and Download Manager. [04:02] PittiKit would be better ... make new pittis! [04:02] yeah, I suppose so [04:02] mpt: rename them to monsters [04:02] Cookie Monster [04:02] :-D [04:02] Image monster [04:02] Popup Monster [04:02] Form Monster [04:02] Password Monster [04:02] Download Monster [04:02] lol [04:02] can we? [04:03] Network Monster would be pretty accurate. [04:03] can we *please*? [04:03] man, what fun April Fools we could do with that [04:03] evand, Seamonkey's in Universe, right? Take over the package and Do It :-) [04:03] I vote Network Monster. [04:04] Vote Network Monster in 2008! [04:04] hrmm, perhaps [04:04] Network Monster for President! [04:05] Ugh, god. If I sat down and wrote a replacement for NetworkManager, would it stand a chance of being adopted? [04:05] no [04:05] LaserJock, actually, I'm glad you mentioned the Bootloader Manager -- were you the mentor? [04:05] work on upstream NetworkManager, BigPick [04:05] mpt: yeah [04:05] replace Usplash with Gnash! [04:05] 0.7 looks like it might sorta work a bit properly sort of. [04:05] lots of bugs in NM are actually driver bugs [04:05] BigPick: no, better to improve NM [04:05] NM is actually not *that* bad [04:06] like the whole "freeze my whole fucking computer bug" [04:06] it generally works fine for me [04:06] thanks Atheros [04:06] LaserJock, how did it end up? [04:06] If you can get it to stop hardlocking my computer I'll believe you. [04:06] mpt: ok I guess [04:06] BigPick: if it hard locks, it's a driver bug [04:06] BigPick: an NIH rewrite would lock the same way [04:06] mpt: I think its got some potential [04:06] wicd for gnome > network mangler [04:06] It works OK for me unless I try to connect to one particular network, in which case it spams my syslog with hundreds of thousands of lines each second, eating CPU. [04:06] LaserJock, I'm wondering if it could be merged with Power M_____r [04:06] No its not. I can confirm the lock on three seperate machines, two of which don't even have wireless drivers. [04:07] but don't tell people I have been running Gnome, I will never hear the end of it :) [04:07] mpt: but I think the goal needs to be broader than "let's be yet another menu.lst GUI" [04:07] "Startup & Shutdown" [04:07] BigPick: anything that hard locks a machine is a driver bug [04:07] BigPick: NM simply can't lock the system itself. [04:07] mpt: yeah, something like that [04:07] BigPick: NM manages non-wireless cards as well [04:08] I really wanted to have an option so that you could choose an OS to reboot into at logout [04:08] yes, an 8th logout option [04:08] LaserJock, yeah, that's what I'm wondering [04:08] I know I know, its not a hardlock, thats a drastic overstatement. NetworkManager just refuses to die and slowly eats up all remaining memory until I can do anything :P [04:08] Burgundavia: well, that's another issue [04:08] *cant't [04:09] I've been getting a lot of scary bug reports about Wine lately - whole system freezes, crashes, etc. Wine is a user-level application and shouldn't be causing these sorts of things - it's likely exposing driver bugs or something, but I don't know where to forward the bugs to. [04:09] ( Shut Down Now ) ( Restart ) ( Restart Into BeOS ) [04:09] BigPick: no it doesn't. [04:09] LaserJock: what is? management of wired cards? [04:09] Isn't the logout dialog being redone for Hardy, mpt? [04:09] Fujitsu: yes [04:09] Fujitsu, hopefully, that's why I'm asking [04:09] No it doesn't what? [04:09] doesn't use all available memory [04:09] and doesn't refuse to die [04:09] if you can't kill -9 it => driver bug ;) [04:10] Burgundavia: having too many logout options [04:10] LaserJock: yes, well there are ways to get around that [04:10] KeybukKit: So do I presume these are ati driver bugs and refile them against that package? [04:10] if driver bugs were not an issue, I would only have Hibernate and Suspend [04:11] YokoZar: nvidia binary graphics driver bugs [04:11] Burgundavia: as the only options for logout? [04:11] Look, when I don't have NetworkManager doesn't load, the problem doesn't happen. [04:11] LaserJock: and logout, but yes [04:11] KeybukKit: So I think I should mark incomplete and then target nvidia or ati [04:11] once they give driver version [04:11] *when I don't have network manager load. [04:11] LaserJock: no need for reboot, as that can be done via prompting. Shutdown is not needed. We should be saving sessions [04:12] thus leaving you at two options: turn my system off or not [04:12] BigPick: I find that my computer is bug free all the time it's switched off ;) [04:12] KeybukKit: Yeah, funny how that works. [04:12] BigPick: the possibility is that NM is exposing a bug not previously exposed [04:12] Burgundavia: But what if I just upgraded to the newest shiny release, and need to reboot to get the new kernel & libc? [04:12] Burgundavia: suspend happens when you close your lid [04:12] Burgundavia, I'm assuming that we can't fix all session management bugs for Hardy [04:13] And even if we could, I'm not sure that would alter the design at all [04:13] KeybukKit: There's also desktop suspend. Less common, but present [04:13] KeybukKit: Even if it is a driver bug, why doesn't it occur since I started manually configuring my interfaces? [04:13] persia: that would happen via the update-notifier dialogue (ie: it is a special case that happens only once in a while) [04:13] mpt: we would need to fix those bugs as well, but the driver one is a killer [04:13] persia, handled by a configurable timeout [04:13] Burgundavia: Ah. So I'd select "reboot" from that dialog, and then go back to suspend/hibernate? [04:13] BigPick: because NM is probably tickling the bug by being useful [04:14] persia: no, reboot would be on another dialog, the one telling you had to reboot [04:14] it scans wireless networks regularly [04:14] mpt: Use case being "I want it suspended now", but I see your point. [04:14] and checks the link sense on wired network interfaces, etc. [04:15] KeybukKit: HAHAHA ah, thats awsome. Nothing like just passing off blame for problems :-D [04:15] So would anybody be interested in a bug that I found in the nm-applet plugin for openvpn? I'm willing to try to help fix the problem. [04:15] Burgundavia: Sorry. To be more verbose. When I need to reboot for the new kernel, the notification dialog allows me to do so. After than reboot, I would continue to choose between suspend/hibernate for future sessions. [04:15] BigPick: nothing to do with passing off blame [04:15] persia: yes, absolutely [04:15] it's to do with accurate triage of the problems at hand [04:15] if you were a developer needing to reboot, you are a developer. You know how to use a terminal [04:15] The problem is that when you connect to the VPN using the openvpn setup, network-manager wipes out your resolv.conf. [04:16] persia, I think "It's not a laptop but I want it suspended immediately" is one small thing where we may have to defer to the command line [04:16] (aka "eeeeeeedge case") [04:17] mpt: Actually, based on lid event / screen lock, I'm more tempted by just having a "Hibernate" option (given that it works for everyone) [04:17] NM does not cause world hunger [04:17] mpt: suspending for sane power management is not really an edge case [04:17] don't get me wrong [04:17] persia: Hibernate doesn't always work. [04:17] I hate it as much as the next person [04:17] but I'm aware that most of the problems aren't its fault [04:17] Burgundavia: Desktop-immediate-suspend vs. desktop-lock-timeout-suspend [04:17] like the fact it crashes several times a day while here [04:17] oh [04:17] it's in uninterruptible sleep; that's a kernel issue [04:17] KeybukKit: Okay, considering I have bcm43xx compiled with debugging enabled, and I worked on the patches for bcm4311 compatability and I am still helping the investigation into the TX power problem... [04:17] Fujitsu: As an ideal, it's a good goal. For my workstation, it's also useless. [04:17] (proven by the fact that I often have to remove and reprobe the ipw3945 module) [04:18] persia, actually, another part of the spec is combining those two [04:18] BigPick: bcm is ... incomplete :) [04:18] Burgundavia, what do you mean? [04:18] Fujitsu: there is also the issue of dual boot + hibernate is really not good [04:18] mpt: sorry, I was confused [04:18] BigPick: it's also worth pointing out that the bcm43xx driver is also deprecated ;) [04:18] Burgundavia: Why not? Would it be better if file buffers were always flushed? [04:18] KeybukKit: And considering the problem occurs even if bcm43xx is blacklisted. [04:19] BigPick: could be a problem with your wired card [04:19] tg3? [04:19] mpt: combining which two? [04:19] persia: issues with stuff moving around when the other os is running [04:20] persia, suspend and hibernate -- though if your computer doesn't work with one or the other, you could ramp the slider all the way to one end or the other [04:20] Burgundavia: Ah. Right. [04:20] mpt: it seems he did implement the "reboot into: " thing, it's just in his UI rather than in a logout dialog or something [04:21] mpt: Well, my workstation doesn't do either (desktop use case). For power management, moving from suspend to hibernate in a configurable way makes sense. [04:21] This is useless. KeybukKit, your right. I'm just a noob and can't tell a kernel-mode driver error from a python crash when I see one. [04:21] I guess all I can do is sit here and hope that the driver developers get in touch with the NetworkManager maintainers so they can learn the proper way to implent networking drivers. [04:22] BigPick: don't get frustrated [04:22] BigPick: well, err, given NetworkManager isn't written in Python ... ;) [04:22] yes, but knetworkmanger is, which is where my stack traces are leading to. [04:23] if you can demonstrate bugs in NetworkManager, I'm sure that they'll be rapidly fixed [04:23] likewise for the KDE applet for it [04:23] but if you're seeing anything other than simple silly bugs, like hardware lock-ups, you're definitely seeing kernel bugs [04:23] (a lot of NM's issues also come down to missing kernel support for things) [04:25] Burgundavia: I get frustrated because I have been dealing with this mentality for weeks. For instance with update-manager. Everyone just told me my configuration was incorrect. [04:25] it is not a mentality, it is the truth [04:25] bugs exist at different layers [04:26] Roll up my sleeves and come to find out that my update failures were the result of two seperate memory leaks within the update-manager and python-apt packages. [04:26] NM refuses to work around stupid bugs, which is generally good [04:26] BigPick: thanks very much! I wish more technically-inclined users would help out in that way [04:26] mpt: wow, this turned out a lot better than I thought [04:26] have you been able to connect with mvo? [04:26] Burgundavia, if it doesn't give good error message, that's bad [04:26] mpt: you speaking about NM failing? [04:27] yes [04:27] mpt: I just got the latest code for Bootloader Manager and took a bunch of screenshots [04:27] good error messages are expected in 2-3 years ;) [04:27] LaserJock, you didn't look at it again until now? :-X [04:27] mpt: one of the nasty bugs that you really cannot warn the user about is that Atheros reports strength wrong (too weak) [04:27] Burgundavia: err, I *fixed* that! [04:27] KeybukKit: you fixed it? I don't see said fix... [04:27] hmm [04:27] mpt: not the final stuff, he's worked on it since I last looked [04:27] but then I stopped having an Atheros card, so it's entirely likely it got unfixed [04:27] No, I have not. And so far my only responses from other developers have been that the problem doesn't meet SRU [04:28] mpt: the whole SoC thing was ... interesting [04:28] BigPick: we very very *very* rarely SRU [04:28] LaserJock: SoC tends to produce such code [04:28] So nothing is done instead? [04:28] we always have another release out within 6 months [04:28] it's fixed for the next release [04:28] (assuming your patch was accepted?) [04:29] It hasn't been considered. [04:29] what's the bug#? [04:29] Burgundavia: I think this project has a chance [04:29] people really want something [04:29] BigPick: the other challenge is that this week was teh Ubuntu Developers Summit, so lots of developers were heads down in person to person meetings [04:29] LaserJock: people wanting something != project has a chance [04:29] Bug 107188 [04:29] Launchpad bug 107188 in update-manager "[MASTER] [kde] Upgrade tool crashed with " Cannot allocate memory"" [High,Confirmed] https://launchpad.net/bugs/107188 [04:30] if wishes were horses, I would have a better latop [04:30] This bug has existed for over a year. I had the same issue during Edgy->Feisty. [04:30] Burgundavia: no, I'm saying it has a chance *and* people seem to want it [04:30] LaserJock: right [04:30] BigPick: it's kde specific? [04:30] but it really does need to get picked up [04:31] BigPick: No, I gave a detailed explanation of why it wasn't. [04:31] I just refrenced myslef....LMAO [04:31] LaserJock, I get the impression that the proportion of Ubuntu SoC projects that actually end up in Ubuntu is alarmingly small [04:31] Though maybe I just look at the wrong ones [04:31] mvo seems quite active on that bug [04:31] No, it is not kde specific, but it is caused by an anomaly in kubuntu-desktop. [04:32] mpt: Which ones have made it in? [04:32] Check the dates. [04:32] Fujitsu, no idea [04:32] Bug 154195 [04:32] Launchpad bug 154195 in ubuntu "Gutsy cdromupgrade script fails" [Undecided,New] https://launchpad.net/bugs/154195 [04:32] mpt: I think that's an Ubuntu problem and not an SoC problem [04:33] Thats the bug I filed for the second memory leak as reported by the user "Christian Assig" patch also included. [04:33] BigPick: right, your patch is very very recent [04:33] colorfilter made it into ubuntu [04:33] pwnguin: Aha, true. [04:34] i thought it was kinda nifty [04:34] mpt: check out the screenshots at http://laserjock.us/files/ubuntu/soc/ [04:34] No, not that date, mvo's last response to the bug was six months ago. [04:34] but not finished [04:34] BigPick: there was no new information until your post though [04:34] for example, it would have been neat to have a "this is what colorblind people see" set of filters [04:35] pwnguin: that has been suggested a lot fo times [04:35] i thought it was just me [04:35] BigPick: simple reality is that we have more users than we have developers [04:35] number of bugs is proportional to number of users [04:36] ergo we have more bugs than we have developers [04:36] i thought software was a commodity :P [04:36] since this is greater by a factor of several thousand, we do rely on technologically inclined community members and users to help out with the bug triage [04:36] which you've done [04:36] which is great ;) [04:36] I understand, but this is the first time it has been acknowledged as "new information" [04:36] I've tagged the bug so that mvo knows there's a patch on it [04:37] KeybukKit: I think this exposes an LP bug. GNOME bugzilla lists bugs that have patches and have a standard tag for them. We need one [04:37] sure, but this isn't surprising since for the entire time since your message, our developers have been at the UDS planning the next release [04:37] LaserJock, so maybe if you have some time you could ask the relevant Ubuntu people how to improve SoC effectiveness (since you know much more about it than me) [04:37] I have not been able to contact mvo, and up until now I was flatly told that it was either adepts or KDEs problem. [04:37] from the text above in the bug, that was a reasonable explanation [04:38] Burgundavia: Attaching something marked as a patch flags it, and allows us to search. [04:38] Fujitsu: does it now? [04:38] Burgundavia: It has for at least a year. [04:38] You can see how it is extremely frustrating for a non-developer to try and submit this stuff. [04:38] Fujitsu: I have been using LP for so long, sometimes I miss these things [04:38] indeed, which is why we encourage non-developers to use the answer tracker rather than the bug tracking system [04:39] Burgundavia: It has been there as long as I can remember, I think. [04:39] Which is a good couple of years. [04:39] And more. [04:39] hmm, maybe you are right [04:39] likely it is just not very obivous [04:39] LP is like that [04:39] Yeah. [04:40] I appreciate that you worked hard on the patch [04:40] and triumphantly submitted it to LP thinking you'd get a quick response [04:41] sadly this is the busiest time for our developers, who simply won't have had time to keep up with their bugs at this point [04:41] Its not a quick response issue. I'm not trying to toot my own horn here. [04:41] we've finished one release, and are opening the next [04:42] I'm trying to point out how a major bug like this has been continuing over three release cycles now. [04:42] many bugs like that persist [04:42] sad reality of software development [04:42] how much time would you estimate you spent tracking it down? [04:42] 6 hours? 10 hours? [04:42] a really bad one might take an entire day [04:42] A fraction of the time it took me to recover the three boxes it corrupted. [04:43] if we have a only thousand of those, that's three years of one developer's time! [04:43] we receive several hundred bugs a day [04:43] (at this point, it's probably closer to a thousand a day) [04:43] did anyone record the UDS sessions? [04:44] https://blueprints.launchpad.net/ubuntu/+spec/bug-volume [04:44] so a large part of bug triage is waiting for new information [04:44] pwnguin, no [04:44] sad [04:44] pwnguin, well, not that we know of [04:44] sometimes it can be an offhand comment in a bug that leads you to explore a new idea [04:44] I'm on the buglist, I feel you on the sheer bolume. [04:44] *volume [04:44] and sometimes it's a skilled person who tracks the bug down themselves [04:44] mpt: I bet when we had it at Google HQ they recorded everything ;-) [04:45] the majority of Ubuntu developers are people just like you, who do this in their spare time simply because they love it [04:45] Wouldn't somebody (the sysadmins?) have recorded them through VoIP? [04:45] and there's only around ~100 developers [04:45] i bet google doesnt have a bug tracker. you just say that their software has a bug anywhere on the net and their super web searcher apps report it for you. [04:46]