[00:41] <johanbr> BigPick: A good place to start is to play with the video restore settings in /etc/default/acpi-support.
[01:28] <BigPick> So does Michael use IRC ever?
[01:28] <Fujitsu> BigPick: Which Michael?
[01:28] <BigPick> Vogt
[01:28] <Nafallo> yes
[01:28] <Fujitsu> Ah, he's mvo, and is often here.
[01:29] <BigPick> Sweet. I hoping to get some input from him.
[01:31] <BigPick> I may have some helpful information on the update-manager crashes.
[01:51] <Burgundavia> BigPick: attach any information to a bug, to prevent the data getting lost
[01:55] <BigPick> Already done. I've submitted full information and serveral experimental patches to both the update-manager and the python-apt packages.
[02:01] <Burgundavia> cool
[02:03] <BigPick> The problems arise from an odd anomally in the handling of the kubuntu-desktop metapackage.
[02:03] <BigPick> And wind up causing 2 different memory leaks.
[02:04] <BigPick> Its not one big problem, but several minor errors that compound.
[02:05] <BigPick> 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] <realist> Aren't all infinite loops 'accidental'?
[02:09] <Keybuk> not the ones that the kernel can do in 5s
[02:10] <realist> Isn't 5s finite?
[02:10] <BigPick> 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] <realist> BigPick: key word "until" ;-)
[02:11] <BigPick> Indeed :P
[02:11] <realist> I understand your point though :-)
[02:12] <BigPick> Hey, I was trying not to point any fingers :-D
[02:13] <BigPick> I was just emphasizing the "accidental", instead of like "negligent" or "incompotent" or something.
[02:16] <persia> 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] <BigPick> Exactly.
[02:18] <BigPick> 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] <pipegeek> 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] <pipegeek> Sometimes its days,
[02:24] <pipegeek> but certain conditions make it happen frequently
[02:24] <pipegeek> for instance,
[02:24] <pipegeek> If I'm running mencoder,
[02:24] <pipegeek> it takes about 5 minutes.
[02:24] <pipegeek> which is very, very annoying.
[02:24] <pipegeek> Have other people been reporting this behavior, or am I special? :P
[02:25] <pipegeek> actually, on second thought, this would probably be better suited for #ubuntu
[02:26] <pipegeek> sorry for bothering you guys.  Keep up the good work!
[02:27] <beuno> pipegeek, this is usually not the best place to ask, checking out bugs reported in Launchpad is probably the best way
[02:27] <pipegeek> thank you.
[02:27] <pipegeek> heading there right now
[02:27] <beuno> or opening threads in forums, this channel is specifically for development jiberish  :D
[02:27] <beuno> pipegeek, :D
[02:27]  * Fujitsu notes that Ubuntu mencoder doesn't actually link against any X libraries.
[02:28] <Nafallo> Fujitsu: should it?
[02:30] <bluefoxicy> ...
[02:30] <pipegeek> 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] <bluefoxicy> kees cook?
[02:30] <bluefoxicy> keescook:  ping
[02:30] <pipegeek> Fujistu: I should try compiling something big
[02:35] <Fujitsu> Nafallo: No, it's meant to not have anything to do with X.
[02:35] <Nafallo> Fujitsu: all good then? :-)
[02:36] <Nafallo> Fujitsu: aha. you answered something above :-P
[02:43] <pipegeek> Could I ask a general question of the devs here?  I'm just curious about something.
[02:43] <Fujitsu> pipegeek: Sure.
[02:44] <Fujitsu> (though most of the main devs are likely not here)
[02:44] <pipegeek> So, my understanding of the way ubuntu (and debian) releases are handled,
[02:44] <pipegeek> (that's ok, I figured :^) )
[02:44] <pipegeek> is that, once a release is final, the only changes that make it in are security fixes.
[02:44] <pipegeek> What I don't understand,
[02:45] <Fujitsu> Not quite. Important bugfixes can also be made after appropriate QA procedures.
[02:45] <pipegeek> 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] <pipegeek> aaah
[02:45] <pipegeek> so what's that process?
[02:45] <persia> !sru | pipegeek
[02:45] <ubotu> pipegeek: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
[02:46] <pipegeek> thanks, persia
[02:47] <pipegeek> 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] <pipegeek> There probably already is a bug for it
[02:47] <pipegeek> I should go comment on it
[02:48]  * Fujitsu has found Compiz to be completely stable since late in Gutsy cycle.
[02:48] <persia> 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] <pipegeek> represents a possibility for data loss, and it directly affects desktop, non technical users
[02:48] <pipegeek> righto
[02:49] <pipegeek> 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] <pipegeek> but then, it does have to get done....
[02:50] <pipegeek> Thanks, all.  I hope I haven't been too obnoxious...
[02:52] <persia> pipegeek:  Thanks for digging into the issue.  Please make sure there is a bug, and post your findings there.
[02:57] <Keybuk> meh @ .gtkrc
[02:58] <Keybuk> can't work out how to make the treeview expander things visible
[03:08] <Keybuk> HAHAHA
[03:08] <Keybuk> gcc developers rock
[03:08] <Keybuk> "in fact, assuming almost anything where a reasonable implementation could change, is not a good idea"
[03:09] <Keybuk> (googleing to see whether alloca() works inside inline functions :p)
[03:10] <Burgundavia> Keybuk: what gtk thing are you trying to work on
[03:10] <Burgundavia> ?
[03:11] <Keybuk> Burgundavia: running darklooks but with white input boxes
[03:11] <Keybuk> the triangle thing inside them is also white
[03:11] <Keybuk> and I can't figure out how to make it black
[03:12] <Burgundavia> right
[03:14] <BigPick> Okay... well... we all have out little battles I guess.
[03:49] <mpt> I think there should be a moratorium on the use of the word "Manager" for program names
[03:49] <Keybuk> agree
[03:49] <Keybuk> s/Manager/Kit/g
[03:49] <LaserJock> should we write a Word Manager to implement that?
[03:49] <LaserJock> maybe UI Manager
[03:50] <BigPick> Agreed.
[03:50] <mpt> Network Manager, Power Management, Restricted Drivers Manager
[03:50] <Keybuk> LaserJock: WordKit
[03:50] <LaserJock> heh
[03:50] <mpt> I don't want to manage any of those things, I want to *use* them
[03:50] <Keybuk> NetworkKit, PowerKit, RestrictedDriversKit
[03:50] <LaserJock> Bootloader Manager
[03:50] <BigPick> No not kit.
[03:50] <mpt> Kit is Maccy
[03:51] <Keybuk> BootKit
[03:51] <LaserJock> mpt: you ever give that SoC student a review of Bootloader Manager?
[03:51] <mpt> LaserJock, I thought I did and CCed you
[03:51] <LaserJock> ok
[03:51] <mpt> or did I just imagine I did?
[03:51] <BigPick> How about we get everything name * Manager to work correctly. :-D
[03:52] <LaserJock> you did early on I remember
[03:52] <Burgundavia> Pete Savage should have named his new thingy MessageKit
[03:52] <LaserJock> haha
[03:52] <LaserJock> Notification Manager?
[03:52] <BigPick> So far things named "Manager" are causing me no end of pain.
[03:52] <Keybuk> NotificationKit
[03:54] <mpt> http://web.archive.org/web/20051124192442/www.blakeross.com/images/splash-manager.gif
[03:54] <Keybuk> SplashKit
[03:54] <LaserJock> so we just need an UbuntuKit and UbuntuManager to wrap it all up and go home
[03:55] <Keybuk> LaserJockKit
[03:55] <LaserJock> noooooooo
[03:55] <LaserJock> although a LaserJock Manager sounds good
[03:55] <LaserJock> but that position's already been taken by my wife I think ;-)
[03:58] <mpt> ah, http://web.archive.org/web/20050912102712/http://www.blakeross.com/images/refcnt.gif
[03:59] <mpt> Those were the days
[03:59] <KeybukKit> mpt: http://www.kde.org/
[04:00] <Burgundavia> http://amarok.kde.org/
[04:00] <LaserJock> now we just need PittiManager
[04:01] <mpt> ah, found it
[04:01] <mpt> the list of managers Mozilla used to have
[04:01] <KeybukKit> you want to manage pitti?
[04:02] <mpt> Cookie Manager, Image Manager, Popup Manager, Form Manager, Password Manager, and Download Manager.
[04:02] <KeybukKit> PittiKit would be better ... make new pittis!
[04:02] <LaserJock> yeah, I suppose so
[04:02] <KeybukKit> mpt: rename them to monsters
[04:02] <KeybukKit> Cookie Monster
[04:02] <ion_> :-D
[04:02] <KeybukKit> Image monster
[04:02] <KeybukKit> Popup Monster
[04:02] <KeybukKit> Form Monster
[04:02] <KeybukKit> Password Monster
[04:02] <KeybukKit> Download Monster
[04:02] <LaserJock> lol
[04:02] <evand> can we?
[04:03] <ScottK> Network Monster would be pretty accurate.
[04:03] <evand> can we *please*?
[04:03] <LaserJock> man, what fun April Fools we could do with that
[04:03] <mpt> evand, Seamonkey's in Universe, right? Take over the package and Do It :-)
[04:03] <BigPick> I vote Network Monster.
[04:04] <Burgundavia> Vote Network Monster in 2008!
[04:04] <evand> hrmm, perhaps
[04:04] <Burgundavia> Network Monster for President!
[04:05] <BigPick> Ugh, god. If I sat down and wrote a replacement for NetworkManager, would it stand a chance of being adopted?
[04:05] <Burgundavia> no
[04:05] <mpt> LaserJock, actually, I'm glad you mentioned the Bootloader Manager -- were you the mentor?
[04:05] <Burgundavia> work on upstream NetworkManager, BigPick
[04:05] <LaserJock> mpt: yeah
[04:05] <Burgundavia> replace Usplash with Gnash!
[04:05] <Fujitsu> 0.7 looks like it might sorta work a bit properly sort of.
[04:05] <Burgundavia> lots of bugs in NM are actually driver bugs
[04:05] <KeybukKit> BigPick: no, better to improve NM
[04:05] <KeybukKit> NM is actually not *that* bad
[04:06] <Burgundavia> like the whole "freeze my whole fucking computer bug"
[04:06] <LaserJock> it generally works fine for me
[04:06] <Burgundavia> thanks Atheros
[04:06] <mpt> LaserJock, how did it end up?
[04:06] <BigPick> If you can get it to stop hardlocking my computer I'll believe you.
[04:06] <LaserJock> mpt: ok I guess
[04:06] <KeybukKit> BigPick: if it hard locks, it's a driver bug
[04:06] <KeybukKit> BigPick: an NIH rewrite would lock the same way
[04:06] <LaserJock> mpt: I think its got some potential
[04:06] <nixternal> wicd for gnome > network mangler
[04:06] <Fujitsu> 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] <mpt> LaserJock, I'm wondering if it could be merged with Power M_____r
[04:06] <BigPick> No its not. I can confirm the lock on three seperate machines, two of which don't even have wireless drivers.
[04:07] <nixternal> but don't tell people I have been running Gnome, I will never hear the end of it :)
[04:07] <LaserJock> mpt: but I think the goal needs to be broader than "let's be yet another menu.lst GUI"
[04:07] <mpt> "Startup & Shutdown"
[04:07] <KeybukKit> BigPick: anything that hard locks a machine is a driver bug
[04:07] <Fujitsu> BigPick: NM simply can't lock the system itself.
[04:07] <LaserJock> mpt: yeah, something like that
[04:07] <Burgundavia> BigPick: NM manages non-wireless cards as well
[04:08] <LaserJock> I really wanted to have an option so that you could choose an OS to reboot into at logout
[04:08] <Burgundavia> yes, an 8th logout option
[04:08] <mpt> LaserJock, yeah, that's what I'm wondering
[04:08] <BigPick> 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] <LaserJock> Burgundavia: well, that's another issue
[04:08] <BigPick> *cant't
[04:09] <YokoZar> 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] <mpt> ( Shut Down Now ) ( Restart ) ( Restart Into BeOS )
[04:09] <KeybukKit> BigPick: no it doesn't.
[04:09] <Burgundavia> LaserJock: what is? management of wired cards?
[04:09] <Fujitsu> Isn't the logout dialog being redone for Hardy, mpt?
[04:09] <Burgundavia> Fujitsu: yes
[04:09] <mpt> Fujitsu, hopefully, that's why I'm asking
[04:09] <BigPick> No it doesn't what?
[04:09] <KeybukKit> doesn't use all available memory
[04:09] <KeybukKit> and doesn't refuse to die
[04:09] <KeybukKit> if you can't kill -9 it => driver bug ;)
[04:10] <LaserJock> Burgundavia: having too many logout options
[04:10] <Burgundavia> LaserJock: yes, well there are ways to get around that
[04:10] <YokoZar> KeybukKit: So do I presume these are ati driver bugs and refile them against that package?
[04:10] <Burgundavia> if driver bugs were not an issue, I would only have Hibernate and Suspend
[04:11] <KeybukKit> YokoZar: nvidia binary graphics driver bugs
[04:11] <LaserJock> Burgundavia: as the only options for logout?
[04:11] <BigPick> Look, when I don't have NetworkManager doesn't load, the problem doesn't happen.
[04:11] <Burgundavia> LaserJock: and logout, but yes
[04:11] <YokoZar> KeybukKit: So I think I should mark incomplete and then target nvidia or ati
[04:11] <YokoZar> once they give driver version
[04:11] <BigPick> *when I don't have network manager load.
[04:11] <Burgundavia> LaserJock: no need for reboot, as that can be done via prompting. Shutdown is not needed. We should be saving sessions
[04:12] <Burgundavia> thus leaving you at two options: turn my system off or not
[04:12] <KeybukKit> BigPick: I find that my computer is bug free all the time it's switched off ;)
[04:12] <BigPick> KeybukKit: Yeah, funny how that works.
[04:12] <Burgundavia> BigPick: the possibility is that NM is exposing a bug not previously exposed
[04:12] <persia> Burgundavia: But what if I just upgraded to the newest shiny release, and need to reboot to get the new kernel & libc?
[04:12] <KeybukKit> Burgundavia: suspend happens when you close your lid
[04:12] <mpt> Burgundavia, I'm assuming that we can't fix all session management bugs for Hardy
[04:13] <mpt> And even if we could, I'm not sure that would alter the design at all
[04:13] <persia> KeybukKit: There's also desktop suspend.  Less common, but present
[04:13] <BigPick> KeybukKit: Even if it is a driver bug, why doesn't it occur since I started manually configuring my interfaces?
[04:13] <Burgundavia> persia: that would happen via the update-notifier dialogue (ie: it is a special case that happens only once in a while)
[04:13] <Burgundavia> mpt: we would need to fix those bugs as well, but the driver one is a killer
[04:13] <mpt> persia, handled by a configurable timeout
[04:13] <persia> Burgundavia: Ah.  So I'd select "reboot" from that dialog, and then go back to suspend/hibernate?
[04:13] <KeybukKit> BigPick: because NM is probably tickling the bug by being useful
[04:14] <Burgundavia> persia: no, reboot would be on another dialog, the one telling you had to reboot
[04:14] <KeybukKit> it scans wireless networks regularly
[04:14] <persia> mpt: Use case being "I want it suspended now", but I see your point.
[04:14] <KeybukKit> and checks the link sense on wired network interfaces, etc.
[04:15] <BigPick> KeybukKit: HAHAHA ah, thats awsome. Nothing like just passing off blame for problems :-D
[04:15] <manchicken> 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] <persia> 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] <KeybukKit> BigPick: nothing to do with passing off blame
[04:15] <Burgundavia> persia: yes, absolutely
[04:15] <KeybukKit> it's to do with accurate triage of the problems at hand
[04:15] <Burgundavia> if you were a developer needing to reboot, you are a developer. You know how to use a terminal
[04:15] <manchicken> The problem is that when you connect to the VPN using the openvpn setup, network-manager wipes out your resolv.conf.
[04:16] <mpt> 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] <mpt> (aka "eeeeeeedge case")
[04:17] <persia> 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] <KeybukKit> NM does not cause world hunger
[04:17] <Burgundavia> mpt: suspending for sane power management is not really an edge case
[04:17] <KeybukKit> don't get me wrong
[04:17] <Fujitsu> persia: Hibernate doesn't always work.
[04:17] <KeybukKit> I hate it as much as the next person
[04:17] <KeybukKit> but I'm aware that most of the problems aren't its fault
[04:17] <persia> Burgundavia: Desktop-immediate-suspend vs. desktop-lock-timeout-suspend
[04:17] <KeybukKit> like the fact it crashes several times a day while here
[04:17] <Burgundavia> oh
[04:17] <KeybukKit> it's in uninterruptible sleep; that's a kernel issue
[04:17] <BigPick> 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] <persia> Fujitsu: As an ideal, it's a good goal.  For my workstation, it's also useless.
[04:17] <KeybukKit> (proven by the fact that I often have to remove and reprobe the ipw3945 module)
[04:18] <mpt> persia, actually, another part of the spec is combining those two
[04:18] <KeybukKit> BigPick: bcm is ... incomplete :)
[04:18] <mpt> Burgundavia, what do you mean?
[04:18] <Burgundavia> Fujitsu: there is also the issue of dual boot + hibernate is really not good
[04:18] <Burgundavia> mpt: sorry, I was confused
[04:18] <KeybukKit> BigPick: it's also worth pointing out that the bcm43xx driver is also deprecated ;)
[04:18] <persia> Burgundavia: Why not?  Would it be better if file buffers were always flushed?
[04:18] <BigPick> KeybukKit: And considering the problem occurs even if bcm43xx is blacklisted.
[04:19] <KeybukKit> BigPick: could be a problem with your wired card
[04:19] <KeybukKit> tg3?
[04:19] <persia> mpt: combining which two?
[04:19] <Burgundavia> persia: issues with stuff moving around when the other os is running
[04:20] <mpt> 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] <persia> Burgundavia: Ah.  Right.
[04:20] <LaserJock> 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] <persia> 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] <BigPick> 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] <BigPick> 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] <Burgundavia> BigPick: don't get frustrated
[04:22] <KeybukKit> BigPick: well, err, given NetworkManager isn't written in Python ... ;)
[04:22] <BigPick> yes, but knetworkmanger is, which is where my stack traces are leading to.
[04:23] <KeybukKit> if you can demonstrate bugs in NetworkManager, I'm sure that they'll be rapidly fixed
[04:23] <KeybukKit> likewise for the KDE applet for it
[04:23] <KeybukKit> but if you're seeing anything other than simple silly bugs, like hardware lock-ups, you're definitely seeing kernel bugs
[04:23] <KeybukKit> (a lot of NM's issues also come down to missing kernel support for things)
[04:25] <BigPick> 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] <Burgundavia> it is not a mentality, it is the truth
[04:25] <Burgundavia> bugs exist at different layers
[04:26] <BigPick> 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] <Burgundavia> NM refuses to work around stupid bugs, which is generally good
[04:26] <KeybukKit> BigPick: thanks very much!  I wish more technically-inclined users would help out in that way
[04:26] <LaserJock> mpt: wow, this turned out a lot better than I thought
[04:26] <Burgundavia> have you been able to connect with mvo?
[04:26] <mpt> Burgundavia, if it doesn't give good error message, that's bad
[04:26] <Burgundavia> mpt: you speaking about NM failing?
[04:27] <mpt> yes
[04:27] <LaserJock> mpt: I just got the latest code for Bootloader Manager and took a bunch of screenshots
[04:27] <KeybukKit> good error messages are expected in 2-3 years ;)
[04:27] <mpt> LaserJock, you didn't look at it again until now? :-X
[04:27] <Burgundavia> mpt: one of the nasty bugs that you really cannot warn the user about is that Atheros reports strength wrong (too weak)
[04:27] <KeybukKit> Burgundavia: err, I *fixed* that!
[04:27] <Burgundavia> KeybukKit: you fixed it? I don't see said fix...
[04:27] <Burgundavia> hmm
[04:27] <LaserJock> mpt: not the final stuff, he's worked on it since I last looked
[04:27] <KeybukKit> but then I stopped having an Atheros card, so it's entirely likely it got unfixed
[04:27] <BigPick> No, I have not. And so far my only responses from other developers have been that the problem doesn't meet SRU
[04:28] <LaserJock> mpt: the whole SoC thing was ... interesting
[04:28] <KeybukKit> BigPick: we very very *very* rarely SRU
[04:28] <Burgundavia> LaserJock: SoC tends to produce such code
[04:28] <BigPick> So nothing is done instead?
[04:28] <KeybukKit> we always have another release out within 6 months
[04:28] <KeybukKit> it's fixed for the next release
[04:28] <KeybukKit> (assuming your patch was accepted?)
[04:29] <BigPick> It hasn't been considered.
[04:29] <KeybukKit> what's the bug#?
[04:29] <LaserJock> Burgundavia: I think this project has a chance
[04:29] <LaserJock> people really want something
[04:29] <Burgundavia> 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] <Burgundavia> LaserJock: people wanting something != project has a chance
[04:29] <BigPick> Bug 107188
[04:29] <ubotu> Launchpad bug 107188 in update-manager "[MASTER] [kde] Upgrade tool crashed with " Cannot allocate memory"" [High,Confirmed] https://launchpad.net/bugs/107188
[04:30] <Burgundavia> if wishes were horses, I would have a better latop
[04:30] <BigPick> This bug has existed for over a year. I had the same issue during Edgy->Feisty.
[04:30] <LaserJock> Burgundavia: no, I'm saying it has a chance *and* people seem to want it
[04:30] <Burgundavia> LaserJock: right
[04:30] <KeybukKit> BigPick: it's kde specific?
[04:30] <LaserJock> but it really does need to get picked up
[04:31] <BigPick> BigPick: No, I gave a detailed explanation of why it wasn't.
[04:31] <BigPick> I just refrenced myslef....LMAO
[04:31] <mpt> LaserJock, I get the impression that the proportion of Ubuntu SoC projects that actually end up in Ubuntu is alarmingly small
[04:31] <mpt> Though maybe I just look at the wrong ones
[04:31] <KeybukKit> mvo seems quite active on that bug
[04:31] <BigPick> No, it is not kde specific, but it is caused by an anomaly in kubuntu-desktop.
[04:32] <Fujitsu> mpt: Which ones have made it in?
[04:32] <BigPick> Check the dates.
[04:32] <mpt> Fujitsu, no idea
[04:32] <BigPick> Bug 154195
[04:32] <ubotu> Launchpad bug 154195 in ubuntu "Gutsy cdromupgrade script fails" [Undecided,New] https://launchpad.net/bugs/154195
[04:32] <LaserJock> mpt: I think that's an Ubuntu problem and not an SoC problem
[04:33] <BigPick> Thats the bug I filed for the second memory leak as reported by the user "Christian Assig" patch also included.
[04:33] <KeybukKit> BigPick: right, your patch is very very recent
[04:33] <pwnguin> colorfilter made it into ubuntu
[04:33] <Fujitsu> pwnguin: Aha, true.
[04:34] <pwnguin> i thought it was kinda nifty
[04:34] <LaserJock> mpt: check out the screenshots at http://laserjock.us/files/ubuntu/soc/
[04:34] <BigPick> No, not that date, mvo's last response to the bug was six months ago.
[04:34] <pwnguin> but not finished
[04:34] <KeybukKit> BigPick: there was no new information until your post though
[04:34] <pwnguin> for example, it would have been neat to have a "this is what colorblind people see" set of filters
[04:35] <Burgundavia> pwnguin: that has been suggested a lot fo times
[04:35] <pwnguin> i thought it was just me
[04:35] <KeybukKit> BigPick: simple reality is that we have more users than we have developers
[04:35] <KeybukKit> number of bugs is proportional to number of users
[04:36] <KeybukKit> ergo we have more bugs than we have developers
[04:36] <pwnguin> i thought software was a commodity :P
[04:36] <KeybukKit> 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] <KeybukKit> which you've done
[04:36] <KeybukKit> which is great ;)
[04:36] <BigPick> I understand, but this is the first time it has been acknowledged as "new information"
[04:36] <KeybukKit> I've tagged the bug so that mvo knows there's a patch on it
[04:37] <Burgundavia> 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] <KeybukKit> 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] <mpt> 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] <BigPick> 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] <KeybukKit> from the text above in the bug, that was a reasonable explanation
[04:38] <Fujitsu> Burgundavia: Attaching something marked as a patch flags it, and allows us to search.
[04:38] <Burgundavia> Fujitsu: does it now?
[04:38] <Fujitsu> Burgundavia: It has for at least a year.
[04:38] <BigPick> You can see how it is extremely frustrating for a non-developer to try and submit this stuff.
[04:38] <Burgundavia> Fujitsu: I have been using LP for so long, sometimes I miss these things
[04:38] <KeybukKit> indeed, which is why we encourage non-developers to use the answer tracker rather than the bug tracking system
[04:39] <Fujitsu> Burgundavia: It has been there as long as I can remember, I think.
[04:39] <Fujitsu> Which is a good couple of years.
[04:39] <Fujitsu> And more.
[04:39] <Burgundavia> hmm, maybe you are right
[04:39] <Burgundavia> likely it is just not very obivous
[04:39] <Burgundavia> LP is like that
[04:39] <Fujitsu> Yeah.
[04:40] <KeybukKit> I appreciate that you worked hard on the patch
[04:40] <KeybukKit> and triumphantly submitted it to LP thinking you'd get a quick response
[04:41] <KeybukKit> 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] <BigPick> Its not a quick response issue. I'm not trying to toot my own horn here.
[04:41] <KeybukKit> we've finished one release, and are opening the next
[04:42] <BigPick> I'm trying to point out how a major bug like this has been continuing over three release cycles now.
[04:42] <KeybukKit> many bugs like that persist
[04:42] <KeybukKit> sad reality of software development
[04:42] <KeybukKit> how much time would you estimate you spent tracking it down?
[04:42] <KeybukKit> 6 hours?  10 hours?
[04:42] <KeybukKit> a really bad one might take an entire day
[04:42] <BigPick> A fraction of the time it took me to recover the three boxes it corrupted.
[04:43] <KeybukKit> if we have a only thousand of those, that's three years of one developer's time!
[04:43] <KeybukKit> we receive several hundred bugs a day
[04:43] <KeybukKit> (at this point, it's probably closer to a thousand a day)
[04:43] <pwnguin> did anyone record the UDS sessions?
[04:44] <mpt> https://blueprints.launchpad.net/ubuntu/+spec/bug-volume
[04:44] <KeybukKit> so a large part of bug triage is waiting for new information
[04:44] <mpt> pwnguin, no
[04:44] <pwnguin> sad
[04:44] <mpt> pwnguin, well, not that we know of
[04:44] <KeybukKit> sometimes it can be an offhand comment in a bug that leads you to explore a new idea
[04:44] <BigPick> I'm on the buglist, I feel you on the sheer bolume.
[04:44] <BigPick> *volume
[04:44] <KeybukKit> and sometimes it's a skilled person who tracks the bug down themselves
[04:44] <LaserJock> mpt: I bet when we had it at Google HQ they recorded everything ;-)
[04:45] <KeybukKit> the majority of Ubuntu developers are people just like you, who do this in their spare time simply because they love it
[04:45] <Fujitsu> Wouldn't somebody (the sysadmins?) have recorded them through VoIP?
[04:45] <LaserJock> and there's only around ~100 developers
[04:45] <pwnguin> 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] <Fujitsu> LaserJock: We have exactly 100 in ~ubuntu-dev at the moment.
[04:46] <Fujitsu> And a lot of them are inactive.
[04:46] <pwnguin> Fujitsu: i assumed if icecast was set up, there'd be a recording
[04:46] <KeybukKit> Fujitsu: as mentioned in the wrap-up, recording likely requires consent
[04:46] <mpt> Fujitsu, that was discussed at the wrapup session, and (afaict) the answer was no
[04:46] <BigPick> I understand the logistics, I understand the passion. But when my co-workers ask me why kubuntu would release a new version if the ugrader caused our computers to become inoperable... how am I supposed to answer them.
[04:46] <Fujitsu> KeybukKit: Ah, true.
[04:46] <pwnguin> heh, recording requires consent, but broadcasting doesn't?
[04:47] <persia> KeybukKit: That just requires advertisement that there is an open channel, and all activites are being recorded.
[04:47] <BigPick> I have since had to revert our linux boxes back to Windows.
[04:47] <KeybukKit> BigPick: Kubuntu will release a version within the next six months
[04:47] <persia> pwnguin: Actually, the same rules apply, but it's harder to show evidence of transient broadcasting without recording it oneself, which makes it null due to cross-violations
[04:47] <KeybukKit> we *always* release a new version within the next six months
[04:48] <mpt> pwnguin, you're right about the Google bug tracker. http://daringfireball.net/2004/05/writing_for_google
[04:48] <pwnguin> heh
[04:48] <pwnguin> awesome
[04:48] <pwnguin> i was thinking that might be the case the other day when i found a bug in liferea / google video rss
[04:48] <BigPick> KeybukKit: I told them that six months ago when the same thing happened to our Edgy installs. And they believed me. Its six months later and I can't ask them to believe that again.
[04:48] <pwnguin> cuz about 4 days after i filed the bug in liferea, the rss changed
[04:49] <KeybukKit> BigPick: until the bug is marked Fix Released, there's no guarantee
[04:49] <KeybukKit> and, not to put too fine a point on it
[04:49] <KeybukKit> when did Microsoft last respond to a bug report you filed on Windows?
[04:49] <KeybukKit> and what's their average turn-around time on bug fixes?
[04:49] <mpt> mswish@microsoft.com
[04:51] <persia> KeybukKit: That's not entirely fair.  Microsoft does respond to bug reports for some customers, and does send fixes, sometimes even quickly.  I also think we're faster, but...
[04:52] <KeybukKit> persia: paying customers ;)
[04:52]  * pwnguin notes that canonical sells rapid reponse contracts
[04:52] <pwnguin> rather cheaply last i looked
[04:52] <KeybukKit> not just customers that pay for the software either
[04:52] <KeybukKit> you have to pay more on top for the support
[04:52] <persia> KeybukKit: I'd rather consider them "Customers with valid licenses", but sure...
[04:53] <persia> KeybukKit: Well, depends.  Sufficiently large userbases (>5000 users) tend to get a bit of support even when they haven't paid for extra, but that's admittedly different.
[04:55] <BigPick> I'm sorry but I don't consider that to be in keeping with our mission.
[04:56] <KeybukKit> our mission doesn't escape the fact that even if we hired every single Linux developer there is, we still couldn't give every single bug the attention it deservers
[04:57] <LaserJock> BigPick: I certainly understand the frustration, it's just a very difficult problem
[04:57] <pwnguin> KeybukKit: im not sure on that
[04:57] <pwnguin> KeybukKit: but its certainly not a cheap option
[04:58] <mpt> LaserJock, those screenshots are pretty scary
[04:58] <BigPick> Six months difficult?
[04:58] <mpt> Nested tabs! That's the first time I've seen those in the past several years
[04:59] <KeybukKit> BigPick: ?
[04:59] <KeybukKit> six months is our release schedule period
[05:00] <BigPick> This bug was originally nominated for Feisty. As you can see Cimmo has now nominated it for Hardy.
[05:01] <KeybukKit> yes, but without a fix, that's meaningless
[05:01] <KeybukKit> the bug hasn't had a patch until last week
[05:02] <BigPick> And I still don't understand how that can happen. We are talking about the official upgrade process here, not some universe package.
[05:03] <pwnguin> if its very hard to reproduce, that would be one reason
[05:03] <KeybukKit> because there was nothing in the bug to suggest it was anything other than a low memory condition
[05:03] <KeybukKit> it only appeared to (and was tagged to say) it only affected Kubuntu, which is largely community supported
[05:04] <KeybukKit> and as pwnguin says, it was probably hard to reproduce
[05:04] <BigPick> There are 85 duplicate reports.
[05:04] <KeybukKit> (given that kubuntu upgrades are tested every single release, and nobody encountered it)
[05:05] <KeybukKit> right, but those duplicates don't *add new information*
[05:05] <KeybukKit> you were the first person to do taht
[05:05] <KeybukKit> so Michael would have had to spend days, maybe even weeks, just on that *one bug*
[05:05] <BigPick> The reports clearly state that the bug cause the upgrader to crash and in many instances rendered the machine unbootable.
[05:06] <KeybukKit> we have far more serious bug reports than that
[05:07] <desrt> KeybukKit; dpkg list says "say it ain't so!"
[05:07] <KeybukKit> we do, honestly, try to fix as many bugs as we can
[05:08] <KeybukKit> desrt: ? :)
[05:08] <desrt> actually, this guy named joey wrote an extremely detailed and thoughtful reply
[05:08] <desrt> explaining why he thinks it is a bad idea
[05:08] <BigPick> Wait... if the machine becomes unusable... I'm not sure how much worse it can get. I lost six months of data that I had to recover off a backup server.
[05:09] <KeybukKit> BigPick: if 8,000,000 machines become unusable, it's worse than 80
[05:09] <Fujitsu> BigPick: It corrupted the filesystem?
[05:09] <BigPick> Yes, it corrupted the filesystem on one of my boxes.
[05:09] <KeybukKit> BigPick: how did it corrupt the filesystem?
[05:09] <desrt> KeybukKit; wrote back.  we'll see what comes of it.
[05:10] <KeybukKit> BigPick: what happened when you selected recovery mode?
[05:10] <BigPick> On another it left KDE half installed, and on the third, I had use a live CD to chroot and reinstall the image.
[05:10] <KeybukKit> ok, so it didn't corrupt the filesystem
[05:10] <KeybukKit> it just left the upgrade part-finished
[05:10] <KeybukKit> your data was intact
[05:10] <KeybukKit>   dd if=/dev/random of=/dev/hda1  <=  corrupted filesystem
[05:12] <BigPick> No, on one server my ext3 partitions, including /home/ reported bad master blocks. No I could of fired up my knoppix CD and spent several hours fscking it but I went with the backup.
[05:12] <KeybukKit> that would not have been caused by the upgrade failure
[05:12] <BigPick> It worked before.
[05:12]  * Fujitsu doesn't often see dpkg screwing around below the VFS level.
[05:13] <mpt> persia, https://wiki.ubuntu.com/LogoutDialog
[05:14] <KeybukKit> mpt: random rename? :p
[05:15] <mpt> KeybukKit, I like puns
[05:15] <Fujitsu> mpt: I like to be able to close my lid without suspending, TYVM.
[05:16] <KeybukKit> Fujitsu: that's in the Power Management prefs
[05:16] <pwnguin> mpt: that article wasn't quite what i meant, interesting none the less
[05:18] <mpt> ugh, wiki.ubuntu.com's <dl><dt><dd> presentation is wonky
[05:18] <pwnguin> mpt: also, i cant help but really not trust Vista's hybrid suspend.
[05:18] <persia> mpt: 1) mobile-as-PMP: can suspend be triggered on lack of audio, rather than lid close?
[05:19] <mpt> Fujitsu, what KeybukKit said (and see "Assumptions" #4)
[05:19] <persia> 2) workstation as home server: can desktop-suspend-after-timeout be disabled by default?
[05:19] <persia> 3) What about hardware for which the support isn't there (like my current workstation)
[05:19] <pwnguin> persia: 2) afaik, gnome won't even present suspend or hibernate if it doesnt believe it can be done
[05:20] <mpt> persia, (1) What's PMP?
[05:20] <Fujitsu> mpt: It seems pretty silly to remove the suspension option from the UI entirely.
[05:20] <persia> pwnguin: GNOME isn't onniscient :)
[05:20] <Fujitsu> At least an option to bring the button back would probably make sense.
[05:20] <mpt> persia, (2) Sure, "Never" would be at one end of the slider
[05:20] <persia> mpt: Personal-media-player.  My 4.7" laptop has a 6GB drive, which is sufficient for a bit of music.  I often close the lid and use earphones when I'm on the train.
[05:20] <mpt> persia, (3) see (2)
[05:21] <persia> mpt: For (2), (3), I guess I'm just asking for "Never" to be default.  I'd rather have to explain how to enable power-savings for desktops than explain why things stop working.  This is especially interesting for use cases like home music server, mythtv, etc.
[05:22] <mpt> persia, so you have an iPod Kilo?
[05:22] <persia> mpt: Zaurus
[05:22]  * mpt ducks
[05:22]  * Fujitsu has been very irritated on multiple occasions when he has been copying stuff from a machine, and it went to sleep.
[05:22] <mpt> persia, I expect "Never" would be the default, yes
[05:23] <Fujitsu> Ah, good.
[05:23] <mpt> For "When Using Mains Power", at least
[05:23] <persia> mpt: Excellent.  Other than the specialised case of mobile-as-PMP, it looks great.  Thanks for the writeup.
[05:23]  * pwnguin really dislikes the idea of transitioning from suspend to hibernate
[05:23] <persia> mpt: Most desktop use cases are always "When Using Mains Power", no?
[05:24] <Fujitsu> pwnguin: But Vista does it!
[05:24] <persia> pwnguin: Why?  If my battery is low, wouldn't it be better to save state in hibernate then silently crash?
[05:24] <pwnguin> Example: close the lid, place in backpack. halfway to your class, disk activity ensues
[05:24] <pwnguin> your drive is now active while being bounced around...
[05:24] <Fujitsu> Wouldn't it have to write the RAM out before sleeping?
[05:25] <KeybukKit> ==15087== Warning: invalid file descriptor 1021 in syscall open()
[05:25] <KeybukKit> err. WTF?!
[05:25] <Fujitsu> It can't wake up due to low power, surely..
[05:25] <persia> pwnguin: Good point.  Extra bonus for including motion sensors in all portable devices.
[05:25] <pwnguin> heh
[05:25] <pwnguin> Fujitsu: vista does it!
[05:25] <mpt> persia, right, so if you're using a computer that doesn't have a battery you wouldn't have the "When Using Battery" tab at all
[05:25] <persia> Fujitsu: No, but it can wake up after a configurable timeout, and then hibernate.
[05:25] <Fujitsu> persia: Ah, true.
[05:25] <Fujitsu> pwnguin: I think it writes out to the swap partition first.
[05:26] <persia> mpt: What about mobile-PMP.  I think that's better solved by trapping suspend to not happen during audio playback, but I'm really not sure how to implement that with the current ACPI-events model.
[05:26] <pwnguin> question: whats the difference between switch user and lock screen?
[05:27] <Fujitsu> persia: Or even just sitting-on-the-desk-PMP.
[05:27] <KeybukKit> pwnguin: lock screen is a security feature
[05:27] <persia> (Zaurus suspends when the playlist is complete)
[05:27] <pwnguin> KeybukKit: and switch user isnt?
[05:27] <persia> Fujitsu: In that case, it's not as obnoxious to keep the lid open.
[05:27] <KeybukKit> pwnguin: switch user is changing user on the machine
[05:27] <Fujitsu> persia: This is true.
[05:27] <KeybukKit> lock screen is because you're leaving your laptop unattended in a room of people you don't trust not to say rude things on IRC with your nickname
[05:27] <Fujitsu> Weren't Switch User and Lock Screen meant to be merged in unify-login-unlock?
[05:27] <persia> pwnguin: Good point.
[05:27] <mpt> persia, that's an interesting question. I'm not sure that's more common than a bunch of other "Sleep if X" cases, for which it would be better to write a script than to have checkboxes for them all.
[05:27] <KeybukKit> eventually
[05:28] <pwnguin> if gdm was a bit smarter about tracking who's logged in
[05:28] <pwnguin> i think you could merge the two ala XP
[05:28] <KeybukKit> pwnguin: yeah
[05:28] <persia> mpt: Perhaps.  Do you see timeout-suspend having a different hook than lid-close suspend?
[05:28] <KeybukKit> and if we could switch to gdm without having to fire up another X server ...
[05:28] <KeybukKit> ;)
[05:29] <mpt> persia, sorry, don't know what you mean by "hook"
[05:29] <mpt> I are just a UI designar
[05:30] <persia> mpt: triggering different scripts.  Currently lid-close triggers /etc/acpi/lid.  I don't know how timeout works.  If both then called the same configurable "I'm suspending" model, it makes sense.  In most implementations I've seen, /etc/acpi/lid just calls the suspend routines fairly directly.
[05:31] <persia> mpt: To put it in UI terms: do you imagine that a user should expect different behaviour from timeout and lid close?
[05:32]  * pwnguin thinks you should fix totem before trying any suspend on idle shennanigans
[05:32] <persia> mpt: The argument for different behavioiur is that lid-close typically indicates intent.  The argument for the same behaviour is that it makes things like mobile-as-PMP easy.
[05:33] <KeybukKit> pwnguin: "fix totem" ?
[05:33] <mpt> persia, I don't know enough to have a useful opinion about that.
[05:33] <pwnguin> KeybukKit: for some reason it fails to actually disable dpms
[05:33] <mpt> For example, I don't know how common it is for other scripts to call /etc/acpi/lid already.
[05:33] <pwnguin> i guess that your timer would be based on gnomescrensaver, which i think it handles correctly
[05:35] <persia> mpt: OK.  Ignore implementation.  Just in terms of behaviour.  As a UI expert, how much do you believe the lid-close action indicates a specific intent to disable the computer, vs. indicating that input and video output are likely suspended for a while?
[05:35] <desrt> it is quite an annoying historical accident that the gplv3 wasn't around for khtml >:|
[05:35] <Mithrandir> desrt: how so?
[05:35] <desrt> think: iphone
[05:36] <Mithrandir> well, the iphone is quite easy to get into
[05:36] <desrt> true enough
[05:36] <pwnguin> note that converting a tablet PC from laptop to tablet mode will trigger a lid event.
[05:37] <persia> pwnguin: Depends on the hardware.  For my Stylistic, there is no lid event (not a convertible).  For my Zaurus, there are two events, one for closed, and one for now in tablet mode
[05:37] <pwnguin> fortunately, it seems to be smart enough at the moment to check if the switch is open or closed before shutdown
[05:38] <pwnguin> persia: ive been chatting with another tecra m7 owner, and to the best of our knowledge acpi is missing an event
[05:39] <persia> pwnguin: That doesn't surprise me.  The Zaurus actually traps the "now closed" and "now in tablet mode" as /dev/input events
[05:39] <pwnguin> for our device at least
[05:41] <mpt> persia, I think it indicates intent to put laptops in low-/zero-power mode 99% of the time. What it means for other devices, I know only what you've just said to pwnguin.
[05:42] <persia> mpt: That makes sense.  So perhaps for i386/amd64, lid-close should be special, and just suspend, whereas for lpia, it might instead trigger a more nuanced suspend decision?
[05:42]  * persia wishes for an lpia device with the Zaurus form factor, or Ubuntu ARM
[05:42] <mpt> What's lpia?
[05:42] <pwnguin> low power intel arch
[05:42] <persia> mpt: The -mobile architecure (Low Power Intel Architecture)
[05:42] <pwnguin> i386 for seekret tech
[05:43] <mpt> What does the Classmate PC use?
[05:43] <Mithrandir> mpt: you might have heard of this project called ubuntu mobile?
[05:43] <Mithrandir> unsure, not lpia since they're not in production yet
[05:43] <mpt> Mithrandir, I have indeed
[05:43] <LaserJock> Mithrandir: is that like jdub's world tour? ;-)
[05:44] <LaserJock> mpt: it's a "regular" intel chip
[05:44] <mpt> See, this is why persia shouldn't be asking me these questions ;-)
[05:44] <Mithrandir> (also, I disagree with you about a wish to enter low power mode - people also quite often close their laptops when docking them)
[05:45] <LaserJock> mpt: Intel® Mobile Processor ULV 900 MHz, Zero L2 cache, 400 MHz FSB
[05:45] <persia> mpt: You're an expert on user-interaction.  My apologies when I ask questions with too many technical references: I'm really seeking your input on good UI.
[05:46] <persia> Mithrandir: Good point.  Do you think we should trigger the "what am I doing now" script on lid close, to check "am I docked?", "am I playing audio", "am I feeding video to an external device", etc.?
[05:46] <mpt> That might be nifty
[05:47] <persia> (with the idea that the "what am I doing now" script would also be called after n seconds for timeout suspends)
[05:47] <Mithrandir> persia: that might be a start.  I'm not convinced it's possible to know from a script either, but it'll at least stand a somewhat better chance
[05:48] <persia> Mithrandir: Just thinking blue-sky, I'm just thinking that we have a set of external events that triggers some plugin-based configurable utility to check if X conditions are true prior to suspending.  Of course, this requires 1) hardware support, 2) software support, 3) design, and 4) implementation.
[05:50] <Mithrandir> persia: how is the system going to know the difference between "I want to go to work and am closing the lid so the laptop will suspend" and "I want to move the laptop from one room to another, but I close it since it's then easier to carry"?  In the latter case, I might well want it to keep playing.
[05:50] <Mithrandir> so sure, it'd be a start.  I just don't think covering such a use case is feasible
[05:50] <pwnguin> frankly, im not even sold on "7 is too many buttons"
[05:51] <persia> Mithrandir: That's a tricky distinction, but I like the idea of using lid-close to do something, rather than having a menu entry.
[05:54] <Keybuk> Mithrandir: clearly playing something inhibits the suspend
[05:54] <Keybuk> if you're idle, it doesn't matter whether you suspend or not
[05:55] <Keybuk> on mobile, typically you'll want to micro-suspend a lot anyway
[05:55] <persia> Keybuk: So, always call the "what am I doing now" script?
[05:55] <Keybuk> but hardware into the lowest possible state
[05:55] <Keybuk> persia: no
[05:55] <Keybuk> never have any script to do that
[05:55] <persia> And yes, suspending to walk between rooms is normal for the mobile case
[05:55] <Keybuk> just use D-BUS to do the right things
[05:55] <pwnguin> theres a what am i doing state, and use dbus to set it?
[05:55] <Keybuk> you can use d-bus to inhibit screensaver or suspend, etc.
[05:56] <persia> Keybuk: Sure.  Implementation aside: always check current system state to make a suspend decision, rather than attempting to divine user intent.
[05:56] <Keybuk> (playing music might inhibit suspend, playing video might inhibit both)
[06:15] <persia> mpt: Any objection to the modification of the lid-close assumption in ExitStrategy?  I'm thinking something like: http://paste.ubuntu-nl.org/43090/
[06:17] <Keybuk> persia: objection is that it shouldn't check
[06:17] <Keybuk> it should simply be inhibited
[06:17] <Keybuk> out of scope for hardy
[06:17] <Keybuk> where we will simply go with what we have right now
[06:17] <Keybuk> (which is that your laptop suspends when you close the lid while on battery)
[06:17] <persia> Keybuk: Exit-strategy is in-scope for Hardy?
[06:17] <Keybuk> yes
[06:18] <persia> Ah.  Well, as I can't actually run Ubuntu on the device that would be affected, I'll not change anything.  Thanks.
[06:20] <mpt> persia, "docked" means connected to another computer?
[06:21] <pwnguin> not really
[06:21] <persia> mpt: Connected to a "dock" or "port replicator" device.  These generally allow external audio / video / input to a closed laptop/
[06:21] <mpt> ok
[06:22] <pwnguin> basically think of it as a converter from laptop to desktop
[06:22] <Fujitsu> persia: Why can't you run Ubuntu on it? ARM?
[06:22] <persia> mpt: So, one might get home, put the laptop in the dock, and use a real screen and keyboard at ones desk.  When one goes out, one undocks the laptop, and typical usage patterns resume.
[06:22] <persia> Fujitsu: Yep.  ARM.  The new Fujitsu devices are almost small enough, but they only fit in two of my suits.
[06:23] <pwnguin> Fujitsu: out of curiousity, is your name related to the manufacturer?
[06:24] <Fujitsu> pwnguin: This nick goes back several years. A friend decided wgrant wasn't a good enough username for my account on his system, and he had a Fujitsu hard disk next to him at the time..
[06:25] <pwnguin> hmm. on the one hand, i like using real names, on the other hand, pwnguin was just too awesome to pass up
[06:26] <pwnguin> maybe some day i'll hand this alias off to a bot and resume using my real name
[06:32] <mekius> Hi, custom live cd and when it boots up, update-notifier displays a few errors about some packages.  Is there a way to easily clear these?
[09:01] <hunger_t> When will xserver-xorg-core become installable again on hardy?
[09:06] <persia> hunger_t: When it gets fixed.  Is it blocking you in some way?
[09:06] <hunger_t> persia: Nope, I am just curious since it is broken for a couple of days now.
[09:07] <hunger_t> persia: I am on hardy... if a little breakage would block me then I would be pretty stupid to do that.
[09:07] <persia> hunger_t: The development summit was last week, and people are travelling now.  Unless it's blocking the people working, it probably won't get real attention until next week.
[09:08] <hunger_t> persia: Thats what I thought. But I was repeatedly told that merges were in full swing, even in spite of the summit and all:-)
[09:09] <persia> hunger_t: That's definitely been true.  Lots of stuff uploaded & merged.  Not so much attention to making sure it integrates yet.
[09:10] <Fujitsu> There are also several thousand builds still pending - I suspect the drivers that are needed for xserver 1.4 are yet to be built.
[11:34] <tepsipakki> hunger_t: there are still a lot of drivers not built against it, so it'll take a while
[11:35] <tepsipakki> oh, Fujitsu told that already :)
[11:37] <Fujitsu> Potentially another week or so.
[11:38] <tepsipakki> could be
[12:06] <Hobbsee> tepsipakki: anything interesting in it?
[12:07] <tepsipakki> Hobbsee: in X?
[12:07] <Hobbsee> tepsipakki: yeah, the new X stuff
[12:08] <tepsipakki> Hobbsee: well, the input-hotplug -support, which we need to sort out :)
[12:08]  * Hobbsee nods
[12:09] <tepsipakki> currently it's disabled by the newest hal, because it has some issues
[12:09] <persia> tepsipakki: Are there any good docs on that?  I've an excess of keyboards, mice, and joysticks attached, and am curious what will happen :)
[12:10] <tepsipakki> persia: when you have hardy, just put the fdi file from /u/s/d/hal/ in /etc/hal/fdi/policy, and off you go :)
[12:11] <tepsipakki> it should work pretty well
[12:11] <tepsipakki> I've played with it a bit
[12:11] <Hobbsee> tepsipakki: new revision of -intel hasnt broken yet, btw.  if you care :)
[12:11] <persia> tepsipakki: Right.  Are there any docs that could tell me what will happen before I do that?  I want to prepare adjustments for nostromo, gizmod, etc.
[12:12] <tepsipakki> Hobbsee: cool, bryce is happy then :)
[12:12] <Hobbsee> tepsipakki: you're supposed to break something, dammit!  :P
[12:12] <Hobbsee> hardy isnt supposed to mostly work.
[12:13] <tepsipakki> persia: docs about the i-h? I'm not sure, it's pretty simple to set up
[12:13] <tepsipakki> Hobbsee: well, it should also go to gutsy as SRU
[12:14] <persia> tepsipakki: That's about what I found before: simple config hints, overviews, and code.  No deep docs.  I'll chase code then.  Thanks.
[12:14] <tepsipakki> persia: heh, yeah. ask daniels on #xorg-devel if you want the dirty details ;)
[12:15] <persia> tepsipakki: Nah: I doubt they'll translate well on IRC (and he's busy enough that I don't want to complain too much about a lack of docs for something that just works (and is a clear improvement))
[12:16]  * tepsipakki nods
[13:24] <rohan> in this bug - https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/133677 - would be advisable to attach the files which are asked for individually, or as one gzip file ?
[13:24] <rohan> i've been asked to attach almost 6-7 files .. wouldn't it be too much 'spam' to attach each of them individually ?
[13:24] <ubotu> Launchpad bug 133677 in xserver-xorg-video-intel "System unusable after resume from suspend or hibernate" [Undecided,Incomplete]
[13:28] <Hobbsee> rohan: may as well add them all together
[13:30] <geser> rohan: both ways have it advantages and disadvantages: one file is only one attachment but everyone who wants to look at the files needs to unpack them first
[13:34] <rohan> Hobbsee: in a gzip file ?
[13:34] <rohan> geser: what do you suggest ?
[13:34] <Hobbsee> gzip file works.
[13:35]  * persia likes lots of little files, but LP is annoying so that makes lots of little comments, which is annoying
[13:38] <Hobbsee> pitti!
[13:38]  * Hobbsee hugs pitti
[13:38] <rohan> pitti: exactly !
[13:38] <pitti> Good morning!
[13:38]  * pitti hugs Hobbsee back
[13:39] <Hobbsee> :D
[13:39] <Hobbsee> pitti: what will you end up doing today, actually having a weekend off?
[13:39] <rohan> err sorry .. i meant persia not pitti
[13:40] <pitti> Hobbsee: I want do do some Debian stuff, go to lunch with some kernel guys, and visit the Boston science museum in the afternoon
[13:40] <rohan> well forget it i'll attach both :P
[13:40] <Hobbsee> pitti: nice :)
[13:40] <Hobbsee> pitti: poke StevenK onto irc please.
[13:40] <Hobbsee> if he's near you
[13:40] <pitti> Hobbsee: he's still happily snoring along in his bed :)
[13:40]  * pitti tries to not type too loudly
[13:40] <Hobbsee> pitti: *snort*.
[13:41]  * Hobbsee doubts you'll wake him up typing.
[13:43] <rohan> there should really be a way in launchpad to attach multiple files in a single step
[13:46] <persia> rohan: There should be.  Until then, a tar isn't that bad.
[13:46] <desrt> pitti; !
[13:46] <desrt> pitti; seb was sleeping (wtf!)
[13:46] <pitti> desrt: lazy French guys *tsk*
[13:46] <desrt> srsly.
[13:47]  * pitti hands desrt Hobbsee's long pointy stick
[13:47] <rohan> persia: hehe check out what i did .. https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/133677
[13:47] <ubotu> Launchpad bug 133677 in xserver-xorg-video-intel "System unusable after resume from suspend or hibernate" [Undecided,Incomplete]
[13:47] <desrt> eh.  he already looked annoyed enough that i woke him up by knocking on his door
[13:47] <desrt> better put the stick away :p
[13:48] <persia> rohan: That has all the disadvantages of both.  You generate all the bugmail for the different attachments, and you end up with a big binary blob on launchpad.
[13:54] <rohan> persia: exactly .. so i chose to the well .. ugliest way out it seems ;)
[13:56] <SoulSeeker> can anybody tell my what is SFS file system, and why my NTFS file system is named like that ?
[13:56] <jpatrick> !topic | SoulSeeker
[13:56] <ubotu> SoulSeeker: Please read the channel topic whenever you enter, as it contains important information. To view it at any time after joining, simply type /topic
[13:57] <rohan> persia: hehe, just got all the spam right now ;)
[13:57]  * Hobbsee takes her stick back from desrt, and smacks pitti
[13:57] <Hobbsee> mine!
[13:57] <SoulSeeker> sorry
[13:57] <rohan> Hobbsee: what is a desrt ? desert ?
[13:58] <Hobbsee> rohan: i think the guy might complain if we ate him.
[13:58] <Hobbsee> rohan: desrt is ryan lortie
[13:58] <geser> Hobbsee: doesn't you eat people regularly?
[13:58] <rohan> oh sorry it was a person ..
[13:58] <rohan> btw any idea who "unggnu" is ?
[13:59] <rohan> https://edge.launchpad.net/~unggnu/ --- no real name given :-/
[13:59] <Hobbsee> geser: depends - i prefer to stab them with a stick, instead.
[14:00] <Hobbsee> rohan: some people like using only an alias.
[14:00] <geser> rohan: I remember seeing that nick in #ubuntu-de (but not right now)
[14:00] <Hobbsee> i did, until they talked about giving me a plain ticket to come to a developer summit :P
[14:00] <rohan> Hobbsee: hahaha
[14:00] <rohan> did you get the plane ticket, after all ?
[14:00] <Hobbsee> oh yes
[14:01] <Hobbsee> sevilla was great.
[14:01] <rohan> which one ? boston ?
[14:01] <rohan> oh
[14:02] <geser> Hobbsee: how did you get your LongPointyStick into the plane? or did you travel without it?
[14:02] <Hobbsee> geser: i brought it with me.
[14:02] <Hobbsee> geser: magical powers
[14:03] <zul> because of that Hobbsee is now on the no-fly list
[14:03] <geser> Hi bddebian
[14:04] <Hobbsee> Sysinfo for 'LongPointyStick': Linux 2.6.22-14-generic running KDE 3.5.8, CPU: Genuine Intel(R) CPU           T2250  @ 1.73GHz at 1733 MHz (3458 bogomips), HD: 39/70GB, RAM: 1392/2018MB, 133 proc's, 7.12h up
[14:04] <Hobbsee> zul: nah...
[14:04] <bddebian> Heya gang
[14:04] <bddebian> Hi geser
[15:39]  * Keybuk tries to remember the spells and runes to summon jamiemcc
[15:39] <Burgundavia> talk about beagle
[15:40] <Nafallo> lol
[15:40] <Burgundavia> jamiemcc@blueyonder.co.uk <-- Keybuk
[15:41] <Nafallo> ehrm. no. Keybuk has another address...
[15:42] <Robot101> Nafallo: no he was giving jamiemcc's address to Keybuk :P
[15:42] <Nafallo> ;-)
[15:43] <Burgundavia> Robot101: you need to blog more telepathy stuffs
[15:44] <pitti> asac: do we actually need icedove-locales in Hardy? (it's imported from Debian)
[15:44] <Robot101> Burgundavia: probably true, yeah :P
[15:46] <Burgundavia> Keybuk: jamiemcc@blueyonder.co.uk
[15:46] <Burgundavia> if you didn't get it before you dropped off
[15:46] <Keybuk> Burgundavia: that would be fine, except tracker is hitting my system so hard I can't actually open evolution
[15:47] <Burgundavia> oh, geez
[15:47] <Burgundavia> beagle was doing that last night, with the 5GB fake drive qemu had created
[15:47] <Burgundavia> I was testing the developer preview live cd of solaris
[15:47] <Burgundavia> the live cd requires a hard drive to boot
[15:47] <Keybuk> tracker has apparently indexed every file and directory over 200 times
[15:47] <Keybuk> according to its own stats
[15:48] <Nafallo> lol
[15:48] <Mithrandir> Keybuk: so it's _really_ sure about what the file contains, then?
[15:48] <Nafallo> *asg~*
[15:48] <Hobbsee> Mithrandir: but it migth have changed!  it needs to check!
[15:48]  * persia wonders if there is +atime vs. +mtime confusion
[15:49] <Mithrandir> I guess Scott didn't run it with --disable-awty-mode
[15:51] <LaserJock> has it changed yet? .... has it changed yet? .... has it changed yet?
[15:51] <Keybuk> Mithrandir: I boot the kernel with noadd on the command line
[15:51] <hunger_t> tepsipakki: Thanks for the info on fix time for xorg-core. I assumed as much, but it is nice to get that confirmed.
[15:52] <Nafallo> LaserJock: rotfl
[15:53]  * hunger_t is afraid that LaserJock is making fun of him.
[15:53] <Nafallo> hunger_t: are you tracker? :-)
[15:54] <LaserJock> hunger_t: no Keybuk's tracker
[15:54] <hunger_t> Nafallo: Nope, but I must sound a bit like that here on the channel:-) Constantly asking about where stuff is stuck at any time.
[15:54] <Nafallo> hunger_t: better then to reinsex files hundreds of times anyway... ;-)
[15:55] <Nafallo> ehrm. reINDEX
[15:55] <Nafallo> damnit!
[15:56] <sladen> Keybuk: ha!
[16:01] <somerville32> wow.
[16:02] <Keybuk> jamiemcc: so, err
[16:02] <Keybuk> you must really hate coming on IRC
[16:02] <Keybuk> because you know somebody is going to have some awesome tracker bug they want to talk to you about ;)
[16:02] <Keybuk> like trackerd has indexed 200 more directories than actually exist on the filesystem, or something
[16:02] <jamiemcc> Keybuk: really?
[16:03] <jamiemcc> Keybuk: thats a know corruption problem that should now be fixed in svn
[16:03] <Keybuk> it seems to be indexing the same things over and over again
[16:03] <Keybuk> wing-commander scott% find -type d | wc -l
[16:03] <Keybuk> 17212
[16:03] <Keybuk> wing-commander scott% tracker-stats | grep Folders
[16:03] <Keybuk> Folders : 3671974
[16:04] <jamiemcc> Keybuk: we now check for corruption if trackerd was not shut down cleanly
[16:04] <jamiemcc> and force reindex if necessary
[16:04] <Keybuk> can I do that myself?
[16:05] <jamiemcc> dont think so - but you can reindex trackerd --reindex
[16:05] <jamiemcc> im planning a release with that fix on monday
[16:05] <Keybuk> should I wipe the cache first?
[16:05] <jamiemcc> --reindex does that
[16:06] <Keybuk> ok, I'll give that a go
[16:06] <jamiemcc> Keybuk: corruption occurs cause gnome-session does kill -9 trackerd while its indexing
[16:07] <Keybuk> jamiemcc: heh
[16:07] <Keybuk> RCU FTW
[16:13] <Keybuk> jamiemcc: I wonder whether it happened because I increased the inotify watch count so that it could actually index my entire home dir
[16:14] <jamiemcc> Keybuk: dont think so as we still crawl all directories at startup if they are not indexed
[16:14] <Keybuk> ah right
[16:51] <Keybuk> jamiemcc: so, err
[16:51] <Keybuk> tracker appears to have detected glibc and is bailing out a lot
[16:52] <jamiemcc> Keybuk: ?
[16:52] <Keybuk> *** glibc detected *** identify: free(): invalid pointer: 0xb761e000 ***
[16:52] <jamiemcc> eek
[16:52] <Keybuk> /usr/lib/libMagick.so.9(RelinquishMagickMemory+0x21)[0xb7d476b1]
[16:52] <Keybuk> /usr/lib/libMagick.so.9[0xb7da1e27]
[16:52] <Keybuk> /usr/lib/libMagick.so.9(DestroyImagePixels+0x69)[0xb7c7d859]
[16:52] <Keybuk> /usr/lib/libMagick.so.9(DestroyImage+0x80)[0xb7d2f050]
[16:52] <Keybuk> /usr/lib/libMagick.so.9(DestroyImageList+0x62)[0xb7d3fe02]
[16:52] <Keybuk> /usr/lib/libMagick.so.9(IdentifyImageCommand+0x451)[0xb7d2a0b1]
[16:52] <Keybuk> identify[0x8048ae9]
[16:52] <jamiemcc> oh thats tracker-extract - ignore it
[16:52] <Keybuk> ok
[16:52] <jamiemcc> it just means it could not extract metadata
[16:53] <jamiemcc> and imagemagick is quite buggy in that regard
[16:53] <Keybuk> yeah, it's /usr/bin/identify crashing
[16:53] <Keybuk> sorry for alarming you ;)
[17:34] <Cerberius> Hi everyone
[17:34] <somerville32> Hi
[17:34] <Cerberius> i need some help downloading torrents in ubuntu
[17:35] <Cerberius> i try with several client... azereus, bittorrent... and download never begin!!
[17:36] <Nafallo> Cerberius: #ubuntu is the correct channel, and you only need to click on them anyway.
[17:36] <Cerberius> thanks!
[19:16] <mwolson> could i get a sponsor for the main archive to prioritize uploading the security fix in Bug #159525 to hardy, gutsy-security, and feisty-backports?
[19:16] <ubotu> Bug 159525 on http://launchpad.net/bugs/159525 is private
[19:16] <mwolson> now that there is a known exploit, i am very eager to get my fix uploaded
[19:17] <mwolson> (i'm one of the maintainers of emacs22, the affected package)
[19:20] <LaserJock> mwolson: geeze, it's even private for me, not a lot people can do with a bug they can't see
[19:21] <mwolson> LaserJock: how do i fix that?  i don't recall doing anything special to make it private.
[19:21] <mwolson> ah found the option
[19:21] <LaserJock> mwolson: probably it's just the security team that has access
[19:21] <mwolson> ok, it's no longer private now
[19:22] <mwolson> that must have been the default value when i indicated that it was a security issue in the initial report
[19:25] <LaserJock> yes, when they are listed as a security they are made private
[19:25] <LaserJock> mwolson: you might want to see if keescook or pitti were around
[19:26] <mwolson> i was hoping that they would be hanging out here
[19:27] <LaserJock> well, it is the day after UDS
[19:28] <crimsun_> kees is pretty good about processing; just hang tight
[19:35] <crimsun_> mwolson: you could go ahead and modify the debdiff for a gutsy-security upload (using gutsy-security as the distro and 22.1-0ubuntu5.1 as the version)
[19:36] <mwolson> crimsun_: would it be OK to leave my other changes in the gutsy-security upload (i've verified them to be correct, and they only affect debian/rules), or should i just use the minimal set of changes for -0ubuntu5.1?
[19:38] <geser> LaserJock: does pitti still does security uploads?
[19:38] <LaserJock> geser: have no idea but he can do anything ;-)
[19:38] <geser> LP lists only keescook jdstrand and infinity as ~ubuntu-security members
[19:39] <crimsun_> mwolson: the current one is sufficient [with above changes]
[19:39] <LaserJock> all you need is an archive admin
[19:41] <mwolson> alright, i'll post an additional debdiff for -0ubuntu5.1.
[19:41] <crimsun_> I can go ahead and push 0ubuntu6 for hardy after you post it so there's no problem with versioning
[19:53] <mwolson> i've attached the gutsy-security debdiff
[19:55] <crimsun_> (pulling src)
[19:56] <mwolson> heh, looks like lintian doesn't like "hardy" as a distribution name
[19:57] <mwolson> also attached a debdiff for hardy
[19:58] <mwolson> let me know what you want the package version number for feisty-backports to be
[20:01] <crimsun_> 22.1-0ubuntu4~feisty2 would be fine
[20:07] <crimsun_> uploaded to hardy.
[20:07] <mwolson> excellent, thanks!
[20:08] <mwolson> attached the debdiff for feisty-backports
[20:08] <crimsun_> I've opened a gutsy task, too
[20:09] <mwolson> (hmm ... though perhaps i should have added back the "Automated backport upload; no source changes." line before generating the feisty-backports debdiff -- let me know if that matters)
[20:10] <crimsun_> not really an issue; core-dev can upload to foo-backports
[20:16] <crimsun_> mwolson: for gutsy-security, it's best to include the CVE # in the changelog
[20:17] <mwolson> ah.  need me to re-make the debdiff, or is it already on its way?
[20:17] <crimsun_> for gutsy-security, rerolling is best
[20:23] <mwolson> i've attached a new debdiff for gutsy-security that adds the CVE #
[20:26] <crimsun_> uploaded to feisty-backports; pending accept.
[20:41] <warp10> Hi all
[20:41] <somerville32> Hi
[22:33] <mdke_> Riddell: still getting emails for failed builds to the kubuntu-members ppa. Any solution for that? could a different ppa be used perhaps?
[23:17] <Keybuk> I need to learn to stop being surprised when something works on Linux
[23:17] <somerville32> lol
[23:18] <Fujitsu> Keybuk: What works?
[23:20] <Keybuk> Network Manager offers my USB-connected phone as a possible network device to use
[23:20] <Fujitsu> Ah, nice.
[23:20] <StevenK> Keybuk: And it would probably be faster than the hotel network
[23:21] <Keybuk> and somewhat more expensive ;)
[23:21] <Keybuk> though it can only see GSM and GPRS from here
[23:21] <Keybuk> no 3G
[23:21] <Fujitsu> Keybuk: For very large values of somewhat?
[23:22] <Keybuk> indeed
[23:24] <jdong> stupid rain, I don't wanna go out to get food....
[23:26] <somerville32> I'm hungry too :(
[23:27]  * jdong grabs a flashlight and waterproof coat and preps himself
[23:27] <somerville32> Send some my way, will you? We have a tropical storm ATM