[00:09] <chrisccoulson> seb128 - thanks
[07:00] <pitti> Good morning
=== MacSlow is now known as MacSlow|afk
[07:30] <RAOF> Morning, pitti.
[07:30] <pitti> hey RAOF, how are you?
[07:31] <RAOF> Fine.  The smell of bolognese is making me hungry!
[07:31] <pitti> RAOF: did you get along with the bug mail filtering stuff?
[07:31] <pitti> yummy!
[07:32] <RAOF> Yup.  I've reconfigured some of my evolution filters; I think the “filter out things of importance, dump the rest in appropriate buckets” method will scale better than the “bump in appropriate buckets” I used earlier.
[07:36] <pitti> RAOF: well, both sound like valid implementations, as long as you can make sure to be able to respond to urgent bug mail without getting drowned in the flood of incoming bugs :)
[07:37] <pitti> RAOF: ok, thanks for setting that up
[07:42] <RAOF> Yeah.  I'm going to get a lot more bugs than I'm used to, what with X and a bunch of destkop stuff :)
[07:42] <RAOF> Mmm, dinner!
[08:11] <pitti> bryceh: wrt. https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-lucid-release-collaboration-with-debian, the "X" work item is still open
[08:12] <pitti> bryceh: I guess we are pretty much settled for our X version in lucid? I guess this meant to be in sync with Debian as much as possible?
[08:15] <sabdfl> as i understand it, we're driving X in both cases?
[08:15] <pitti> most of the client side just comes from Debian
[08:15] <pitti> for the server we have a pretty good collaboration between bryceh and tjaalton and the Debian guys, AFAICS
[08:16] <pitti> I'm off for a doctor appointment, back in an hour
[08:18] <tjaalton> pitti: there's one stable release update (1.7.6) coming up, debian now has the rc2 version of it. the final should be released later this week most likely
[08:19] <tjaalton> also, mesa 7.7.1 will be released within two weeks, we have a snapshot of the stable branch (like debian)
=== sabdfl1 is now known as sabdfl
[08:22] <tjaalton> pitti: but yes, we share most of it
=== MacSlow|afk is now known as MacSlow
[08:47] <bryceh> pitti, oh I'd filled in that info the other day but didn't mark the task done
[08:47] <bryceh> pitti, look at the blueprint, the X versions are shown there
[08:52] <seb128> hey there
[09:08] <pitti> re
[09:08] <pitti> bonjour seb128
[09:08] <seb128> hey pitti
[09:09] <pitti> bryceh, tjaalton: thanks! so it seems we can flip that one to DONE?
[09:09] <seb128> pitti, how are you?
[09:09] <pitti> I'm great, thanks! just back from doctor
[09:11] <bryceh> pitti, I set it to done, but I didn't actually verify the versions with debian.  But we've been tracking pretty close and I doubt they're going to suddenly do something exotic
[09:11] <seb128> pitti, hayfever again?
[09:11] <pitti> seb128: yes, it's a series of 10 treatments, twice a week
[09:11] <pitti> bryceh: *nod*, thanks
[09:11] <bryceh> pitti, I saw you set me as the assignee for the whole multitouch blueprint!
[09:12] <bryceh> pitti, I suspect it should be duncan since he's project manager
[09:12] <pitti> bryceh: oh, please feel free to assign it to someone else if  appropriate; I thought you and Rick said you were going to work on it?
[09:12] <pitti> bryceh: fine for me; so he'll own the items by default, and you pick out some?
[09:12] <bryceh> pitti, yes I am but just a portion; most of those tasks on the blueprint are going to be done by other folk
[09:13] <bryceh> yep
[09:13] <pitti> bryceh: I'm greatly relieved!
[09:13] <bryceh> yeah I'm just going to play the role of hired gun on this one
[09:13] <pitti> bryceh: what's his LP id?
[09:13] <bryceh> probably mostly just packaging/testing but we'll see
[09:13] <pitti> there are quite a lot of duncans
[09:14] <bryceh> oubiwann
[09:14] <seb128> RAOF, hi
[09:14] <pitti> ah, right
[09:14] <seb128> RAOF, bug #175191
[09:14] <ubottu> Launchpad bug 175191 in f-spot "f-spot changes timestamp in an incorrect way" [Unknown,Confirmed] https://launchpad.net/bugs/175191
[09:14] <bryceh> == Duncan McGreggor
[09:14] <pitti> bryceh: ah, I searched for "McGregor"
[09:14] <pitti> changed
[09:14] <bryceh> pitti, btw this evening I made a new graph
[09:15] <bryceh> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid.svg
[09:15] <bryceh> that is a (much saner) chart showing just X bugs tagged 'lucid'
[09:15] <seb128> RAOF, bug #175191, do you think it's something you can work on for lucid?
[09:15] <ubottu> Launchpad bug 175191 in f-spot "f-spot changes timestamp in an incorrect way" [Unknown,Confirmed] https://launchpad.net/bugs/175191
[09:15] <bryceh> so that limits it to just bugs we know are relevant on lucid.  Still a lot of bugs but looks more doable
[09:16] <pitti> bryceh: urgh, half of it are -intel..
[09:17] <bryceh> pitti, and half of those are bugs collected by the apport freeze hook
[09:17] <pitti> bryceh: oh, btw, my after-resume corruption finally seems to be fixed \o/ (I'm running 2.6.33 for testing)
[09:17] <bryceh> great
[09:17] <pitti> I guess it should also work with our lucid kernel now, with the backported drm; I'll test that again
[09:17] <bryceh> yes it should
[09:17] <mvo> pitti: I noticed that you changed module-init-tools at some point, did it build with bzr-buildpackage for you? or did you just plain-old apt-get source when you did it?
[09:17] <pitti> now X crashes sometimes after suspend, but at least it works perfectly if it doesn't crash
[09:18] <pitti> Vcs-Bzr: http://bazaar.launchpad.net/~ubuntu-core-dev/module-init-tools/ubuntu
[09:18] <pitti> mvo: ^
[09:18] <pitti> mvo: but I don't remember whether I used bzr bd
[09:18] <mvo> right, I use that
[09:18] <mvo> but bzr-buildpackage is not happy, not in default nor --split mode
[09:19] <mvo> I was just wondering if I overlook something obvious, otherwise I will just bug keybuk when he is around
[09:39] <RAOF> seb128: Yeah, I've been investigating it.  As I said on the bug, I think simply not writing the timestamp out to the primary file will solve the most obnoxious problem.
[09:40] <seb128> RAOF, seems an easy enough change, can you work on it?
[09:40] <RAOF> Yup.  I've done it locally.
[09:40] <RAOF> That, plus a number of miscelaneous other fixes should be ready for once the archive unfreezes.
[09:45] <seb128> RAOF, if you think you are done with those changes feel free to add the debdiff on launchpad
[09:45] <seb128> we can queue uploads so they will go in after unfreeze
[09:45] <seb128> that's better than having to run around at the end of the week to see what was waiting
[09:46] <RAOF> I actually have upload privs to f-spot now, via the new pkg-mono team.  So, uploads made now are queued and pushed through after the freeze.
[09:46] <RAOF> ?
[09:48] <seb128> RAOF, yes
[09:48] <seb128> RAOF, upload away things just get queued
[09:48] <seb128> and everything will be flushed after freeze
[09:49] <RAOF> Cool.  Once I've finished polishing I'll upload.
[09:49] <seb128> thanks
[09:54] <seb128> re
[09:55] <cassidy> kenvandine, you shouldn't enable the favorite feature, it requiers telepathy-logger which is not packaged yet
[09:56] <seb128> cassidy, oh btw what is the rational to display offline contacts by default?
[09:56] <cassidy> seb128, Cannonical's usability testing :)
[09:57] <cassidy> users didn't find the option to display offline contacts and was expecting to have their full contact list
[09:57] <seb128> oh, interesting
[09:57] <seb128> see user testing is useful
[09:57] <RAOF> I can see how that would work, yeah.  Yay data!
[09:57] <seb128> I would never have though that's something user want :p
[09:58] <cassidy> and we assumed it's easier for user to think "How can I disable that?" than "Humm maybe there is an option to display online contacts"
[09:58] <RAOF> Any idea what the median number of contacts people have was?  That'd be a critical piece of info, I'd think.
[10:08] <seb128> hey chrisccoulson
[10:08] <chrisccoulson> hey seb128, how are you?
[10:08] <seb128> good!
[10:08] <seb128> you?
[10:08] <chrisccoulson> yeah, i'm good thanks, but quite tired
[10:08] <pitti> hey chrisccoulson, how are you
[10:09] <seb128> had a late night again?
[10:09] <chrisccoulson> i'm just doing some mass bug reporting now i can use apport again ;)
[10:09] <chrisccoulson> hey pitti, yeah, i'm ok thanks
[10:09] <chrisccoulson> seb128 - yeah, it was quite a late night last night, and i didn't rest much yesterday
[10:11] <seb128> chrisccoulson, :-(
[10:11] <seb128> chrisccoulson, you should call it a day early today, especially with the freeze there is no hurry to get changes
[10:12] <seb128> chrisccoulson, bug #412440, do you know if there was any design recommendation about what to do for this one?
[10:12] <ubottu> Launchpad bug 412440 in gnome-disk-utility "gnome-disk-utility doesn't use new notifications" [Low,Confirmed] https://launchpad.net/bugs/412440
[10:12] <chrisccoulson> yeah, i might do, although I got up quite late this morning already ;)
[10:12] <seb128> do you think we should just drop the action there?
[10:12] <chrisccoulson> i'm not sure if anyone decided what we should do with that bug
[10:13] <chrisccoulson> we could drop the action for now, but i think there was a suggestion to use a more helpful dialog with a link to the manufacturers website
[10:13] <seb128> do we have those informations?
[10:13] <seb128> the manufacturer website
[10:13] <seb128> that seems a non trivial change with UI changes
[10:14] <seb128> I'm wondering if we should stop running the gdu things with the session in lucid
[10:16] <chrisccoulson> we could do, but i think the gdu-notifier process also displays the slow unmount dialog too
[10:16] <chrisccoulson> (the one which pops up when you unmount something in nautilus)
[10:17] <seb128> pitti, ^
[10:17] <seb128> any opinion on that?
[10:18] <seb128> in any case if we can't fix bug #438136 we should turn that notification off
[10:18] <ubottu> Launchpad bug 438136 in libatasmart "palimpsest bad sectors false positive" [Unknown,Confirmed] https://launchpad.net/bugs/438136
[10:18] <seb128> we are freaking users about broken disks where disks are not broken
[10:18] <pitti> seb128: what do you mean with "new notifications"?
[10:19] <pitti> seb128: gdu shows the "low disk space" ones, the "please wait with removing USB device", "your RAID is broken", etc.
[10:19] <pitti> I think it's quite important to have
[10:19] <seb128> pitti, gdu is using actions right now
[10:19] <pitti> (also, "your hard drive is failing")
[10:19] <seb128> so we get those gtk fallback dialogs
[10:19] <seb128> instead of notification bubbles
[10:19] <pitti> weird, I see proper dialogs
[10:19] <chrisccoulson> pitti - gsd shows the low disk space warning doesnt it?
[10:19] <pitti> they even have a checkbox
[10:19] <pitti> chrisccoulson: yes
[10:19] <chrisccoulson> (unless we have 2 of those now)
[10:19] <seb128> pitti, for failing disks?
[10:19] <pitti> seb128: ah, so failing disks are notifications?
[10:20] <seb128> pitti, see bug #412440
[10:20] <ubottu> Launchpad bug 412440 in gnome-disk-utility "gnome-disk-utility doesn't use new notifications" [Low,Confirmed] https://launchpad.net/bugs/412440
[10:20] <pitti> I'm fine with disabling actions for them
[10:20] <seb128> comment #1 has a screenshot
[10:20] <seb128> ok, that was minor point
[10:20] <seb128> but since we have dx contractors to work on those sort of issues
[10:20] <pitti> ah, yes, those actions should be fixed
[10:20] <seb128> I will assign that to one of them
[10:20] <chrisccoulson> i think that disabling actions is a good compromise at the moment, but we could probably think of something better for next cycle
[10:21] <chrisccoulson> seb128 - i notice that someone is working on the gnome-screensaver "leave message" change now
[10:21] <chrisccoulson> is that something we expect for lucid?
[10:21] <seb128> pitti, the one which really annoys me is the libatasmart one
[10:22] <seb128> chrisccoulson, I would consider it low priority, mpt pointed it as something nice to fix so I added to jpetersen tasks as lowest priority if he runs out of assigned tasks
[10:22] <seb128> chrisccoulson, he's one of the dx contractors
[10:22] <seb128> pitti, can you make sure the libatasmart issue is on the lucid radar?
[10:23] <seb128> pitti, or can we talk about disabling failing disk warnings if it's not fixed for lucid
[10:23] <seb128> pitti, telling people to change their disk when it's not broken is an issue
[10:23] <pitti> seb128: yes, we can disable the notifications as a last resort thing
[10:23] <pitti> I'll talk to it with mezcalero
[10:23] <seb128> thanks
[10:23] <seb128> the box my parents are using has the issue
[10:24] <seb128> quite annoying to explain them to ignore the dialog opening at every boot saying their disk is broken
[10:24] <seb128> "don't worry it's not broken, it's just a bug" ;-)
[10:24] <pitti> what does it say?
[10:24] <seb128> cf screenshot you just looked at before
[10:25] <seb128> "hard disk failing"
[10:25] <pitti> seb128: I mean, what does palimpsest say about the details/
[10:25] <pitti> ?
[10:25] <pitti> I guess there are a few bad sectors, but not enough of them to start worrying?
[10:25] <chrisccoulson> seb128 - i wouldn't mind being involved with any review of gnome-screensaver changes
[10:25] <seb128> chrisccoulson, ok, noted, thanks
[10:26] <chrisccoulson> thanks
[10:26] <seb128> chrisccoulson, I will ping you if he comes with a patch for it
[10:26] <seb128> pitti, well, we had a look a few months back, all the win tools we found list 0 issues
[10:26] <seb128> no bad sectors
[10:26] <seb128> I'm pretty sure it's a bug in gdu or the libatasmart issue
[10:26] <mvo> out of curisotiry, how does redhat/fedora do global keyboard settings? is there a system-config-keyboard or somesuch?
[10:27] <seb128> mvo, no idea, ask mclasen when he's around
[10:27] <pitti> seb128: sudo skdump /dev/sda might be interesting
[10:27] <pitti> seb128: did you file a bug for it? these days apport includes a smart blob dump
[10:27] <chrisccoulson> the kernel team will love me by the end of the day
[10:27] <pitti> which upstream needs
[10:27] <pitti> chrisccoulson: why, filed 5 bugs? :-)
[10:27] <chrisccoulson> pitti - i think i might be able to report 5 ;)
[10:28] <seb128> pitti, no, but I can do that in half an hour if you want, against which package should I file it?
[10:28] <pitti> seb128: libatasmart
[10:29] <pitti> seb128: then I have a bug as a reminder, and good data; thanks
[10:29] <seb128> pitti, np
[10:29] <seb128> pitti, bug #438136 is not good enough?
[10:29] <ubottu> Launchpad bug 438136 in libatasmart "palimpsest bad sectors false positive" [Unknown,Confirmed] https://launchpad.net/bugs/438136
[10:29] <seb128> pitti, it has over an hundred comments, responsive submitter and upstream bug reports
[10:30] <pitti> seb128: if that's what you are seeing, sure
[10:30] <seb128> pitti, anyway will file mine anyway you can dupif required
[10:30] <pitti> seb128: it has a million screenshots, but not a blob dump
[10:30] <seb128> right
[10:31] <pitti> these were reported in karmic mostly, where we didn't have the improved apport hook yet
[10:31]  * pitti assigns the bug to himself for now, though
[10:33] <seb128> bug #454301 is weird
[10:33] <ubottu> Launchpad bug 454301 in gnome-disk-utility "warning given about disk health due to smart not being enabled" [Low,Incomplete] https://launchpad.net/bugs/454301
[10:37] <RAOF> I haven't missed the team meeting reminder email, have I?
[10:38] <chrisccoulson> RAOF, i haven't seen a reminder yet
[10:39] <RAOF> Ok.  Well, I'll be up relatively early in the morning anyway.  Good night!
[10:40] <chrisccoulson> good night RAOF!
[10:41] <seb128> 'night RAOF
[11:19] <seb128> pitti, btw my .xsession-errors has this warning listed
[11:19] <seb128> " system-config-printer-applet: failed to start PrinterDriversInstaller service: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.105" is not allowed to own the service "com.redhat.PrinterDriversInstaller" due to security policies in the configuration file"
[11:19] <seb128> do you know if that's a known issue?
[11:20] <pitti> hm, I don't
[11:20] <seb128> pitti, bug #530218
[11:20] <ubottu> Launchpad bug 530218 in system-config-printer "PrinterDriversInstaller service: AccessDenied error" [Undecided,New] https://launchpad.net/bugs/530218
[11:20] <seb128> pitti, should I milestone and assign to Till?
[11:20] <pitti> seb128: can you please assign it to Till?
[11:20] <pitti> yes, please :)
[11:20] <seb128> doing that, thanks
[11:34] <seb128> pedro_, hey
[11:35] <pitti> I'm off IRC for some hour for test-reinstalling my main laptop
[11:35] <seb128> pedro_, can you test if gedit remember the cursor position in a document for you?
[11:35] <seb128> ie open a text, move cursor, close and reopen gedit and see if it set the cursor where it was
[11:35] <seb128> pitti, have fun
[11:35]  * seb128 lunch
[11:35] <pedro_> seb128, yeap one sec
[11:35] <seb128> pedro_, if it's broken for you can you open a bug on bugzilla? pbor said he would look at it
[11:36] <seb128> pedro_, no hurry I'm just going for lunch
[11:36] <seb128> bbl
[11:36] <seb128> pedro_, thanks
[11:36] <pedro_> seb128, enjoy!
[11:36] <seb128> thanks
=== MacSlow is now known as MacSlow|lunch
[11:59] <pedro_> seb128, fyi https://bugzilla.gnome.org/show_bug.cgi?id=613032
[11:59] <ubottu> Gnome bug 613032 in general "Cursor position is not remembered" [Normal,Unconfirmed]
[11:59] <seb128> pedro_, thanks!
[11:59] <pedro_> my pleasure ;-)
[12:00] <nigelb> thoughts on this fix? worth getting into lucid? bug 529744
[12:00] <ubottu> Launchpad bug 529744 in gnome-system-tools "When creating a new user, "Shortname" should really be "Username" ." [Low,Triaged] https://launchpad.net/bugs/529744
[12:02] <chrisccoulson> nigelb, i don't think that justifies a UI freeze exception really
[12:03] <nigelb> my thoughts too, I just wanted the desktop team's take on it
[12:04] <nigelb> chrisccoulson: can you unsubscribe sponsors and mention that there?
[12:14] <kenvandine> cassidy, cool, thx!
[12:34] <seb128> kenvandine, hey
=== KenEdwards is now known as KenEdwards-afk
[12:45] <davmor2> anyone working on une?
[12:45] <kenvandine> hey seb128
[12:46] <seb128> kenvandine, how are you?
[12:46] <kenvandine> good, and you?
[12:46] <seb128> good, thanks!
[12:47] <seb128> kenvandine, was there anything decided about how to handle empathy calls requests?
[12:47] <chrisccoulson> hmmm, is wiki.ubuntu.com working for anyone?
[12:47] <seb128> kenvandine, I know that we discussed that having those in the indicator was not obvious enough
[12:47] <kenvandine> just forcing raising the incoming call window
[12:47] <seb128> kenvandine, do you plan to work on that? or should I add it to the contractors list?
[12:48] <kenvandine> seb128, i want it to just raise that incoming call dialog instead of a notification
[12:48] <seb128> chrisccoulson, seems not, or it's really slow
[12:48] <kenvandine> seb128, was going to do that next cycle
[12:48] <chrisccoulson> seb128 - ah, so it's not just me then
[12:48] <chrisccoulson> i hope it hasn't discarded my work ;)
[12:48] <seb128> kenvandine, "next cycle" = lucid+1?
[12:49] <seb128> chrisccoulson, oh, you mean it's because of you? ;-) doing too many changes there and loading the wiki with those? ;-)
[12:49] <kenvandine> seb128,  i would love to do it now
[12:49] <kenvandine> seb128, could we squeeze that in?
[12:49] <seb128> kenvandine, ok, so you want to take over the bug or should I assign it to a contractor?
[12:49] <chrisccoulson> seb128 - yeah, i keep updating the wiki at the moment ;)
[12:49] <kenvandine> i think i have the time
[12:49] <seb128> kenvandine, not for beta1 but after beta1 one
[12:49] <seb128> one -> yes
[12:50] <kenvandine> awesome
[12:50] <kenvandine> i'll do it
[12:50] <seb128> kenvandine, thanks
[12:50] <kenvandine> got the bug # handy?
[12:50] <kenvandine> cassidy, what is the best way to know an event is an incoming call?
[12:50] <seb128> kenvandine, bug #440865
[12:50] <ubottu> Launchpad bug 440865 in empathy "Visual notification for/correct user response to incoming voice calls and subscription requests not obvious" [Low,Triaged] https://launchpad.net/bugs/440865
[12:51] <cassidy> kenvandine, an EmpathyEvent ?
[12:51] <kenvandine> yeah
[12:51] <kenvandine> same for subscription request
[12:51] <kenvandine> although i don't think that should be a dialog, so should run that by mpt
[12:51] <cassidy> check the type attribute of the evnet
[12:52] <cassidy>     EmpathyEventType type;
[12:53] <kenvandine> cassidy, great
[12:53] <kenvandine> thx
[12:53] <chrisccoulson> grrrr, it lost my changes
[12:53] <seb128> chrisccoulson, if you try to edit again it might take the draft back
[12:54] <seb128> it does it there usually
[12:54] <seb128> or ask at least if you want to use that one
[12:54] <chrisccoulson> hmmm, it's not doing that here :-/
[12:54] <seb128> :-(
[12:54] <seb128> you should take the pitti way
[12:54] <chrisccoulson> oh, hand on
[12:55] <chrisccoulson> "Load draft"
[12:55] <chrisccoulson> that brings back most of the changes ;)
[12:55] <chrisccoulson> that's ok then :)
[12:55] <seb128> use the editmoin to do edition locally in your favorite editor
[12:55] <chrisccoulson> yeah, i might try that
[12:55] <chrisccoulson> sometimes editing it online is so slow ;)
=== MacSlow|lunch is now known as MacSlow
=== KenEdwards-afk is now known as KenEdwards
[13:12] <baptistemm> Hi there
[13:12] <baptistemm> pitti, is bug 529554 in your radar ?
[13:12] <ubottu> Launchpad bug 529554 in apport "[8.04 -> 10.04 a3] Configuration prompt request" [Undecided,Confirmed] https://launchpad.net/bugs/529554
[13:20] <chrisccoulson> seb128 - do you think bug 390816 is worth fixing for lucid?
[13:20] <ubottu> Launchpad bug 390816 in gnome-power-manager "external monitor output is switched off when closing the laptop-lid when gnome-power-manager is set to blank screen on closing" [Medium,Triaged] https://launchpad.net/bugs/390816
[13:21] <seb128> yes!
[13:21] <chrisccoulson> would you mind adding a lucid task for that one then?
[13:21] <chrisccoulson> :)
[13:21] <seb128> will do
[13:21] <chrisccoulson> thanks
[13:21] <seb128> I also need to check if I still get g-s-d crashing when suspending docked and waking up undocked
[13:22] <seb128> btw do you have any idea what source would be to blame for "no screen active" in such cases?
[13:22] <seb128> I need to enter my password without screen
[13:22] <seb128> and do fn-f7
[13:22] <seb128> that's quite annoying too
[13:22] <chrisccoulson> i'm not too sure about that one
[13:22] <chrisccoulson> that's probably another g-s-d issue ;)
[13:22] <seb128> I'm not sure if that's not xorg itsefl
[13:23] <seb128> it should make sure at least one output is active
[13:23] <seb128> tjaalton, bryceh: ^
[13:23] <seb128> opinions?
[13:24] <seb128> typical scenario is "use a laptop docked with lid closed, only the external screen is active, suspend, take the laptop, open it somewhere"
[13:24] <seb128> which leads to "no screen active"
[13:25] <chrisccoulson> seb128 - that could be a xorg issue if g-s-d got no signal that the display configuration changed
[13:25] <chrisccoulson> it should respond when the display configuration changes, and configure them appropriately
[13:26] <chrisccoulson> this is where xtrace helps :)
[13:26] <seb128> hehe
[13:26] <seb128> you recommend running g-s-d under xtrace?
[13:26] <seb128> I never used xtrace, I need to look at it
[13:27] <chrisccoulson> it's probably a quick test, just to see if you get a RRScreenChangeNotify event when you resume the machine
[13:27] <chrisccoulson> if not, then g-s-d has no way of knowing that the display configuration changed
[13:29] <seb128> how do I know about this? using xtrace?
[13:29] <tjaalton> seb128: I'd say the driver
[13:30] <seb128> tjaalton, ok, I'm on intel965
[13:30] <seb128> tjaalton, do you know if that's a known issue for those?
[13:30] <tjaalton> seb128: dunno, I could try with mine :)
[13:30] <seb128> tjaalton, would be nice ;-)
[13:35] <seb128> tseliot, do you think you could have a look to bug #432814?
[13:35] <ubottu> Launchpad bug 432814 in xserver-xorg-input-synaptics "Action for middle and right click is reversed since jaunty" [Undecided,Invalid] https://launchpad.net/bugs/432814
[13:35] <seb128> tseliot, just to see if there is really an issue there or something we should look at changing
[13:35] <tseliot> seb128: sure
[13:35] <seb128> tseliot, it seems it annoy some users but I'm not sure to understand our options and if changing the config the way suggested would break other usecases
[13:36] <tseliot> seb128: I think we can only choose which users we want to annoy ;)
[13:38] <seb128> tseliot, ok, maybe you could drop a quick comment on the bug saying that?
[13:38] <tjaalton> seb128: how do you keep the external alive with lid closed?
[13:39] <seb128> tjaalton, I boot docked and it just do it
[13:39] <tjaalton> seb128: ah ok
[13:39] <seb128> tjaalton, otherwise plug the screen and use the capplet to activate external and desactive the laptop
[13:40] <seb128> or use fn-f7 to do that
[13:40] <seb128> and close the lid
[13:40] <seb128> with something else than suspend on lid close ;-)
[13:40] <tseliot> seb128: the attached patch is not such a bad idea and I think mpt approved something like that for karmic (but I didn't have the time to review it)
[13:41] <seb128> tseliot, can you maybe assign the bug to yourself then, it's low priority milestoned for lucid
[13:41] <seb128> tseliot, so it stays on your target of opportunity list
[13:41] <seb128> ?
[13:42] <tseliot> seb128: yes, sure. BTW is there also a bug report about the disable touchpad thing?
[13:42] <seb128> tseliot, bug #479878
[13:42] <ubottu> Launchpad bug 479878 in gnome-settings-daemon "Need an option to disable touchpad completely" [Wishlist,New] https://launchpad.net/bugs/479878
[13:44] <tseliot> seb128: ok, good
[13:44] <seb128> tseliot, thanks
[13:44] <seb128> slomo, hey
[13:45] <slomo> hi seb128
[13:47] <seb128> chrisccoulson, bug #509478, do you still want to work on it for lucid or should I move it to the team list rather?
[13:47] <ubottu> Launchpad bug 509478 in gnome-settings-daemon "gnome-settings-daemon crashed with signal 5 in xkl_process_error()" [High,Triaged] https://launchpad.net/bugs/509478
[13:48] <seb128> chrisccoulson, realistically you have lot of things to do already so you might want to try to give some bugs back to the team and claim those again later if time allows rather than overworking you for those
[13:51] <tjaalton> seb128: well, I can't undock it while it's asleep
[13:51] <seb128> tjaalton, why not?
[13:51] <pitti> baptistemm: I bet it's the 2305324th duplicate of the update-manager bug, but I'll check
[13:51] <tjaalton> there's a button for the undock, and pressing it wakes the machine up
[13:51] <seb128> tjaalton, just undock without telling the dock :p
[13:51] <tjaalton> seb128: it'll start whining loudly :)
[13:53] <tjaalton> actually no, it wakes up
[13:53] <seb128> tjaalton, well that's good in any case
[13:53] <seb128> open the lid and see if you have a screen on :p
[13:53] <mvo> pitti: what bug?
[13:53] <pitti> mvo: bug 51804
[13:53] <ubottu> Launchpad bug 51804 in launchpad-registry ""Change Maintainer" link on product overview page is misnamed (dup-of: 202135)" [Low,Triaged] https://launchpad.net/bugs/51804
[13:53] <ubottu> Launchpad bug 202135 in launchpad-registry "Change project maintainer page also uses owner and registrant" [Medium,Fix released] https://launchpad.net/bugs/202135
[13:54] <tjaalton> seb128: well it isn't
[13:54] <pitti> mvo: argh, sorry; bug 518043
[13:54] <ubottu> Launchpad bug 518043 in update-manager "Modifies /etc/default/apport during upgrade, causing conffile prompt" [High,Triaged] https://launchpad.net/bugs/518043
[13:54] <tjaalton> seb128: so something is not waking it up, a vt-change does though
[13:54] <tjaalton> seb128: could be g-s-d after all
[13:55] <tjaalton> or is it g-p-m
[13:55] <seb128> tjaalton, "not waking it"? waking who there?
[13:55] <seb128> tjaalton, shouldn't xorg activate the screen on resume?
[13:55] <chrisccoulson> seb128 - i still intend to look at that bug
[13:56] <chrisccoulson> it's fairly reproducible here as well :)
[13:56] <tjaalton> seb128: I'm not sure how it goes
[13:56] <tjaalton> or should go
[13:58] <seb128> tjaalton, I will try checking with federico
[13:58] <seb128> I guess he should know, he works on a lot around those sort of scenarios
[13:59] <tjaalton> yep
[13:59] <tjaalton> thanks
[13:59] <seb128> thank you
[14:20] <chrisccoulson> we're still having a team meeting this afternoon aren't we?
[14:21] <kenvandine> chrisccoulson, afaik
[14:21] <chrisccoulson> i haven't seen a reminder, and there's nothing at https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-03-16
[14:24] <seb128> chrisccoulson, yeah, I guess rickspencer3 has been busy, reminders come late sometime
[14:24] <rickspencer3> d'oh
[14:25] <seb128> hey rickspencer3
[14:25] <rickspencer3> chrisccoulson, I just forget a lot
[14:25] <rickspencer3> hi seb128
[14:25]  * rickspencer3 goes to remind
[14:25] <rickspencer3> thanks chrisccoulson
[14:25] <chrisccoulson> hi rickspencer3, no worries :)
[14:25] <pitti> hey rickspencer3
[14:25] <rickspencer3> stupid daylight savings
[14:25] <rickspencer3> it's says 7:25am, but I am sooo tired
[14:26] <seb128> I would be tired too if I was waking up at 6am
[14:26] <chrisccoulson> rickspencer3, yeah, i hate DST too. i prefer it when the clocks go back in the other direction ;)
[14:28] <pitti> I created the wiki page now
[14:28] <pitti> https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-03-16
[14:28] <rickspencer3> pitti, so did I
[14:28] <pitti> oops
[14:28] <kenvandine> james_w, ping
[14:28] <rickspencer3> pitti, it worked!
[14:28] <pitti> I didn't exist yet 2 minutes ago
[14:28] <pitti> rickspencer3: did I overwrite any contents of your's?
[14:29] <rickspencer3> pitti, I know, when I created it, it didn't throw an error or blow away your changes
[14:29] <rickspencer3> nice
[14:29] <rickspencer3> pitti, nope, it worked in quite a pleasant manner
[14:29] <rickspencer3> so team meeting is in 2 hours, right?
[14:29] <seb128> dpm, hi
[14:30] <james_w> hi kenvandine
[14:30] <seb128> dpm, the indicator-session translation issue, it's likely due to ted's merge from oem translation upstream
[14:30] <kenvandine> james_w, how should we handle things like this
[14:30] <kenvandine> https://code.edge.launchpad.net/~facundo/ubuntu/lucid/pyinotify/fix-path-overlap/+merge/21266
[14:30] <seb128> rickspencer3, yes
[14:30] <rickspencer3> thanks seb128
[14:30] <kenvandine> should we merge right into lp:ubuntu/pyinotify and upload?
[14:31] <james_w> kenvandine: yep, bzr merge; bzr commit; bzr bd -S; bzr mark-uploaded; bzr push lp:ubuntu/pyinotify; dput
[14:31] <kenvandine> ok... only problem is i won't have commit access or upload perms for that package :)
[14:31] <dpm> hey seb128, oh I see... I didn't know there where upstream OEM translations for indicator-session. I knew there might be from other projects, but not for i-s. I'll talk to him, then. Thanks for the heads up
[14:32] <seb128> dpm, np
[14:32] <kenvandine> so i'll need to get a sponsor, but good to know
[14:32] <kenvandine> james_w, thx
[14:32] <james_w> kenvandine: oh, in that case, I can do it
[14:32] <kenvandine> thx :)
[14:32] <seb128> dpm, tedg: any reason why indicator-session upstream translations are not open in launchpad?
[14:33] <seb128> dpm, tedg: or any reason to not merge translations back from ubuntu if those are considered upstream ones?
[14:33] <james_w> kenvandine: the only thing I was unsure of was whether this should be uploaded today or Friday?
[14:33] <kenvandine> friday
[14:33] <kenvandine> beta2
[14:33] <tedg> seb128: Because the only way to merge them back currently is with a tarball dump, which really isn't a "merge"
[14:33] <james_w> kenvandine: ok, I'll go back to ignoring it :-)
[14:33] <seb128> kenvandine, can you review bug #405284?
[14:34] <ubottu> Launchpad bug 405284 in empathy "improve empathy notifications support with notify-osd" [Wishlist,New] https://launchpad.net/bugs/405284
[14:34] <kenvandine> seb128, sure
[14:34] <seb128> kenvandine, or rather the patch there
[14:34] <seb128> kenvandine, it's not trivial and probably not good to use but since the submitter went through the work of posting it etc would be nice to comment
[14:34] <seb128> tedg, how did you "merge" from oem?
[14:35] <dpm> seb128, tedg, I think it's fine if the upstream project is not open for translations for now, so we only have a source for translation, but if we are to merge them, translations from Ubuntu translators should be given precedence . This can be done e.g with msgmerge
[14:35] <tedg> I'm hoping that KyleN and dpm are going to come up with a stellar plan. :)
[14:35] <kenvandine> james_w, i'll assign the package bug to you then
[14:35] <seb128> james_w, kenvandine: just upload your fixes, don't wait for friday, those will be queued
[14:35] <tedg> seb128: We didn't have any upstream translations previously, so there was no merge.
[14:35] <kenvandine> james_w, are you the "ubuntu-branches" team?
[14:35] <dpm> tedg, we've started (well kyleN has) some documentation for this. merges can be done with the gettext tools
[14:35] <seb128> tedg, well you added the oem ones, you could have done the same with the ubuntu ones from an export tarball
[14:36] <tedg> dpm: I agree, I'm not sure if that is useful or more of a problem at this point.
[14:36] <kenvandine> seb128, should i go ahead and upload that rb patch too then?
[14:36] <kenvandine> just so it doesn't get forgotten :)
[14:36] <tedg> seb128: Yes, but I didn't realize what trouble that'd cause when I did it the first time :)
[14:36] <seb128> kenvandine, no, I've 2 other changes to batch there so no need to queue 2 uploads
[14:36] <kenvandine> ok
[14:36]  * kenvandine forgets about rb then
[14:36] <seb128> tedg, ok ;-) I will let dpm sort that
[14:36] <seb128> dpm, you can talk to oem and translators about the issue?
[14:38] <james_w> kenvandine: I am
[14:38] <kenvandine> james_w, hehe :)
[14:39] <dpm> seb128, sure, I'll be talking to kyleN this week anyway. tedg, I don't think there is anything we can do now, but next time the preferred way is either to export a tarball with the translations from the Ubuntu source packages and give them preference with msgmerge. I'll follow this up in an e-mail
[14:39] <tedg> dpm: Cool, thanks.
[14:39] <dpm> no worries
[14:40] <seb128> dpm, tedg: thanks
[14:45] <nigelb> kenvandine: got a couple of minutes?
[14:48] <kenvandine> nigelb, sure
[14:48] <kenvandine> nigelb, what's up?
[14:49] <nigelb> I'm working on getting the gwibber package to debian, so if I run into troubles can you help out (when you get the time)
[14:49] <kenvandine> sure
[14:49] <kenvandine> awesome!
[14:50] <nigelb> I spoke to the current maintainers, they currently have an issue with it not running
[14:53] <kenvandine> what version do they have?
[14:53] <kenvandine> nigelb, well let me know if you run into issues, i'll be happy to help
[14:54] <nigelb> kenvandine: they have an old bzr package
[15:01] <nigelb> kenvandine: debian has gwibber (1.2.0+bzr358-2) I'm trying to get the lastest package in.  Lemme see how it goes.  I'll keep you posted
[15:06] <chrisccoulson> hmmm, wiki.ubuntu.com is timing out again :-/
[15:09] <seb128> pitti, see bug #539636
[15:09] <ubottu> Launchpad bug 539636 in libatasmart "gdu wrongly reports bad disk sectors" [Undecided,New] https://launchpad.net/bugs/539636
[15:09] <seb128> pitti, I guess it doesn't have the infos you want though
[15:09] <seb128> pitti, can you tell me what those are?
[15:10] <seb128> pitti, "DevkitDisksDump: Error: [Errno 2] No such file or directory"
[15:11] <seb128> pitti, bah, /usr/share/apport/package-hooks/libatasmart4.py
[15:11] <seb128> devkit-disks -> udisks
[15:11] <seb128> pitti, is that just a udisks --dump log that you need?
[15:14] <fagan> kenvandine: I cant make a apport bug but gwibber is cashing with attributeerror in exclude_databases()
[15:15] <fagan> I havent been able to use it for a week now :/
[15:15] <kenvandine> fagan, ah... that is the same as jcastro got
[15:15] <kenvandine> please file a bug :)
[15:15] <kenvandine> or if you did.. point me at it please
[15:15] <fagan> Cant apport is broken :/
[15:16] <fagan> Hmmm is there any way to dump the apport info into a text file so I can report it manually?
[15:17] <fagan> pitti: ^
[15:17] <fagan> Oh its working now
[15:17] <seb128> fagan, you can apport-unpack the .crash
[15:18] <seb128> and copy the files you want
[15:18] <kenvandine> fagan, or just attach the log file
[15:18] <kenvandine> ~/.cache/gwibber/gwibber.log
[15:18] <fagan> apport is working now :) Ill point you to the report
[15:18] <kenvandine> thx!
[15:18] <kenvandine> fagan, it's a situation that the u1 guys say shouldn't be possible
[15:18] <kenvandine> if it is the issue i am thinking of
[15:19] <kenvandine> so i guess we need to handle it better in gwibber, and have the u1 guys fix it on their end too
[15:20] <fagan> kenvandine: https://bugs.launchpad.net/ubuntu/+source/gwibber/+bug/539641
[15:20] <ubottu> Launchpad bug 539641 in gwibber "gwibber-service crashed with AttributeError in exclude_databases()" [Undecided,New]
[15:20] <kenvandine> thx
[15:20] <kenvandine> yup
[15:20] <kenvandine> fagan, you use u1?
[15:20] <fagan> kenvandine: yep
[15:20] <kenvandine> fagan, you are paired with ubuntuone, but you have no pairing record in the db
[15:21] <kenvandine> which they claim isn't possible
[15:21] <kenvandine> :)
[15:21] <kenvandine> we thought jcastro was a corner case because of some of the really early testing he did
[15:21] <fagan> bah it is then we have proof
[15:21] <kenvandine> and i guess the same could be true for you :)
[15:21] <kenvandine> but still... :)
[15:21] <kenvandine> fagan, thx for the bug report
[15:22] <fagan> So its just a corner case then for people who have been using lucid since the early alphas
[15:22] <kenvandine> more likely karmic
[15:22] <jcastro> I am doomed. I even blew away all my U1 stuff and reauthed my PC
[15:22] <kenvandine> did you use u1 on karmic?
[15:22] <kenvandine> and like in the beta period?
[15:22] <kenvandine> jcastro, is that what they told you to do?
[15:23] <jcastro> no, it's my usual trying to fix u1 workflow
[15:23] <jcastro> I even have a script
[15:23] <kenvandine> hahaha
[15:23] <kenvandine> jcastro, that is sad dude
[15:23] <jcastro> it's like killev all over again
[15:24] <kenvandine> jcastro, can you "me too" that bug?
[15:24] <jcastro> done, and subbed
[15:25] <kenvandine> thx
[15:53] <tedg> pitti: Can you update the status of this branch please (house keeping branches)?  https://code.launchpad.net/~pitti/indicator-session/libupower-glib
[16:03] <pitti> seb128_: argh, I'll fix the libatasmart apport hook, sorry about that; yes, it's udisks --dump
[16:03] <pitti> fagan: apport-bug --save /tmp/report.apport packagename; and then apport-bug /tmp/report.apport on a different computer (or later on)
[16:03] <pitti> tedg: yes, can do
[16:04] <pitti> seb128_: ah, it doesn't have the disk blob either, presumably because it's also querying it from dk-disks
[16:05] <seb128_> pitti, I still have the box on, what do you need?
[16:05] <seb128_> pitti, I added the udisks log
=== seb128_ is now known as seb128
[16:05] <tedg> pitti: Thanks!
[16:06] <pitti> seb128: install libatasmart-bin and do sudo skdump --save=/tmp/smart.blob /dev/sda
[16:06] <pitti> seb128: and attach /tmp/smart.blob to the bug
[16:06] <seb128> pitti, ok
[16:08] <pitti> tedg: oh, great! you implemented it using async dbus calls now?
[16:10] <tedg> pitti: Yeah, merged that in this morning.
[16:10] <tedg> pitti: Trying to close out indicator-session issues :)
[16:10] <pitti> tedg: thanks!
[16:14] <seb128> tedg, nice to see you fixed the session locking one too ;-)
[16:14] <pitti> seb128: I committed the apport hook fix to debian git and uploaded a new libatasmart; thanks and sorry for the trouble
[16:14] <seb128> pitti, np, thank you for fixing it!
[16:18] <mvo> james_w: I owe you a beer for your fix for #455861 (at least one!)
[16:19] <mvo> james_w: thanks!
[16:19] <james_w> you've tested it?
[16:22] <rickspencer3> Riddell, can we discuss figuring out how to solve bug #538524 for beta in the desktop team meeting?
[16:22] <ubottu> Launchpad bug 538524 in plymouth "boot hangs on splash screen, doesn't switch to KDM" [Medium,Confirmed] https://launchpad.net/bugs/538524
[16:22] <seb128> pitti, smart blob added to the bug
[16:22] <pitti> seb128: cheers
[16:22] <Riddell> rickspencer3: it's top of my list of important issues, I've no idea where to start in solving it
[16:23] <seb128> pitti, I added the hdc one since that's the drive which is shown as having issues
[16:23] <pitti> seb128: "hdc"?
[16:23] <rickspencer3> thanks Riddell
[16:23] <rickspencer3> maybe we can get some help on it at the team meeting
[16:23] <seb128> pitti, /dev/hdc
[16:23] <seb128> pitti, you said "sudo skdump --save=/tmp/smart.blob /dev/sda"
[16:24] <seb128> pitti, I changed to /dev/hdc, that's correct right?
[16:24] <pitti> seb128: ah, the udisks dump has sdc; I take it you mean that one
[16:24] <pitti>       overall assessment:      Disk reports many bad sectors
[16:24] <pitti> seems so
[16:24] <seb128> pitti, ok good
[16:24] <seb128> pitti, anyway else before I take my usb stick back to reinstall the mini with it?
[16:25] <pitti> seb128: looks complete now
[16:25] <seb128> anyway -> anything
[16:25] <seb128> pitti, ok good, thank you!
[16:29] <rickspencer3> desktop team meeting in 1 minute, right?
[16:29] <ccheney> yea
[16:29] <chrisccoulson> cool, i've just got to reboot quickly ;)
[16:31] <tseliot> yep
[16:31] <rickspencer3> ArneGoetje, bryceh, ccheney, chrisccoulson, didrocks, kenvandine, Nafai, pitti, RAOF, Riddell, seb128, tkamppeter, tseliot
[16:31] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-03-16
[16:31] <pitti> o/
[16:31] <ArneGoetje> o/
[16:31]  * kenvandine waves
[16:31] <seb128> hey
[16:31] <ccheney> here
[16:31] <Riddell> hi
[16:31]  * rickspencer3 tops gavel
[16:31] <tseliot> o/
[16:31] <chrisccoulson> here
[16:31] <Nafai> uh oh, I'm included now
[16:32] <rickspencer3> let's get going ...
[16:32] <rickspencer3> hi Nafai, yeah, you can just follow along
[16:32] <rickspencer3> no action for you, just fyi
[16:32] <Nafai> :)\
[16:32] <rickspencer3> anyway ...
[16:32] <rickspencer3> before we start ...
[16:32] <rickspencer3> I want to say ...
[16:32] <rickspencer3> Lucid is totally rocking!
[16:33] <rickspencer3> I used Karmic on my kid's computer yesterday, and I was shocked by the progress that we've made in Lucid
[16:33] <pitti> ♪ weee willl weeeee will ... ♫
[16:33] <rickspencer3> I think we will look back on this release a special time
[16:33]  * kenvandine sings along
[16:33]  * rickspencer3 claps hands a bit out off time
[16:33] <tseliot> :-)
[16:33] <rickspencer3> ok
[16:33] <rickspencer3> so ...
[16:33] <rickspencer3> let's get to work
[16:33] <rickspencer3> first, outstanding actions from last week
[16:34] <rickspencer3> which I just realized I completely forgot to prepare :/
[16:34]  * rickspencer3 chastises self
[16:34] <rickspencer3> moving on ...
[16:34] <rickspencer3> kenvandine, partner update
[16:34] <kenvandine> ok
[16:34] <kenvandine> OLS will have some freeze exceptions
[16:34] <kenvandine> well, bugs already filed and linked on the wiki page
[16:35] <kenvandine> nothing major afaict
[16:35] <kenvandine> they are still having server side download issues with the music store
[16:35] <rickspencer3> :(
[16:35] <kenvandine> hopefully that will get fixed soon...
[16:35] <kenvandine> :(
[16:35] <kenvandine> it works as long as they restart it often
[16:35] <rickspencer3> kenvandine, do we have any kind of strategy for dealing with the (low) possibility that downloads won't be ready in time?
[16:36] <kenvandine> i think the current strategy is regular service restarts
[16:36] <kenvandine> which sucks... but downloads don't get lost
[16:36] <tkamppeter> hi
[16:36] <kenvandine> on to DX
[16:37] <kenvandine> they will have an update to indicator-me this week that will only display the status update entry if the gwibber service is running
[16:37] <kenvandine> so no string changes and overall a very welcome changes
[16:37] <kenvandine> i see no issues with that
[16:37] <rickspencer3> great!
[16:37] <kenvandine> and some regular bug fixes, which i think most of which seb128 has already patched
[16:37] <rickspencer3> this is what I envisioned the "stabilization and completion" milestone to be fore
[16:38] <seb128> I did but they fixed an another round of issues since ;-)
[16:38] <kenvandine> :)
[16:38] <kenvandine> that is all for the partner update
[16:38] <rickspencer3> having bug fixes come in too fast to keep up with is a problem I like to have
[16:38] <seb128> rocking dxteam work this cycle, everybody hugs tedg and bratsche and the others
[16:38] <kenvandine> yup
[16:38] <kenvandine> big high five to the DX team!
[16:38] <seb128> or pay them a beer at uds ;-)
[16:38] <rickspencer3> kenvandine, wrt Dx mostly, but also OLS, does this cycle seem somewhat more organized?
[16:38] <kenvandine> hehe
[16:38]  * pitti hugs tedg, bratsche, and davidbarth
[16:39] <kenvandine> rickspencer3, yes
[16:39] <rickspencer3> ok, never mind, what seb128 says :)
[16:39] <rickspencer3> rock!
[16:39] <kenvandine> rickspencer3, also
[16:39] <pitti> I think we learned from last cycle, on both ends
[16:39] <rickspencer3> indicator area = HUGE improvement for users
[16:39] <tedg> seb128: pitti Thanks guys.
[16:39]  * davidbarth reads up the log; feels good anyway ;)
[16:39] <rickspencer3> ok
[16:39] <kenvandine> we plan to get weekly releases going for OLS next cycle
[16:39] <kenvandine> so that will be great
[16:39] <rickspencer3> kenvandine, great
[16:39] <rickspencer3> thanks again to Dx for making Ubuntu great
[16:40] <rickspencer3> moving back a bit ..
[16:40] <tseliot> +1
[16:40] <rickspencer3> outstanding items from last meeting:
[16:40] <rickspencer3> ACTION: rickspencer3 to ask bdmurray about included targetedness of bugs in bug query
[16:40] <rickspencer3> ACTION: rickspencer3 to follow up with sabdfl to confirm that boot time cursor requirement is met
[16:40] <rickspencer3> ACTION: seb128 to generate a list of 100 "right" bugs to fix in Lucid
[16:40] <rickspencer3> ACTION: rickspencer3 and seb128 to discuss gdm greeter options, especially wrt sound
[16:40] <rickspencer3> so all are done, except the sabdfl thing
[16:40] <kenvandine> pitivi testing too
[16:40] <kenvandine> right?
[16:40] <rickspencer3> and he's on holiday, so I'll push that
[16:40] <rickspencer3> kenvandine, good point, that fell off the list :(
[16:40] <seb128> I didn't do "100" but didn't want to add not matching bugs to get the number
[16:40] <rickspencer3> seb128, but you started, right?
[16:40] <seb128> some bugs got dispatched to people on the way too
[16:41]  * kenvandine imported some DV clips from the camera and rendered a project
[16:41] <kenvandine> worked well
[16:41] <pitti> well, also we already assigned some bugs to individual people
[16:41] <rickspencer3> let's not call it "100 bugs"
[16:41] <pitti> https://bugs.edge.launchpad.net/~canonical-desktop-team/+assignedbugs
[16:41] <rickspencer3> let's call it "top bugs"?
[16:41] <seb128> rickspencer3, yes, we have a good list and dispatched some already
[16:41] <pitti> I'll get to that later on
[16:41] <rickspencer3> thanks pitti
[16:41] <pitti> we have a good amount of fodder now
[16:41] <rickspencer3> ACTION: rickspencer3 to ask bdmurray about included targetedness of bugs in bug query
[16:41] <rickspencer3> ACTION: rickspencer3 to follow up with sabdfl to confirm that boot time cursor requirement is met
[16:41] <rickspencer3> ACTION: seb128 to generate a list of 100 "right" bugs to fix in Lucid
[16:41] <rickspencer3> ACTION: rickspencer3 and seb128 to discuss gdm greeter options, especially wrt sound
[16:41] <seb128> I wish we had a way to list all milestoned bugs for members of a team on launchpad
[16:41] <rickspencer3> d'oh
[16:41] <rickspencer3> seb128, gdm greeter?
[16:42] <seb128> rickspencer3, the gdmsetup sound option change is in bzr
[16:42] <rickspencer3> great!
[16:42] <seb128> thanks to robert_ancell and didrocks mainly
[16:42] <rickspencer3> so we'll need a UI freeze exception for that
[16:42] <pitti> yohoo
[16:42] <rickspencer3> ah, so that's what didrocks was pushing on
[16:42] <pitti> seb128: so the "call gconftool from server" worked out in the end?
[16:42] <seb128> right, I will take care of that after beta1
[16:42]  * pitti hugs seb128
[16:42] <rickspencer3> (btw, didrocks is rocking a Ubuntu conference this week, so he'll be offline mostly)
[16:42] <seb128> pitti, yes, still an issue I need to talk with you about though
[16:43] <seb128> but after meeting
[16:43] <rickspencer3> ok
[16:43] <seb128> didrocks worked on that yesterday but the uid change is not working as he want
[16:43] <seb128> I said I would check with you
[16:43] <pitti> seb128: I bet it's effective vs. real uid
[16:43] <pitti> yes, after meeting
[16:43] <rickspencer3> seb128, maybe we could hand that off
[16:43] <rickspencer3> I think didrocks has enough on his plate ;)
[16:43] <rickspencer3> so moving on
[16:43] <seb128> rickspencer3, we did
[16:44] <rickspencer3> kenvandine mentions pittivi testing
[16:44] <seb128> rickspencer3, I said I would take over for the remaining part yesterday
[16:44] <rickspencer3> (thanks seb128, I should have guessed ;) )
[16:44] <seb128> -> pitivi
[16:44] <seb128> the new version is in lucid
[16:44] <rickspencer3> pitivi
[16:44] <rickspencer3> whatever
[16:44] <rickspencer3> video editing
[16:44] <seb128> please do test and file bugs
[16:44] <seb128> bonus point if you file them on bugzilla too ;-)
[16:44] <rickspencer3> seb128, I saw lots of "Fix Release" and not too many "New"
[16:44] <seb128> right
[16:44] <rickspencer3> so I am taking this to be a good sign
[16:44] <seb128> I'm not sure how much people played with the new version though
[16:45] <seb128> would be nice to have everybody trying it again
[16:45] <rickspencer3> ok
[16:45] <kenvandine> i just wish it could import from my DV camera, i hate having to re-learn dvgrab everytime :)
[16:45] <seb128> and filing bugs with apport if it crashes
[16:45] <rickspencer3> my gut tells me the pitivi team is quite close
[16:45] <kenvandine> but i hit no bugs creating a short 10m video out of about 5 clips
[16:45] <rickspencer3> kenvandine, pitivi is python, I'm sure they'll take a merge proposal from you
[16:45] <rickspencer3> ;) j/k
[16:45] <kenvandine> hehe
[16:45] <kenvandine> if i hit bugs :)
[16:45] <kenvandine> it worked perfectly!
[16:45] <kenvandine> which was nice
[16:46] <kenvandine> but always worked well for me with DV files :)
[16:46] <rickspencer3> I mean for the DV camera import
[16:46] <kenvandine> oh that
[16:46] <kenvandine> ewww
[16:46] <kenvandine> sounds hard to me :)
[16:46] <rickspencer3> it worked for me with a screen capture from gtk-record-my-desktop
[16:46] <kenvandine> cool
[16:46] <rickspencer3> and when I say "worked" I mean totally without issue
[16:46] <rickspencer3> I tried to make problems and couldn't
[16:47] <rickspencer3> ok, let's move on to Kubuntu, because I know Riddell has a rather serious issue to address
[16:47] <kenvandine> my wife saw me testing and now adding a task to my "Honey Do" list :)
[16:47] <kenvandine> she wants more video on DVD
[16:47] <Riddell>  * Beta is blocked by this bug https://launchpad.net/bugs/538524 "boot hangs on splash screen, doesn't switch to KDM"
[16:47] <rickspencer3> and I am hoping that we can rally and help out the Kubuntu team on this one
[16:47] <ubottu> Launchpad bug 538524 in plymouth "boot hangs on splash screen, doesn't switch to KDM" [Medium,Confirmed]
[16:47] <Riddell>    It apparantly requires a chunk of C to be written and tested.  Unsure how to move forward, I don't even know a workaround for beta.
[16:47] <Riddell>  * several SRUs are blocked in karmic-proposed unapproved queue
[16:47] <Riddell>  * Still waiting on new logo from design team, no word from them and Iain doesn't seem to be on IRC
[16:47] <rickspencer3> Riddell, design team is at training atm
[16:48] <kenvandine> i think done today
[16:48] <Riddell> hmm, maybe they shouldn't give me deadlines that fall on their training days
[16:49] <rickspencer3> Riddell, I just asked oubiwann to help us get this resolved
[16:49] <tseliot> ah, is this for the plymouth theme?
[16:49] <rickspencer3> Riddell, the plymouth thing seems a lot more serious though
[16:49] <rickspencer3> Riddell, would you rather focus on a work around, or focus on a fix for beta?
[16:50] <rickspencer3> (any why is it a Medium if it's blocking beta?)
[16:50] <seb128> timing seems to be really right to get a fix for beta now
[16:50] <seb128> *tight*
[16:50] <pitti> we have a quite similar problem with gdm
[16:50] <Riddell> rickspencer3: I don't see it getting fixed in time for beta unless keybuk decides to do it toot sweet
[16:51] <seb128> workaround: don't install plymouth on kubuntu?
[16:51] <pitti> Keybuk now knows what's wrong and is working on a solution
[16:51] <pitti> Riddell: alt+f7 doesn't help?:
[16:51] <rickspencer3> pitti, is he targetting that for beta? is it feasible to pull Plymouth from Kubuntu until it's fixed?
[16:51] <Riddell> pitti: no alt+f7 doesn't help
[16:52] <pitti> hm, then it's something else
[16:52] <Riddell> pitti: he is?  would be nice if he told me about it (well, would be nice if he's told me this was needed three months ago)
[16:52] <Keybuk> pitti: what's wrong is Riddell didn't do the work item he marked as DONE
[16:52] <pitti> rickspencer3: hm, I guess we could pull it somehow
[16:52] <rickspencer3> hold it
[16:52] <rickspencer3> let's not go down that path
[16:52] <rickspencer3> the past is of no use to us now
[16:52] <pitti> Riddell: I assumed it was the "doesn't switch to vt7 automatically" problem, which we discussed yesterday
[16:53] <rickspencer3> Keybuk, do you think we can pull Plymouth until this is fixed?
[16:53] <pitti> but apparently not
[16:53] <Keybuk> rickspencer3: we can't pull plymouth from a seed - mountall depends on it
[16:53] <rickspencer3> can we tell kubuntu not to use it?
[16:53] <rickspencer3> just hack in a work around that let's it boot for now?
[16:53] <Keybuk> not that I know of
[16:53] <rickspencer3> so we have no choice but to fix it
[16:54] <rickspencer3> who has the knowledge to address this?
[16:54] <rickspencer3> Keybuk, tseliot, pitti?
[16:54] <rickspencer3> anyone else?
[16:54] <rickspencer3> chrisccoulson ?
[16:54] <Keybuk> kdm is written in C++ in Qt
[16:54] <Riddell> needs someone who knows C and how to debug VTs and whatnot
[16:54] <rickspencer3> seb128, ?
[16:54] <Riddell> Keybuk: the backend is C
[16:54]  * tseliot doesn't know what the problem is
[16:54] <chrisccoulson> me neither ;)
[16:54]  * tseliot reads the bug report
[16:54] <pitti> rickspencer3: one rather drastic way would be to drop the mountall dependency and seed it on ubuntu for now
[16:54] <chrisccoulson> i could probably help out it if it was gdm
[16:55] <seb128> rickspencer3, I don't
[16:55] <Riddell> tseliot: KDM's backend needs to talk to plymouth before and after starting X (I think)
[16:55] <Keybuk> pitti: err, but then you wouldn't have any filesystems on boot <g>
[16:55] <Keybuk> pitti: and wouldn't have any services running, from dbus all the way past kdm :p
[16:55] <rickspencer3> Keybuk, is the implementation strategy known, but just needs someone to do the programming?
[16:55] <pitti> Keybuk: hm, did that change recently? I didn't have plymouth installed until some days ago
[16:55] <Keybuk> rickspencer3: yup, SMOP
[16:55] <pitti> Keybuk: mountall depends libplymouth2 only, AFAICS?
[16:55] <rickspencer3> SMOP?
[16:56] <Keybuk> pitti: oh, right
[16:56] <Keybuk> rickspencer3: Simple Matter of Programming
[16:56] <rickspencer3> sill manager off point questions?
[16:56] <pitti> AFAICS it's just an ubuntu-standard recommends
[16:56] <Riddell> rickspencer3: Keybuk gave me the psudocode of what needs done, needs it turned into C and put into the right places in KDM's code
[16:56] <rickspencer3> Riddell, so we just need someone to step up and do this today?
[16:56] <Riddell> "just"
[16:56] <pitti> so in theory we could even blacklist it from the kubuntu seeds for now, perhaps?
[16:57] <rickspencer3> I'll take that as a yes
[16:57] <rickspencer3> Riddell, how many hours of programming?
[16:57] <tseliot> Riddell: where's this pseudocode?
[16:57] <rickspencer3> would you estimate?
[16:57] <Riddell> rickspencer3: depends if you can find the right places in KDMs code.  maybe 3 (plus testing)
[16:58] <Keybuk>  in kdm, before starting the X server
[16:58] <Keybuk>  call plymouth --ping
[16:58] <Keybuk>  if this has exit status 0 (true), plymouth is running
[16:58] <Keybuk>  if plymouth is running
[16:58] <Keybuk>    call plymouth deactivate
[16:58] <Keybuk>    then call plymouth --has-active-vt
[16:58] <Keybuk>    if this has exit status 0 (true), plymouth was displaying a splash screen and has terminated leaving it on screen
[16:58] <Keybuk>      get the currently active vt
[16:58] <Keybuk>      start the X server *on that vt*
[16:58] <Keybuk>      if the X server starts ok
[16:58] <Keybuk>        call plymouth quit --retain-splash
[16:58] <Keybuk>      if the X server *fails to start)
[16:58] <Keybuk>        call plymouth quit
[16:58] <Keybuk>    if plymouth --has-active-vt has a non-zero exit status (false), plymouth might have been running but did not display a splash screen
[16:58] <Keybuk>      call plymouth quit
[16:58] <Keybuk>      start the X server as you previously would have (hardcoded to VT7 I assume)
[16:58] <Keybuk>  if plymouth --ping has a non-zero exit status (false), plymouth was not running
[16:58] <Keybuk>    start the X server as you previously would have (hardcoded to VT7 I assume)
[16:58] <Keybuk> <Keybuk> oh, and I forgot
[16:58] <Keybuk>  the other bit (I always forget this)
[16:58] <Keybuk>  when you start X on the current vt, pass -nr
[16:58] <Keybuk>  e.g. -nr vt7
[16:58] <rickspencer3> http://paste.debian.net/64495/
[16:58] <rickspencer3> :)
[16:58] <seb128> I think 3 is optimistic to find your way around a new codebase and do such changes
[16:59] <rickspencer3> tseliot, do agree with 3 hour estimate?
[16:59] <Riddell> well I'm trying to not be too pessimistic :)
[16:59] <tseliot> rickspencer3: I wouldn't know, I would have to look at kdm first
[17:00] <rickspencer3> does *anyone* here know kdm?
[17:00] <seb128> I don't
[17:00] <rickspencer3> ok
[17:00] <rickspencer3> I think we'll need to consider going down the mitigation path
[17:00]  * tseliot grabs the code
[17:00] <Riddell> it's the same code as xdm which is 15 years old and not the sort of code most people like to touch
[17:01] <tseliot> oh
[17:01] <pitti> realistically for beta-1, I think it might be easier to disable plymouth?
[17:01] <rickspencer3> Keybuk, pitti what pitti just said
[17:01] <seb128> I would think so too
[17:01] <pitti> after all, half of the people had it uninstalled until a week ago
[17:01] <rickspencer3> not just easier, but in fact feasible
[17:01] <seb128> can we just make a small change to kdm code which make the thing boot?
[17:01] <seb128> even if it doesn't display the splash when it should etc
[17:02] <seb128> or do we need the full login to get it booting?
[17:02] <Keybuk> rickspencer3: I don't know what any effects of that might be
[17:03] <rickspencer3> Keybuk, well, I think there will be a change/test/change/... cycle involved with the mitigation
[17:03] <seb128> Keybuk, do we need the full logic you described before of would part of it only allow to go through boot even if visually it doesn't do what it should?
[17:03] <rickspencer3> it won't be no work
[17:03] <tseliot> would a certain degree of temporary ugliness be tolerated?
[17:03] <Keybuk> seb128: I don't understand why not having the logic doesn't allow it to go through the boot ;)
[17:03] <rickspencer3> it will be work, but seems more likely to unblock Kubuntu beta than trying to fix it
[17:03] <Keybuk> it should work anyway
[17:04] <seb128> Keybuk, can you try to help Riddell maybe there to figure why it's blocking?
[17:04] <Keybuk> unfortunately in debugging, slangasek and I had assumed that Plymouth had the same code as gdm
[17:04] <seb128> can->could
[17:04] <Keybuk> since the work item had been marked done
[17:04] <Keybuk> so that changes things
[17:04] <Keybuk> seb128: honestly, not really
[17:04] <Keybuk> I haven't time
[17:05] <tseliot> if the answer to my question ^^ is yes we can just prevent plymouth from loading if kdm is installed/in use
[17:05] <tseliot> just like we do when we check the "splash" boot parameter in plymouth
[17:05] <tseliot> would this be acceptable as a hack before we get an actual solution?
[17:05] <Riddell> uglyness is fine for beta, better than a frozen bootup
[17:05] <seb128> tseliot, graphical issues are not a stopper there I would say
[17:06] <pitti> tseliot: I thought without splash it'd boot in text mode?
[17:06] <seb128> ie if you can make it boot without splash I would consider it enough for beta1
[17:06] <pitti> yes, I agree
[17:06] <tseliot> Keybuk: yes, no, will you to kill me if I do it :-P ?
[17:06] <pitti> if we'd hack ubuntu-meta and kubuntu-meta to not pull in plymouth, this would amount to the same anyway
[17:07] <pitti> Riddell: does it boot without the "splash" parameter?
[17:07] <tseliot> pitti: no, AFAIK it falls back to text only if splash is there and your driver doesn't have a decent framebuffer
[17:07] <pitti> this could just be temporarily changed in cdimage
[17:07] <Riddell> pitti: I've no idea, I can't edit grub so I can't even workaround it locally
[17:07] <tseliot> s/to/try/
[17:07]  * tseliot can't spell today
[17:07] <pitti> Riddell: wouldn't the live system have the same problem?
[17:08] <pitti> you can edit boot parameters in the boot splash thing with F6
[17:08] <Riddell> pitti: doesn't seem to, live system is fine for me
[17:08] <Keybuk> tseliot: the splash parameter in plymouth doesn't disable plymouth though
[17:08] <pitti> Riddell: pressing shift during boot should fire up the grub menu
[17:08] <Riddell> pitti: it doesn't
[17:08] <pitti> oh, let's try to figure this out after the meeting, shall we?
[17:08] <Keybuk> sorry, the lack of a splash parameter
[17:08] <tseliot> Keybuk: no, but it can prevent it from showing the splash, right?
[17:08] <Keybuk> tseliot: no
[17:08] <Keybuk> it just changes the plugin plymouth uses
[17:09] <tseliot> ah, so pitti is right
[17:09] <Keybuk> a lot of the reports of KDM issues are with the text plugin anyway
[17:09] <tseliot> Keybuk: we can change that though
[17:09] <Keybuk> tseliot: err, no, please don't
[17:09] <pitti> tseliot, Keybuk: question is if it's still hanging in text mode?
[17:09] <tseliot> :-)
[17:10] <rickspencer3> so what's the resolution?
[17:10] <Keybuk> you'll just discover new bugs by moving things around
[17:10] <Keybuk> rickspencer3: 1024x768 :p
[17:10] <rickspencer3> we'll try unseeding Plymouth?
[17:10] <pitti> I'd check it in text mode first
[17:10] <rickspencer3> or not using it for Kubuntu?
[17:10] <pitti> if that boots, we can just work around it in cdimage
[17:10] <rickspencer3> who can work with Riddell on testing that?
[17:10] <pitti> and failing that, remove plymouth from -meta
[17:12] <pitti> rickspencer3: I'm fine to help out with seed changes, etc.
[17:12] <pitti> will take me a while to download the current kubuntu CD, though, but perhaps Riddell can do the testing, since he's able to reproduce
[17:12] <kenvandine> i can do some testing in a VM
[17:12]  * kenvandine downloads latest image
[17:12] <Riddell> kenvandine: I don't have this problem in a VM
[17:12] <rickspencer3> pitti, am I understanding this correctlyL
[17:13] <kenvandine> Riddell, :/
[17:13] <rickspencer3> plan 1 - force Kubuntu to use plymouth text plugin
[17:13] <rickspencer3> if that doesn
[17:13] <rickspencer3> t work fall back to
[17:13] <seb128> I can't really help with that, I've no kubuntu image handy and with my download speed it would take hours to download one
[17:13] <kenvandine> Riddell, i could dig up hardware to install on
[17:13] <rickspencer3> plan 2 - don't install Plymouth at all on Kubuntu (and do whatever seed changes are required by that?)
[17:13] <kenvandine> does it only affect certain drivers?
[17:13] <pitti> rickspencer3: right
[17:14] <rickspencer3> ok
[17:15] <rickspencer3> so pitti to organize this, Riddell and kenvandine to help with testing?
[17:15] <tseliot> Riddell: I guess it can all be done in kdm/backend/server.c
[17:15] <kenvandine> i am happy to test, just ping me
[17:15] <chrisccoulson> i could probably help out with testing too
[17:15] <chrisccoulson> tseliot, i was just looking in there too. it doesn't look very pretty
[17:15] <rickspencer3> ok
[17:16] <rickspencer3> Riddell, do you think that plan 1, plan 2 will unblock Kubuntu beta 1?
[17:16] <Riddell> I don't know what plan 1 involves
[17:16] <tseliot> chrisccoulson: it's not so ugly, assuming that it works ;)
[17:16] <pitti> Riddell: boot with nosplash
[17:16] <Riddell> pitti: how?
[17:16] <Keybuk> err
[17:16] <rickspencer3> Riddell, do you think that plan 2 will unblock with beta
[17:16] <Keybuk> what's "nosplash" ? :)
[17:16] <rickspencer3> ?
[17:17] <pitti> s/no/no /, sorry
[17:17] <pitti> Riddell: mind you, I have no idea at all whether this can work; but since we don't know why it's hanging in the first place, it's worth a try
[17:17] <pitti> Riddell: it can be disabled in grub (either in the menu, or by booting in rescue mode and editing it in /etc)
[17:18] <rickspencer3> I'd like to move off this topic in the meeting and move this plan into action
[17:18] <Riddell> pitti: and you can help me work out how to do that locally to test and on the CD if it works?
[17:18] <pitti> Riddell: yes
[17:18] <sabdfl1> Riddell: no need to block on artwork for beta1
[17:18] <Riddell> rickspencer3: that'll be our plan for beta then
[17:19] <Riddell> sabdfl1: right, we're aiming for beta 2 for the new logo now
[17:19] <rickspencer3> Riddell, sabdfl1 let's just get the new logo asap ;)
[17:20] <rickspencer3> Riddell, may we move on?
[17:20] <Riddell> rickspencer3: yes
[17:20] <rickspencer3> thanks Riddell
[17:20] <rickspencer3> pitti, release status?
[17:21] <pitti> ok, so fir st beta-1: http://people.canonical.com/~pitti/workitems/canonical-desktop-team-ubuntu-10.04-beta-1.html
[17:21] <pitti> I moved the remaining coding ones over to http://people.canonical.com/~pitti/workitems/canonical-desktop-team-ubuntu-10.04-beta-2.html
[17:21] <pitti> there are four WIs left, which I think should be doable until Thursday
[17:22] <pitti> kenvandine, tseliot, chrisccoulson, didrocks: please let me know if you don't have time for them, but please try to get them done by Thu
[17:22] <pitti> otherwise this looks quite well
[17:22] <rickspencer3> wow
[17:22] <rickspencer3> close
[17:22] <chrisccoulson> pitti - i shouldn't have any issues
[17:22] <pitti> I won't talk about beta-2 just yet, that's for next week
[17:23] <kenvandine> ok
[17:23] <pitti> chrisccoulson: right, you just need the package list reviewed?
[17:23] <chrisccoulson> pitti - yeah, which i've pretty much done. already, some people are disagreeing with my choices of extensions to remove though
[17:23] <pitti> kenvandine: and you just have "write test plan" and an apport hook improvement?
[17:23] <tseliot> pitti: do you want me to upload fglrx even with the freeze? (just asking)
[17:23] <pitti> tseliot: please do
[17:23] <tseliot> ok
[17:23] <kenvandine> apport hook?
[17:23] <pitti> tseliot: just to get it off the list (it'll stay in unapproved until after beta-1)
[17:23] <kenvandine> pitti, where is that?
[17:24] <tseliot> pitti: aah, ok
[17:24] <pitti> kenvandine: oh, sorry, I thought tehre was something about "wrong notify priorities"
[17:24] <pitti> kenvandine: nevermind, must hav mixed it up; it's just two documentation things
[17:24] <kenvandine> :)
=== sabdfl1 is now known as sabdfl
[17:24] <pitti> ok, the more interesting thing now
[17:24] <pitti> https://bugs.edge.launchpad.net/~canonical-desktop-team/+assignedbugs
[17:24] <rickspencer3> ya!
[17:24] <pitti> seb128 worked hard on producing a list of bugs which aren't earth shattering, but woudl really be nice to be fixed in lucid
[17:25] <pitti> some already got assigned to individual team members
[17:25] <pitti> but those still need to
[17:25] <pitti> so, I wanted to hear some general opinions
[17:25] <pitti> (1) I could go ahead and fan them out to appropriate people
[17:25] <pitti> and you guys reassign them back if you don't have time
[17:25] <pitti> or
[17:25] <pitti> (2) everyone grabs a bunch
[17:26] <pitti> with "everyone" being our GNOME loving team members
[17:26] <chrisccoulson> i see there's a gpm one that's probably appropriate for me ;)
[17:26] <pitti> chrisccoulson, didrocks, pitti, RAOF, seb128
[17:26] <rickspencer3> pitti, can we do #2 for say, rest of the week, and then you clean up with #1?
[17:26] <pitti> rickspencer3: heh, I was just going to propose that ;)
[17:26] <seb128> I would prefer (2)
[17:26] <seb128> we already dispatched things around
[17:27] <seb128> but I feel people are already quite loaded with tasks now
[17:27] <seb128> so I would rather prefer having people picking extra one if they feel they have capacity for those
[17:27] <pitti> I'm not sure how everyone's task list looks like after beta-1
[17:27] <chrisccoulson> pretty heavy now :)
[17:28] <pitti> so, those five of us, can we grab 5 bugs each for now and see how far we get?
[17:28] <seb128> chrisccoulson has lot of assigned tasks already
[17:28] <seb128> pitti, you too apparently
[17:28] <seb128> not sure about other people
[17:28] <rickspencer3> not to mention compiz maintaining
[17:28] <seb128> lol
[17:28] <pitti> well, remember that you can still unassign later on, or just not get it done
[17:28] <pitti> but it's good to have it on someone's radar
[17:28] <seb128> I would rather not have people claim bugs if they are realistically not going to work on those
[17:28] <chrisccoulson> seb128 - could we also add bug 390816 to the list please :)
[17:28] <ubottu> Launchpad bug 390816 in gnome-power-manager "external monitor output is switched off when closing the laptop-lid when gnome-power-manager is set to blank screen on closing" [Medium,Triaged] https://launchpad.net/bugs/390816
[17:29] <seb128> so they don't lock potential work from other contributors or team members
[17:29] <rickspencer3> I agree with seb128
[17:29] <seb128> chrisccoulson, oh right, doing that now
[17:29] <pitti> after beta-1, our focus should move from the WI tracker to https://bugs.edge.launchpad.net/people/+me/+assignedbugs
[17:29] <rickspencer3> I'd rather have them on the list unassigned
[17:29] <rickspencer3> unless there is a 80% firm commitment to fix it
[17:29] <pitti> rickspencer3: nobody will look at that, though
[17:29] <chrisccoulson> seb128 - thanks
[17:29] <pitti> I don't believe in unassigned milestoned bugs
[17:29] <pitti> from a long experience
[17:30] <seb128> pitti, I would expect you do once your +assignedbugs is empty
[17:30] <rickspencer3> fair enough
[17:30] <pitti> so I think everyone should grab a few, get them done, and reiterate until release
[17:30] <seb128> ok, works for me
[17:30] <pitti> seb128: a lot of stuff on my +assignedbugs isn't necessarily for lucid, though
[17:30] <seb128> please grab things you think you can get done
[17:30] <rickspencer3> pitti, ok, that's pretty much what i was trying to say
[17:30] <pitti> ok, so there's enough game around, go ahead and hunt!
[17:31] <rickspencer3> thanks pitti
[17:31] <pitti> we'll review this list every week from now on
[17:31] <rickspencer3> also thanks to seb128 for leading the top bugs effort
[17:31] <pitti> and remember:
[17:31] <seb128> np ;-)
[17:31] <pitti> http://qa.ubuntu.com/reports/bug-fixing/lucid-fixes-report.html
[17:31] <pitti> we have to chase seb128!
[17:31] <seb128> lol
[17:31] <hernejj> seb128: Excuse me for interjecting, where can community members who are interested in helping out find this "100 bug list"?
[17:32] <rickspencer3> I will give one of my track lead t-shirts to anyone who gets within 80% of seb128
[17:32] <rickspencer3> hi hernejj!
[17:32] <seb128> hernejj, https://bugs.edge.launchpad.net/~canonical-desktop-team/+assignedbugs
[17:32] <rickspencer3> pitti, else for release status, or can we close the meeting
[17:32] <rickspencer3> ?
[17:32] <seb128> hernejj, it's not really 100 but that's the list
[17:32] <pitti> rickspencer3: I'm done
[17:33] <rickspencer3> "top bugs" not "100 bugs" ;)
[17:33] <rickspencer3> okay
[17:33] <seb128> I think I asked before
[17:33] <seb128> but nobody has a way to list lucid tasks for all team members on one webpage?
[17:33] <pitti> rickspencer3: if you add the ones on our personal +assignedbugs, it's 100 :)
[17:33] <pitti> seb128: bughugger can do that, I think
[17:33] <rickspencer3> nice
[17:33] <seb128> I would like to have an overview of how many bugs everybody claimed
[17:33] <rickspencer3> seb128, bughugger has that as of this morning
[17:33] <seb128> so we can try unload people who have too many
[17:34] <rickspencer3> do the json search for desktop team assigned
[17:34] <seb128> rickspencer3, ok, I will try that in a bit, maybe you can tell me what to do after the meeting?
[17:34] <rickspencer3> and then filter by release contains lucod
[17:34] <seb128> ok, seems easy
[17:34] <seb128> thanks
[17:34] <rickspencer3> seb128, I'll be around later if it doesn;t work for you
[17:34] <seb128> k, thanks
[17:34] <rickspencer3> bdmurray just added the release column, and I haven't tried it
[17:34] <rickspencer3> any other business?
[17:35] <rickspencer3> tick
[17:35] <rickspencer3> tick
[17:35] <rickspencer3> ok
[17:35] <rickspencer3> great
[17:35]  * rickspencer3 taps gavel
[17:35] <rickspencer3> thanks all!
[17:35] <rickspencer3> let
[17:35] <rickspencer3> s get that Kubuntu beta out there!!
[17:35] <rickspencer3> :)
[17:35] <seb128> thanks
[17:37] <Riddell> pitti: so, what needs set in grub, and how can I set grub's settings from a live CD?
[17:37]  * kenvandine digs up hardware to install kubuntu on :)
[17:38] <pitti> Riddell: what happens if you hold the left shift key down during boot?
[17:38] <Riddell> pitti: no change
[17:38] <pitti> strange
[17:39] <pitti> Riddell: you hold that down already when the bios boots?
[17:39] <pitti> it needs to be done rather early
[17:39] <pitti> Riddell: anyway, from a live CD, mount the root partition and edit /boot/grub/grub.cfg
[17:39] <Riddell> yes, just tried it, no sign of grub, usplash starts and freezes with 5 orange dots
[17:39] <pitti> Riddell: search for "keystatus"
[17:40] <pitti> replace that entire if..fi block with "set timeout=10"
[17:40] <pitti> that should show the menu during boot
[17:41] <pitti> Riddell: then, if you see it, edit the "linux" line to drop "splash"
[17:41] <pitti> Riddell: let's see what that does; expected result is that usplash starts in text mode
[17:41] <pitti> I don't know whether it makes a difference, but it's worth trying IMHO
[17:41] <Riddell> live CD booting..
[17:46] <Riddell> groovy, grub showing
[17:46] <Riddell> voila, no splash and KDM starts
[17:47] <pitti> does it shutdown correctly, too?
[17:47] <pitti> Riddell: would probably be worth trying this five times or so, just to check that it's not just good luck
[17:47] <pitti> Riddell: how reliable is the hang with "splash"?
[17:48] <Riddell> pitti: shuts down fine, no splash shown
[17:48] <Riddell> starts up fine a second time with me editing grub, no splash shown
[17:49] <pitti> Riddell: hm, none at all?
[17:49] <pitti> tseliot, Keybuk: until a week ago or so, removing "splash" used the text backend of plymouth; did that change?
[17:49] <Riddell> pitti: hang with splash happens every time on this computer
[17:49] <tkamppeter>  pitti, hi
[17:49] <pitti> Riddell: finally, can you try booting the live system without "splash"? that should give a different timing behaviour
[17:49] <pitti> tkamppeter: o/
[17:50] <tkamppeter> pitti, can you help me debugging a dbus problem?
[17:50] <pitti> Riddell: so, it's text mode, but perhaps acceptable for b1?
[17:50] <pitti> tkamppeter: not right now, sorry; can we talk tomorrow?
[17:50] <pitti> tkamppeter: or just ask around in #u-devel and see if someone bites? (otherwise we can debug tomorrow morning)
[17:51] <tkamppeter> OK, seems that the meeting did not end for you.
[17:51] <pitti> tkamppeter: meeting did, but not the fun :)
[17:51] <Riddell> pitti: this is acceptable for beta 1 yes
[17:51] <pitti> Riddell: let's discuss that in #u-release a bit
[17:52] <seb128> chrisccoulson, did you want to claim bug #390816 btw?
[17:52] <Riddell> pitti: hum, booting live CD without "splash" gives me a blank screen and no KDM
[17:52] <pitti> Riddell: there might be two places -- one is the boot option for the live system, and one for the installed one, but I'm not sure; I pinged cjwatson
[17:52] <seb128> chrisccoulson, there is the lucid task now but it's unassigned
[17:53] <chrisccoulson> seb128 - yeah, i will look at that one
[17:53] <seb128> chrisccoulson, thanks
[17:53] <ubottu> Launchpad bug 390816 in gnome-power-manager "external monitor output is switched off when closing the laptop-lid when gnome-power-manager is set to blank screen on closing" [Medium,Triaged] https://launchpad.net/bugs/390816
[17:53] <seb128> chrisccoulson, assigning to you
[17:53] <pitti> Riddell: not even a text cursor?
[17:54] <jcastro> kenvandine: if we're turning on salut by default why ask the user for the name and all that when we can get that from the system?
[17:54] <kenvandine> jcastro, because it isn't always set
[17:54] <jcastro>  a person's username?
[17:54] <seb128> well it could use the system info to prefil values
[17:54] <jcastro> ^^^
[17:55] <kenvandine> jcastro, feel free to re-open if you think it could be better
[17:55] <kenvandine> that would be fun to work on :)
[17:55] <jcastro> well, not for lucid
[17:55] <seb128> the username at least should be easy
[17:55] <pitti> Riddell: another thing worth testing is to purge plymouth
[17:55] <kenvandine> seb128, yeah... that has to exist :)
[17:55] <Riddell> pitti: oh this time it booted ok from the live CD without "splash"
[17:55] <pitti> Riddell: I'm pretty sure that a system works fine without plymouth at all
[17:55] <pitti> Riddell: I'm less sure about "no splash", that gave some trouble in the past
[17:56] <jcastro> kenvandine: perhaps when U1 ties in the person's avatar and all the about-me stuff; that would be a good time to prefill things like that
[17:56] <pitti> Riddell: so that we can test both possibilities, and then work out what's easier to do
[17:56] <Keybuk> pitti: text mode has the ENTER kills X bug still
[17:57] <Keybuk> but yes, splash vs. no splash changes the plymouth plugin from script to text or details
[17:57] <Keybuk> can't remember which offhand
[17:57] <Keybuk> might be details
[17:57] <Keybuk> which I don't think has the enter kills X bug - at least, haven't replicated it on that one
[17:58] <pitti> Keybuk: I didn't get that one without splash two weeks ago, but some other funny effects (can't remember the details any more)
[17:58] <pitti> back then, slangasek said "drop splash -> don't do that", but a lot has changed since then
[17:58] <Keybuk> atm, text.so is the only plugin that kills X :p
[17:58] <Keybuk> anything with a proper renderer works
[17:58] <pitti> ok, so it seems we should rather not install it at all then; seems safer than hoping that text mode works
[17:59] <Keybuk> that would probably be better
[17:59] <Keybuk> it'll stop me getting bug reports
[18:01] <Riddell> pitti: third time unlucky with live CD boot, no KDM this time either
[18:01] <pitti> Riddell: ok, let's not pursue the "drop splash" thing then; too unreliable
[18:01] <Sarvatt> can you just throw stty -F /dev/tty7 -isig in a startup script for now to fix the text plugin enter crashes? (that works here)
[18:03] <Riddell> pitti: so plan 2, just apt-get remove plymouth?
[18:03] <Riddell> that also removes plymouth-x11
[18:03] <pitti> that's fine; I don't think we're using p-x11 for anything right now
[18:03] <pitti> well, maybe we do
[18:04] <pitti> but I never had problems without having it
[18:04] <Riddell> seems to boot fine, moans about plymouth being terminated but KDM starts
[18:06] <Riddell> pitti: I guess I need to remaster the CD image to test that on the live CD
[18:07] <pitti> Riddell: use persistency?
[18:07] <pitti> (usb key)
[18:07] <Riddell> oh aye, I'll try that
[18:07] <pitti> Riddell: but see #release, seems this would have some drawbacks as well
[18:10] <pitti> Riddell: so in the end it seems that plymouth is chained to our testicles now, and we have to fix kdm somehow
[18:10] <Riddell> maybe we could offer tseliot irn bru?
[18:10] <pitti> tseliot, Keybuk: wrt your idea about a simpler approach, could we just add "plymouth --quit" to kdm's upstart job for now?
[18:11] <Keybuk> pitti: we have exactly that, basically
[18:11] <Keybuk> apparently that doesn't work
[18:11] <Keybuk> I'm confused about that
[18:11] <tseliot> Riddell: uh?
[18:12] <Riddell> tseliot: or any other beverage that might persuade you to write this patch tonight :)
[18:12] <tseliot> Riddell: really you don't want me to write code when I'm tired
[18:13] <tseliot> Keybuk: can't we just make kdm install a file in, say, /lib and make the plymouth upstart scripts look for that file and not start? (temporarily)
[18:14] <Keybuk> tseliot: that's the same as not installing plymouth
[18:14] <Keybuk> which means you're screwed when it comes to filesystem issues or cryptsetup, etc.
[18:14] <tseliot> right, mountall
[18:14] <pitti> right, that's why I thought a simple plymouth --quit in the kdm.init might be better
[18:14] <Keybuk> pitti: there's a plymouth --quit in plymouth.conf
[18:14] <Keybuk> which is run on "starting kdm"
[18:14] <Keybuk> but I've no idea why that doesn't work
[18:15] <pitti> is that really confirmed to be a kdm problem? or perhaps a hardware related one?
[18:15] <Keybuk> it works just fine on intel ;p
[18:15] <Keybuk> lots of people are confirming they see "login:"
[18:15] <Keybuk> even when they shouldn't :p
[18:15] <Keybuk> sorry on ubuntu, not intel
[18:15] <Keybuk> intel-on-the-brain today
[18:16] <pitti> Riddell: when the hang occurs, can you ssh in and check if plymouthd/kdm/Xorg are running?
[18:17] <pitti> Riddell: "initctl list" should tell which jobs are active; in particular, whether it already started kdm and stopped plymouth
[18:17] <Riddell> could try
[18:17] <pitti> or whether it's eternally hanging in plymouth itself
[18:17] <Keybuk> also how many dots do you see? :p
[18:17] <Riddell> 5 orange ones
[18:18] <Keybuk> does it jump to all 5 ?
[18:18] <tseliot> Keybuk: kdm.conf seems to emit "starting-dm", why can't we catch that?
[18:19] <pitti>    [ "$UPSTART_EVENTS" = "starting" -a "$JOB" = "kdm" ] && retain_splash="--retain-splash"
[18:19] <Keybuk> tseliot: we don't use that for anything
[18:19] <pitti> Keybuk: perhaps the --retain-splash is a culprit?
[18:19] <Keybuk> pitti: actually that line of code can never be true, but anyway
[18:19] <pitti> ah, ok
[18:19] <Riddell> Keybuk: jumps from 1 to 5 orange then freezes
[18:19] <Keybuk> that's where we *started* from :)
[18:19] <Keybuk> we did the whole "err, this code is actually wrong - why hasn't kdm noticed" thing
[18:19] <Keybuk> ok
[18:20] <Keybuk> if it jumps to 5, that means "plymouth quit" has been run
[18:20]  * tseliot -> dinner
[18:20] <pitti> I thought that was meant to go back to VTs (like in server)
[18:20] <Keybuk> it is
[18:20] <Keybuk> that's quite odd in of itself
[18:20] <Riddell> "initctl list" http://kubuntu.pastebin.com/ihF7cChn
[18:21] <pitti> so, plymouth is stopped and kdm running
[18:21] <Keybuk> Riddell: and no plym in ps ?
[18:21] <Riddell> plym is not in ps, kdm is in ps
[18:22] <Keybuk> and what do you see on screen?
[18:22] <Riddell> "ubuntu" plymouth splash with 5 orange dots
[18:23] <pitti> Riddell: does kdm have a patch to start the first X server on vt 7?
[18:23] <Keybuk> can you paste the X line from ps?
[18:23] <pitti> Riddell: sudo ls -l /proc/`pidof X`/fd|grep tty
[18:24] <Keybuk> also ls -l /proc/$(pidof X)/fd | grep tty
[18:24] <pitti> heh
[18:24] <pitti> Riddell: if that's tty1, then bad things will happen
[18:24] <pitti> they'd also happen without plymouth, though
[18:24] <Keybuk> not hugely bad
[18:24] <Keybuk> right
[18:24] <Keybuk> it still confuses me why the plymouth stuff is still on screen
[18:25] <Keybuk> could you also grab me cat /proc/fb
[18:25] <pitti> Keybuk: oh? before we had that it was completely screwed for me; getty would start on top of X and grab all the keypresses
[18:25] <Riddell> it has this patch from fedora http://bazaar.launchpad.net/~kubuntu-members/kdebase-workspace/ubuntu/annotate/head:/debian/patches/kubuntu_104_kdm_active_vt_plymouth.diff
[18:25] <Keybuk> pitti: you can use the mouse ;-)
[18:25] <Keybuk> up until the point getty gets bored, respawns, and nukes X
[18:25] <Keybuk> Riddell: what triggers using that patch?
[18:25] <Keybuk> nothing should afaict
[18:25] <Riddell> Keybuk: it's always used, the code runs if /var/spool/gdm/force-display-on-active-vt exists
[18:26] <Keybuk> nothing makes that though
[18:26] <Riddell> right, so the patch does nothing
[18:28] <Keybuk> afaict
[18:28] <Keybuk> output of the above commands would be nice ...
[18:28] <Riddell> lrwx------ 1 root root 64 2010-03-16 18:28 7 -> /dev/tty8
[18:28] <Riddell> that's sudo ls -l /proc/`pidof X`/fd|grep tty
[18:29] <Riddell> >sudo ls -l /proc/$(pidof X)/fd | grep tty
[18:29] <Riddell> lrwx------ 1 root root 64 2010-03-16 18:28 7 -> /dev/tty8
[18:29] <Keybuk> ok
[18:29] <Keybuk> that's used the first inactive VT
[18:29] <Keybuk> silly question
[18:29] <Keybuk> have you tried pressing Alt+F8 ? :)
[18:29] <Keybuk> or maybe ssh in and chvt 8
[18:29] <Keybuk> what's in /proc/fb ?
[18:30] <Riddell> alt+f8 doesn't do anything
[18:30] <Riddell> http://kubuntu.pastebin.com/FZr3xVqE  ps shows /etc/gdm/failsafeXServer running
[18:30] <Riddell> sudo chvt 8
[18:30] <Riddell> that hangs
[18:30] <Riddell> when run from ssh
[18:31] <pitti> Riddell: oh, do you have /var/log/Xorg.0.log.old?
[18:31] <Riddell> >cat /proc/fb
[18:31] <Riddell> 0 nouveaufb
[18:31] <Riddell> 1 VGA16 VGA
[18:31] <Riddell> pitti: yes
[18:32] <Riddell> pitti: http://kubuntu.pastebin.com/AVSFNzDZ
[18:32] <pitti> xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call
[18:32] <pitti> hmm
[18:32] <pitti> tseliot, bryceh: do we know whether plymouth/gdm works with nouveau?
[18:37] <pitti> Riddell: so that also used vt 8; it's using vt7 here, but at least it won't get into the way of getty, so that's not it
[18:37] <Keybuk> ok, you're using nouveau
[18:38] <Keybuk> Riddell: how many monitors do you have?
[18:38] <Riddell> Keybuk: 1
[18:38] <Keybuk> just the panel?
[18:39] <Riddell> this computer has a video chip on the motherboard which I think is S3 I don't use, and an nvidia card of some sort which is used
[18:40] <Riddell> i don't know if that answers your question or not
[18:40] <bryceh> pitti, it ought to
[18:41] <bryceh> pitti, I'm helping keybuk debug a nouveau issue on his card on #ubuntu-kernel presently
[18:41] <bryceh> pitti, if you look at the testing results for nouveau while most cards "just work" there are definitely a fair number of cases where things are utterly broken
[18:42] <Keybuk> Riddell: that implies to me that plymouth should be just using the frame buffer
[18:42] <Keybuk> no fancy drm or gem involved
[18:42] <pitti> bryceh: ok, thanks
[18:42] <Keybuk> which is the simplest renderer by far
[18:42] <Keybuk> it should have VT switched back though
[18:43] <Keybuk> could you try booting without kdm for me - how do you get left?
[18:43] <pitti> Keybuk: "xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call" - did you ever see that before?
[18:43] <pitti> it's a bit weird that X dies on such a thing
[18:44] <pitti> -EINTR is the silliest thing in the world, but one would guess that this would have been discovered before
[18:44] <Keybuk> pitti: depends what the signal is
[18:45] <Keybuk> I'm wondering whether this is kdm being badly written
[18:45] <Keybuk> if it daemonises reaaally early
[18:45] <Keybuk> then it could be starting the X server *at the same time* as plymouth is tearing down the console
[18:45] <Keybuk> oh
[18:45] <Keybuk> no
[18:45] <Keybuk> we use starting kdm
[18:45] <Keybuk> hmm
[18:45] <Keybuk> plymouth should be gone
[18:45] <Keybuk> Riddell: yeah, try booting without kdm
[18:45] <Keybuk> where do you end up
[18:46] <Keybuk> at a VT or left with plymouth?
[18:46] <Riddell> Keybuk: on a VT
[18:47] <pitti> so, ./hw/xfree86/os-support/linux/lnx_init.c doesn't do any effort to restart the VT_WAITACTIVE on a signal
[18:48] <pitti> Riddell: does /var/spool/gdm/ exist for you?
[18:49] <pitti> I wonder what part actually creates /var/spool/gdm/force-display-on-active-vt in kdm
[18:49] <pitti> (/var/spool/gdm doesn't exist in Ubuntu, BTW)
[18:51] <Keybuk> pitti: old plymouth/gdm transition code in Fedora only
[18:51] <Keybuk> Riddell: okkk
[18:51] <Keybuk> Riddell: Alt+F7 for me - anything on there?
[18:51] <Riddell> Keybuk: from what state?  frozen splash screen?
[18:52] <Keybuk> Riddell: from the current state - booted, no kdm, on VT1
[18:52] <Keybuk> (I assume you saw some plymouth as you booted?)
[18:53] <pitti> bug 441653  seems similar
[18:53] <ubottu> Launchpad bug 441653 in xserver-xorg-video-ati "xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call" [Undecided,Confirmed] https://launchpad.net/bugs/441653
[18:53] <Riddell> yes plymouth was up
[18:53] <pitti> but that was pre-plymouth (but with kdm)
[18:53] <Riddell> alt+f7 takes me to a terminal saying "init: ureadahead-other main process terminated with status 4"
[18:53] <Keybuk> Riddell: and you can go back to Alt+F1 ?
[18:53] <Riddell> Keybuk: I can go back to alt+f1 yes
[18:53] <Keybuk> Riddell: ok, login
[18:53] <Keybuk> and write the following file
[18:53] <Keybuk> import os
[18:54] <Keybuk> import fcntl
[18:54] <Keybuk> fd = os.open("/dev/tty7", os.O_RDWR)
[18:54] <Sarvatt> pitti: old bug but looks kind of relevant? https://bugzilla.redhat.com/show_bug.cgi?id=323501
[18:54] <ubottu> bugzilla.redhat.com bug 323501 in rhgb "rhgb causes "xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call" on real X startup" [High,Closed: rawhide]
[18:54] <pitti> Keybuk: right, but if /var/spool/gdm wouldn't exist, http://bazaar.launchpad.net/~kubuntu-members/kdebase-workspace/ubuntu/annotate/head:/debian/patches/kubuntu_104_kdm_active_vt_plymouth.diff is a no-op
[18:55] <Keybuk> fcntl.ioctl(fd, 0x4B3A, 0x01)
[18:55] <pitti> Sarvatt: I found that, too, but it's for an "rhgb"
[18:55] <Keybuk> fcntl.ioctl(fd, 0x5606, 0x07)
[18:55] <Keybuk> fcntl.ioctl(fd, 0x5607, 0x07)
[18:55] <Keybuk> --
[18:55] <Keybuk> save that file
[18:55] <Keybuk> run sudo python on it
[18:56] <Keybuk> pitti: welcome to the middle of this conversation <g>
[18:56] <Riddell> Keybuk: screen freezes
[18:57] <Keybuk> just freezes?
[18:57] <Riddell> yep
[18:57] <Riddell> can't change VT
[18:57] <Keybuk> black freeze?
[18:57] <Keybuk> or with that ureadahead message
[18:58] <Riddell> still shows me what was on the terminal before
[18:58] <Keybuk> ok good
[18:58] <Keybuk> ssh back in, change the file
[18:58] <Riddell> sudo prompt
[18:58] <Keybuk> first ioctl -> 0x01 to 0x00
[18:58] <Keybuk> second and third ioctl -> 0x07 to 0x01
[18:58] <Keybuk> then run it again
[18:58] <Riddell> Keybuk: screen unfreezes
[18:59] <Keybuk> I should worry that I know things like that off by heart
[18:59] <Riddell> I am impressed
[18:59] <NCommander> ccheney: ping, we have a revised ARM enablement patch. Can I tempt you to replace the one in ooo-build :-)?
[18:59] <Keybuk> it helps that 0x4B is "K" -> so 4B3A is "K three A" which kinda rhymes
[18:59] <Keybuk> 0x56 is "V" :)
[19:00] <Keybuk> I was very briefly amused by the kernel folks when I discovered that ioctls kinda matched the first letter of the ioctl constant
[19:00] <Keybuk> so ok
[19:00] <Keybuk> this is confusing
[19:02] <Keybuk> without kdm, everything works
[19:02] <Keybuk> plymouth quit restores VT7 back to text mode
[19:02] <Keybuk> and switches the VT back to VT1
[19:02] <Keybuk> this is the *same* plymouth quit that's run "on starting kdm"
[19:03] <Keybuk> but you don't see that with kdm enabled
[19:03] <Keybuk> you get stuck on VT7, which is still in graphics mode, which still has the plymouth output on it
[19:03] <Keybuk> I wondered whether nouveau might have left that there
[19:03] <Keybuk> your Alt+F7 proved it isn't
[19:03] <Keybuk> so I wondered whether nouveau, when you set to KD_GRAPHICS, restores what ever was graphical before
[19:03] <Keybuk> it was a possibility given KMS + GEM (which I've never seen)
[19:03] <Keybuk> those ioctls you did proved that wasn't true
[19:04] <Keybuk> your system wasn't hung
[19:04] <Keybuk> it was just in graphics mode ;)
[19:04] <Keybuk> the second set put it back to KD_TEXT
[19:04] <Keybuk> so
[19:04] <Keybuk> theory?
[19:04] <Keybuk> X is getting started before plymouth has quit?
[19:05] <Keybuk> no idea how that could happen
[19:06] <qense> I've got a patch ready for AppInd integration for Banshee. I have submitted the same patch upstream but it's not sure if it will make it into 1.6.0. Do you think it's worth the trouble to get the patch into our banshee package? It would allow us to expose it to some testing before the final release.
[19:07] <pitti> Keybuk: "on starting kdm", does that mean "before kdm daemon is even started"?
[19:07] <pitti> or "while kdm is starting"?
[19:07] <pitti> i. e. do these two run in parallel?
[19:08] <pitti> if so, would a sleep 5 right before launching kdm (in the upstart job) help to check this theory?
[19:08] <Keybuk> pitti: before
[19:08] <Keybuk> and wait
[19:08] <pitti> ok, so that's not it then
[19:08] <Keybuk> a sleep 5 would be an interesting test
[19:08] <Keybuk> please do try it
[19:08] <Riddell> k
[19:09] <ccheney> NCommander: sure, url?
[19:09] <pitti> Riddell: before you reboot, can you please remove /var/log/Xorg.*, so that after boot we can be sure that if we have two Xorg logs, we really had two X servers starting up?
[19:10]  * ccheney bbia 30m, lunch
[19:10] <pitti> it looks like the first one dies on that -EINTR, then failsafe kicks in, and doesn't work
[19:10] <NCommander> ccheney: http://pastebin.ubuntu.com/395620/
[19:10] <Keybuk> it's strange to me though
[19:10] <Keybuk> because ioctl 0x5607, 0x07 *is* VT_WAITACTIVE
[19:10] <Keybuk> and riddell's python didn't get -EINTR :p
[19:12] <ccheney> NCommander: ok will commit it after lunch
[19:12] <Riddell> added sleep at the start of the script in /etc/init/kdm.conf and no change, plymouth splash gets to 5 orange dots and stays there
[19:12] <pitti> Keybuk: it's X which gets the signal, not kdm
[19:13] <pitti> (and dies)
[19:13] <Riddell> I have both Xorg.0.log and Xorg.failsafe.log
[19:13] <pitti> Riddell: Xorg.0.log has the EINTR again?
[19:13] <Keybuk> interesting
[19:13] <Riddell> pitti: it has xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call
[19:13] <Keybuk> could you add a sleep 5 to plymouth.conf at the bottom of the pre-stop script
[19:13] <pitti> ok, that's consistent then
[19:14] <pitti> Riddell: just for testing I'll monkey-patch Xorg to retry on EINTR (which is the usual approach on that error code)
[19:15] <Keybuk> pitti: I want to know what signal it's getting interrupted by
[19:15] <Keybuk> could we attach gdb to X ? :p
[19:15] <pitti> strace perhaps
[19:16] <tseliot> https://wiki.ubuntu.com/X/Backtracing
[19:16] <Riddell> adding sleep 5 below exec plymouth in plymouth.conf makes no change, 5 orange dots frozen quite still
[19:19] <Keybuk> ok
[19:19] <Keybuk> after that sleep 5 can you add
[19:19] <Keybuk> actually sod it
[19:19] <Keybuk> that's just weird in of itself
[19:19] <Keybuk> ok
[19:19] <Keybuk> before and after the sleep 5 in plymouth pre-stop
[19:19] <Keybuk> touch /var/run/plymouth-pre-stop-before
[19:19] <Keybuk> touch /var/run/plymouth-pre-stop-after
[19:19] <Keybuk> (ie. one before, one after)
[19:19] <Keybuk> then do the same for kdm
[19:20] <Keybuk> touch /var/run/kdm-start-before
[19:20] <Keybuk> touch /var/run/kdm-start-after
[19:20] <Keybuk> either side of the sleep 5
[19:20] <Keybuk> then reboot
[19:20] <Keybuk> ssh in
[19:20] <Keybuk> and stat those four files and stick in pastebin
[19:21] <Riddell> ok
[19:22] <Keybuk> (obviously ssh in to get the stat)
[19:24] <Riddell> Keybuk: http://kubuntu.pastebin.com/rdw9ern0
[19:26] <seb128> bbl
[19:31] <NCommander> ccheney: figure you also might want to know that the latest ooo-build builds fine on lucid with our current config options (at leas ton ARM)
[19:38] <Keybuk> Riddell: so the plymouth ones aren't being run?!
[19:39] <ccheney> NCommander: ok
[19:40] <Riddell> Keybuk: seems so
[19:40] <Keybuk> weird
[19:40] <Keybuk> can you add to plymouth.conf:   post-stop exec touch /var/run/plymouth-stopped
[19:41] <pitti> Riddell, Keybuk: https://edge.launchpad.net/~pitti/+archive/ppa now has an xserver which retries that ioctl on -EINTR; might be worth a try? (it won't tell us yet which signal it gets, that should be done with strace)
[19:41] <ccheney> NCommander: is the patch name still proper? branch_directly_to_cpp_vtable_call_on_arm
[19:42] <NCommander> ccheney: yes, its just revised code that is more stable; the old patch under some cirmstances will corrupt the stack :-/
[19:42] <Keybuk> pitti: it's ok
[19:42] <Keybuk> X is correct, it probably should not retry that
[19:42] <Keybuk> a signal during that signal is a bad thing
[19:42] <Keybuk> well
[19:42] <Keybuk> actually arguably it's not very robust :p
[19:43] <Keybuk> it shoudl recover
[19:43] <pitti> well, like the sleep statements it's another thing to test
[19:43] <Keybuk> but the bug here is not an X one necessarily
[19:43] <pitti> not necessarily a final fix
[19:43] <Keybuk> yeah, I'd like to continue down one line of testing at a time though ;)
[19:43] <pitti> but the problem certainly doesn't get easier with two X servers starting in a row
[19:43] <pitti> Keybuk: sure
[19:43] <ccheney> NCommander: oh ok
[19:43] <pitti> Keybuk: just wanted to mention it, I have a meeting in 15 mins and need to grab a quick bite before
[19:44] <Riddell> Keybuk: that stuff I should add to plymouth.conf is all on one line ?
[19:44] <pitti> Keybuk: and to get a feeling that I contributed a least a tiny bit to the debugging :)
[19:45] <Keybuk> Riddell: yeah all on one line outside of the script blocks
[19:45] <Riddell> Keybuk: http://kubuntu.pastebin.com/GjksHanj
[19:45] <didrocks> pitti: hey o/ the WI wasn't close as it should, changing that now. The other one (forbidding for setting encrypted home user as autologin) should be quickly done, can have a try for next Friday but for beta 2, it's ok :)
[19:46] <Keybuk> Riddell: ok, that's quite interesting
[19:46] <Keybuk> Riddell: could you change the touch to "env > "
[19:46] <Keybuk> ie. dump environment to the plymouth-stopped file
[19:46] <Keybuk> reboot
[19:46] <Keybuk> and cat the file rather than stat it
[19:47]  * Keybuk wonders whether it's a bug that your sleep 5 only slept for 4.46s
[19:48] <pitti> didrocks: thanks
[19:49]  * vuntz wonders whether he should repeat what didrocks told him today or not...
[19:49] <seb128> hey didrocks vuntz
[19:49] <seb128> vuntz, repeat!
[19:49] <didrocks> hey seb128, pitti :-)
[19:49] <didrocks> vuntz: ahah ;)
[19:49] <ccheney> NCommander: i think the info in issue 105359 needs to be updated by i might be wrong
[19:49] <Riddell> Keybuk: http://kubuntu.pastebin.com/R0fRKGp5
[19:49] <seb128> how are the linux solutions this year?
[19:50] <NCommander> ccheney: in the tracker?
[19:50] <NCommander> (OOo bug tracker?)
[19:50] <ccheney> NCommander: yea
[19:50] <Keybuk> Riddell: and definitely nothing in /var/run to do with plymouth?
[19:50] <ccheney> NCommander: lool wrote on it yesterday but no mention of this new patch on it yet
[19:50] <Riddell> Keybuk: only plymouth-stopped
[19:50] <didrocks> seb128: fine, lot of people coming (even if vuntz is there). Good cheese and wine tonight ;-)
[19:50] <vuntz> seb128: he told bad things
[19:50] <Riddell> no sign of /var/run/plymouth-pre-stop-before
[19:51] <didrocks> seb128: but bad network, as every year :-)
[19:51] <Keybuk> Riddell: this vexes me
[19:51] <Keybuk> I am very vexed
[19:51] <Keybuk> could you pastebin the kdm.conf as well, just so my eyes and brain match?
[19:51] <didrocks> vuntz: nobody will trust you anyway :p
[19:51] <seb128> didrocks, ah, food and drinks, I see what you do all day ;-)
[19:52] <didrocks> seb128: only this evening, then, we was flushed out by the security :-)
[19:52] <Riddell> Keybuk: kdm.conf http://kubuntu.pastebin.com/7v7Pnc9c
[19:52] <Keybuk> ok
[19:52] <Keybuk> and the plymouth.conf - could you pastebin that too?
[19:53] <Riddell> Keybuk: plymouth.conf http://kubuntu.pastebin.com/5ZQQjvk3
[19:53] <Keybuk> oh
[19:53] <Keybuk> duh
[19:53] <Keybuk> "exec plymouth quit" -> that should be just "plymouth quit"
[19:53] <Keybuk> sorry
[19:54] <Keybuk> could you try that, then ls -l the /var/run bits for kdm and plymouth - along with the cat of the other file
[19:54] <ccheney> NCommander: i got it checked into the 3-2 branch, just trying to find out how to pull a git commit into head, someone else managed to do it without it being another commit
[19:54] <NCommander> ccheney: no idea :-/
[19:55] <ccheney> NCommander: rene might know how to do it if so he'll probably fix it by tomorrow
[19:55] <ccheney> NCommander: i asked on the ooo-build channel but no response yet
[19:57] <Riddell> Keybuk: umm, my /etc/init/plymouth.conf seems to have emptied itself
[19:57] <Keybuk> http://kubuntu.pastebin.com/5ZQQjvk3
[19:57] <Keybuk> :p
[19:57] <Keybuk> fortunately you put it on the internets
[19:59]  * Riddell installs emacs, enough of this nano toy
[20:02] <Riddell> Keybuk: well KDM starts, no sign of /var/run/plymouth-*  http://kubuntu.pastebin.com/b8zCTcpd
[20:03] <Keybuk> did you modify plymouth.conf ?
[20:03] <Keybuk> to remove the "exec" before plymouth quit ?
[20:03] <Riddell> yes
[20:03] <Keybuk> can you pastebin your plymouth.conf again
[20:04] <Riddell> plymouth.conf http://kubuntu.pastebin.com/HrgdXq67
[20:04] <Riddell> I don't see any splash on start now
[20:16] <Keybuk> sorry
[20:16] <Keybuk> just to confirm
[20:16] <Keybuk> you didn't paste the jr@lichts:~>cat /etc/init/plymouth.conf bit
[20:16] <Keybuk> into your plymouth.conf
[20:16] <Keybuk> ? :p
[20:18] <Riddell> Keybuk: no I didn't
[20:18] <Keybuk> Riddell: edit the file, save it, check syslog
[20:19] <Riddell> Keybuk: I added a new line in /etc/init/plymouth.conf and saved it, syslog has some stuff about [drm] nouveau setting dpms mode
[20:21] <Keybuk> no parse errors from init then?
[20:21] <Riddell> no
[20:21] <Keybuk> huh
[20:21] <Keybuk> it was working fine until the file vanished
[20:21] <Keybuk> :-/
[20:21] <Keybuk> I'm 100% sure I know what's wrong
[20:21] <Keybuk> I just want to do this test to prove it
[20:22] <Keybuk> ah
[20:22] <Keybuk> did any of the other plymouth files empty themselves? :p
[20:22] <Keybuk> like plymouth-splash.conf ?
[20:22] <Riddell> no they all have non-zero size
[20:24] <Keybuk> meh
[20:24] <Keybuk> rebooting doesn't show the splash at all?
[20:24] <Riddell> nope
[20:24] <Keybuk> ok, I guess we give up then
[20:24] <Keybuk> file permissions? directory permissions?
[20:25] <Keybuk> Riddell: in other news, my Fedora spies tell me they've patched kdm to do almost the same thing as gdm ;)
[20:26] <Riddell> I looked at their packaging today and the patch hadn't changed from the one we stole from them months ago
[20:27] <Keybuk> it might be in cvs somewhere?
[20:27] <Keybuk> but yeah
[20:27] <Riddell> http://cvs.fedoraproject.org/viewvc/rpms/kdebase-workspace/devel/kdebase-workspace-4.3.4-kdm_plymouth.patch?revision=1.3&view=markup
[20:27] <Keybuk> I don't know how plymouth has broken for you since you emptied the file
[20:27] <Riddell> Keybuk: /etc/init is 755, /etc/init/* are all 644, all root owned
[20:28] <pitti> Riddell: I still feel this patch is a no-op, though
[20:28] <Riddell> pitti: yes I agree
[20:28] <Keybuk> pitti: nah, I bet your patch fixes it now
[20:29] <Keybuk> now I understand what's happening
[20:29] <Keybuk> the only thing I couldn't see was why those files weren't appearing from pre-stop
[20:29] <Keybuk> and that was because the line before was "exec ..." :p
[20:29] <pitti> ah, heh
[20:31] <pitti> Keybuk: so you know why X gets an unexpected signal now?
[20:31] <Keybuk> well
[20:31] <Keybuk> I know the state of the machine when X starts
[20:31] <Keybuk> the current VT is VT7
[20:31] <Keybuk> that VT is in KD_GRAPHICS mode
[20:31] <Keybuk> I don't know how X is started, but however it is, it clearly isn't happy about that
[20:44] <tseliot> Keybuk: but shouldn't it be in text mode before we start X?
[20:45] <tseliot> and I can fix how X is started
[20:45] <Riddell> kenvandine, chrisccoulson: are either of you doing kubuntu test installs?
[20:45] <Keybuk> tseliot: no, that's what --retain-splash is all about
[20:45] <Keybuk> --retain-splash means "leave the console in a bad state"
[20:46] <tseliot> hehe
[20:46] <tseliot> Keybuk: I'll try to reproduce the gdm behaviour in kdm if I can, so that we can use deactivate instead (after the beta)
[20:53] <kenvandine> Riddell, i have dug up a netbook i can test on
[20:53] <kenvandine> Riddell, found any specific fixes i should test?
[20:54] <Riddell> kenvandine: no but it would be good to have someone else that has the issue should we ever come across a fix
[20:54] <kenvandine> ok, i'll reproduce now
[20:55] <Keybuk> Riddell: it would be nice if you could get back into a state where plymouth at least apparently works
[20:55] <Keybuk> until it kills kdm
[20:55] <Keybuk> since I can't get this nvidia machine to accept KMS
[20:55] <Riddell> Keybuk: I purged and reinstalled plymouth, it now starts and freezes with 5 orange dots
[20:56] <Keybuk> ok, sweet
[20:56] <Keybuk> so can you try something for me
[20:56] <Keybuk> modify plymouth.conf
[20:56] <Keybuk> scroll down to the pre-stop bit
[20:56] <Keybuk> and comment out the line about retaining splash with kdm
[20:56] <Riddell> comment is a hash presumably?
[20:58] <tseliot> yep
[20:58] <Keybuk> yes
[20:58] <Keybuk> that's shell in there
[21:00] <Riddell> Keybuk: plymouth drops to a terminal, a few seconds later KDM starts
[21:01] <Keybuk> and KDM starts normally
[21:01] <Riddell> Keybuk: yes
[21:01] <Keybuk> hurrah
[21:01] <Keybuk> the universe is as it should be ... I am right
[21:01] <Keybuk> ok
[21:01] <Keybuk> put that line back
[21:01] <Keybuk> and try pitti's patched X server
[21:03] <tseliot> lol
[21:07] <Riddell> ran  sudo apt-get install xserver-common xserver-xorg-core  and rebooted
[21:07] <Riddell> plymouth freezes at 5 orange dots
[21:07] <Keybuk> ok
[21:07] <Keybuk> and I guess X is still getting -EINTR ?
[21:07] <pitti> Riddell: what does Xorg.0.log say now?
[21:07] <Keybuk> is it looping continually getting -EINTR?
[21:08] <pitti> or .old (if it's running failsafe now, which ps aux|grep X should tell)
[21:08] <Riddell> Xorg.0.log http://kubuntu.pastebin.com/i3qwjV4m
[21:08] <Riddell> jr@lichts:/var/log>ps aux|grep X
[21:08] <Riddell> jr        1154  0.0  0.0   7544   884 pts/0    S+   21:08   0:00 grep X
[21:09] <Riddell> no X running?
[21:09] <pitti> o_O
[21:09] <pitti> hm, I was just going to ask for an strace to check whether it gets EINTR in a loop
[21:10] <pitti> I didn't test that X server with an EINTR, I just booted it here to see that it still works on a "normal" system
[21:10] <Keybuk> ohhhhhh
[21:10] <Keybuk> I just worked this out
[21:10] <Keybuk> of course it gets -EINTR
[21:10] <Keybuk> the next one will fail EINVAL or something
[21:11] <Keybuk> and then X will give up and exit
[21:11] <Keybuk> Riddell: you know how gdm has a patch pitti wrote so that the first X server is always on vt7, even when plymouth isn't running
[21:11] <Keybuk> you don't have one of those patches, do you? :p
[21:11] <Riddell> no
[21:11] <Riddell> we don't
[21:11] <Keybuk> you always let X pick whatever VT it likes <g>
[21:12] <Keybuk> so you have lots of bugs
[21:12] <Keybuk> you have the "X picked VT1 because getty wasn't using it yet" bug
[21:12] <Keybuk> and, right now
[21:12] <Keybuk> you have "X picked VT8 but can't switch to it, because plymouth set VT7 up for X to takeover, so VT switches aren't allowed right now"
[21:13] <mvo> ccheney: hello, re #516727 -- debian fixed this in their packages, can you please import the fix and upload a new version?
[21:13] <mvo> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570361
[21:13] <ubottu> Debian bug 570361 in openoffice.org-filter-binfilter "aptitude refuses upgrade from 3.1.1-15 to 3.2.0-1" [Serious,Fixed]
[21:13] <mvo> fix is in 1:3.2.0-2
[21:13] <mvo> (and why do I have to find out about this fix?)
[21:14] <tseliot> Keybuk, Riddell: right, that's a patch that I wanted to port to kdm too
[21:14] <Keybuk> NOT A PLYMOUTH BUG
[21:14]  * Keybuk dances around the house singing
[21:14] <tseliot> in fedora they always use tty1
[21:14] <tseliot> hehe
[21:14] <Keybuk> tseliot: in Fedora they kill babies and eat them too
[21:15] <tseliot> hehe
[21:16] <mvo> ccheney: fixed in debian almost 3 weeks ago
[21:16] <tseliot> Riddell: so you have a temporary workaround, right?
[21:16] <Riddell> not as far as I know
[21:16] <Riddell> although commenting out the --retain-splash line seemed to help
[21:17] <tseliot> Keybuk: can't we detect kdm and skip that ^^ ?
[21:17] <Keybuk> tseliot: sure
[21:17] <Riddell> it's only set for KDM :)
[21:17] <Keybuk> but there's a far more serious kdm bug here
[21:17] <Keybuk> you can't just pick the first active VT like that
[21:17] <Keybuk> that'll be vt1 in half the cases
[21:17] <Keybuk> and then kdm will run on the same tty as getty
[21:18] <Keybuk> and they'll steal keypresses from each other
[21:18] <Keybuk> and then getty will get bored, respawn
[21:18] <Keybuk> and X will die
[21:18] <Keybuk> there'll be a funeral and everything
[21:18] <Keybuk> so
[21:18] <Keybuk> it's a bit of luck we didn't go with the "don't seed plymouth" option :p
[21:18] <Keybuk> plymouth was the only thing protecting you from that bug
[21:19] <tseliot> heh, nice
[21:21] <chrisccoulson> hi Riddell, sorry, i went for dinner
[21:21] <chrisccoulson> do you still need me to do a test install?
[21:21] <tseliot> Keybuk: as the nth workaround we can just hardcode tty7 in kdm until the proper fix is in place
[21:21] <Keybuk> tseliot: that breaks multi-user switching
[21:21] <Riddell> chrisccoulson: yes it would be good if you could
[21:22] <pitti> tseliot: that's pretty much what http://bazaar.launchpad.net/%7Eubuntu-desktop/gdm/ubuntu/annotate/head%3A/debian/patches/05_initial_server_on_vt7.patch does
[21:22] <pitti> it's the worst patch evar
[21:22] <pitti> but until today I haven't figured out/got told a better way to do it :(
[21:22] <tseliot> pitti: yes, that's exactly what I had in mind. I remembered that piece of code
[21:23] <rickspencer3> seb128, I have your query in bughugger right now
[21:23] <rickspencer3> do you want me to paste the moin somewhere for you or something>
[21:23] <rickspencer3> ?
[21:24] <seb128> rickspencer3, excellent, I was about to reboot to try something but I'm back in 2 minutes and then yes
[21:24] <seb128> brb
[21:24] <rickspencer3> ok
[21:24] <tseliot> Keybuk, Riddell: would something like that be acceptable for beta1? (please say yes)
[21:24] <rickspencer3> we have 80 Lucid bugs it looks like
[21:25] <Riddell> tseliot: sorry like what?
[21:25] <Keybuk> tseliot: something like the initial_server_on_vt7 patch?
[21:25] <tseliot> Riddell: like the patch that pitti mentioned
[21:25] <tseliot> Keybuk: yep
[21:25] <Riddell> tseliot: yeah if there's a kind and clever soul who can code it in time
[21:26]  * pitti downloads kdm code and has a look
[21:26] <Keybuk> tseliot: that would be very nice indeed
[21:26] <Keybuk> kdm needs that patch anyway
[21:26] <pitti> urgh, it's in kdebase-workspace
[21:27] <tseliot> Riddell: yes, I'll try. Otherwise (if I can't code it in time) we can just ship the workaround in the upstart script and keep our fingers crossed
[21:27] <shtylman_> pitti: yes.. indeed ... enjoy :)
[21:27] <Riddell> tseliot: which workaround in the upstart script?
[21:28] <tseliot> Riddell: commenting out the --retain-splash thing when using kdm
[21:28] <Riddell> right
[21:28] <tseliot> and joining the X funeral every once in a while as a side effect ;)
[21:28] <shtylman_> Riddell: tseliot: I was under the impression that the kdmrc file can tell kdm which vt to use?
[21:28] <pitti> so, I think buildling kdebase-workspace will take some two hours on my box
[21:29] <shtylman_> pitti: you can build just a part of it
[21:29] <tseliot> icore7 FTW
[21:29] <shtylman_> pitti: specifically kdm
[21:29] <pitti> shtylman_: oh, any tricks/
[21:29] <pitti> ?
[21:29] <pitti> that would be very helpful indeed
[21:29] <shtylman_> pitti: yea... use cmake directly
[21:29] <shtylman_> now if you want to make the deb... thats another story
[21:29] <shtylman_> but for plain building.. you can most certainly build only the part you need
[21:29] <pitti> shtylman_: as long as I can run it from the build tree, I don't care about a .deb
[21:29] <shtylman_> pitti: yea.. then you are good
[21:30] <shtylman_> use cmake to make the initial build tree
[21:30] <seb128> re
[21:30] <shtylman_> but stop it before it starts building
[21:30] <pitti> apt is almost done with installing the gazillion build deps
[21:30] <shtylman_> and then just change to the kdm directory (in the build tree) and do make there
[21:30] <shtylman_> it will handle the rest
[21:30] <seb128> ups, still buggy, brb
[21:31] <pitti> shtylman_: how do I invoke that?
[21:32] <TheMuso> Good morning.
[21:32] <Riddell> pitti: you can run debuild then control-C once the cmake configuration is done
[21:32] <pitti> ah, ok
[21:32] <shtylman_> pitti: best bet.. once you have the source... make a directory (i usually call it build) and then cd to that and run: cmake <path to source>
[21:32] <Riddell> then cd obj-<tab>/kdm; make
[21:32] <shtylman_> pitti: or that :)
[21:33] <seb128> re
[21:33] <seb128> rickspencer3, ok, I'm back, sorry about that
[21:34] <rickspencer3> seb128, no problems
[21:34] <rickspencer3> seb128, do you want to try it with bughugger yourself first?
[21:35] <seb128> rickspencer3, sure
[21:36] <rickspencer3> seb128, when it in inevitably crashes or is too confusing, let me know, and I'll paste you the data somehere :/
[21:36] <shtylman_> pitti: let me know how that goes ... I can try testing it tonight on my laptop
[21:36] <seb128> ok, I'm waiting for it to unfreeze from the launchpad handshake right now ;-)
[21:37] <seb128> seems stucked...
[21:37]  * tseliot -> off for the night
[21:40] <seb128> oh, slangasek there ;-)
[21:41] <slangasek> pitti: Riddell tells me you're stuck porting the vt7 patch to kdm?  is that going to get done today?
[21:41] <pitti> slangasek: I'm on it right now
[21:41] <pitti> I'm currently finding my way in the kdm source to see where it starts the server
[21:41] <seb128> rickspencer3, "retrieving release targetted bug_tasks for canonical-desktop-team in lucid", how long does that usually takes?
[21:42] <slangasek> pitti: kdm/backend/server.c :)
[21:42] <pitti> ah, thanks
[21:43] <seb128> rickspencer3, unping, it moved tp retrieving other things
[21:43] <seb128> I'm away for a shower while it's working
[21:43] <rickspencer3> seb128, nooo
[21:43] <rickspencer3> use the json search
[21:43] <rickspencer3> it will literally take hours to search that way
[21:43] <rickspencer3> I mean the way you are doing it
[21:43] <seb128> rickspencer3, I've no clue what json is or how to use that...
[21:44] <rickspencer3> ok
[21:44] <rickspencer3> go search->json searches
[21:44] <rickspencer3> click on desktop team assigned
[21:44] <rickspencer3> then click on the run button above
[21:44] <rickspencer3> this will slurp in the cached results from bdmurray's cron job
[21:45] <seb128> rickspencer3, ooooh
[21:45] <seb128> rickspencer3, ok, I though json would require me to write a json file
[21:45] <seb128> thanks ;-)
[21:46] <seb128> ok, now it makes sense
[21:47] <rickspencer3> sorry seb128, not an inutitive UI
[21:47] <rickspencer3> at least there is no help file to ensure that no else can use it easier
[21:47] <seb128> that's ok
[21:47] <seb128> lol
[21:47] <rickspencer3> this keeps bug reports rather to a trickle
[21:49] <slangasek> pitti: so I'm going to afk now for a bit, since I expect I'm going to be working late into the evening shepherding this through; if you get to a point where you need to drop it and you don't find me on IRC, feel free to call me and I'll take it from there as needed
[21:49] <pitti> slangasek: ok, will do
[21:51] <seb128> robert_ancell, hye
[21:51] <seb128> hey
[21:52] <robert_ancell> seb128, hello
[21:52] <seb128> rickspencer3, ok, the UI sucks but otherwise bughugger is quite handy ;-)
[21:52] <rickspencer3> hehe
[21:52] <rickspencer3> seb128, patches welcome
[21:52]  * rickspencer3 adds seb128 to bughuggers team
[21:53] <seb128> lol
[21:53] <robert_ancell> and assigns him all the bugs
[21:54] <Keybuk> yes, because what we really need is for seb128 to burn out ;-)
[21:54] <seb128> robert_ancell, you wait to be back there!
[21:58] <pitti> Keybuk, Riddell: sorry, what was the reason again why kdm sends the first X to vt8?
[21:58] <pitti> i. e. should we respect that, or force to vt7 on first start?
[21:59] <Keybuk> pitti: first unallocated vt
[21:59] <Keybuk> should be forced to vt7, like gdm is
[21:59] <Keybuk> (for the first server)
[22:00] <pitti> Keybuk: no, I mean kdm launches X with an explicit "vt8"
[22:00] <pitti> gdm doesn't do that (upstream)
[22:00] <Keybuk> oh wow
[22:00] <Keybuk> no idea on that one
[22:00] <rickspencer3> TheMuso, RAOF, robert_ancell, bryceh ... Eastern Edition?
[22:00] <Keybuk> Riddell: ?
[22:00] <TheMuso> rickspencer3: sure lets go
[22:00]  * bryceh waves
[22:01]  * RAOF was born ready!
[22:01] <pitti> Keybuk: ok, I thought it was discussed and I missed it; nevermind
[22:01] <Riddell> I don't know anything about an explicit "vt8", it starts on vt 7 pre-lucid
[22:01] <Keybuk> pitti: I had assumed that X was just picking the first unusued
[22:01] <Keybuk> not that kdm has an explicit vt8
[22:02] <rickspencer3> pitti, Riddell, Keybuk typically at this time we rehash the team meeting for our friends in Sydney and such
[22:02] <rickspencer3> so please excuse us while we flood the channel ;)
[22:02] <pitti> rickspencer3: sorry, will STFU
[22:02] <rickspencer3> TheMuso, robert_ancell, RAOF, bryceh the minutes are here:
[22:02] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-03-16
[22:02] <rickspencer3> pitti, not at all, I didn't mean it that way
[22:03] <rickspencer3> we don't talk too much, so carry on
[22:03] <rickspencer3> ;)
[22:04] <robert_ancell> hehe, didrocks is having fun with seteuid now :)
[22:05]  * TheMuso reads through.
[22:05]  * bryceh caught backlog earlier
[22:05] <didrocks> robert_ancell: "fun" wasn't really the exact word TBH. There is a bug there and I strike on it yesterday for two hours before seb128 told "did you check that seteuid is working?" :)
[22:06] <robert_ancell> didrocks, :)  I'm always suprised how complex low level unix stuff is when you actually try and use it
[22:07] <didrocks> robert_ancell: right, and there is a bug there, but yesterday, it was 11 PM and I was tied to not have think the issue came from there (I was more blaming the gconftool-2 side :))
[22:08] <didrocks> as I'm at a French Linux event on the canonical booth those 3 days, I don't really have the time to check that. I'll see on Friday if nobody's touch it :)
[22:08] <rickspencer3> TheMuso, robert_ancell, RAOF, let me know when you're done looking over the minutes
[22:08]  * TheMuso is done.
[22:08] <robert_ancell> rickspencer3, done
[22:08] <pochu> mvo: heya, are you aware of any application using VteReaper from python-vte, other than gdebi?
[22:09] <RAOF> rickspencer3: Done.
[22:09] <rickspencer3> alright
[22:10] <rickspencer3> I guess we'll touch on some highlights
[22:10] <rickspencer3> looks like the GDM sound patch thingy is underway
[22:10] <rickspencer3> and there's a bit to discuss later about top bugs
[22:12] <rickspencer3> in the partner update there was generally agreement that the Dx team was delivering good stuff, and the weekly releases are quite useful
[22:12] <rickspencer3> should extend that to OLS next release
[22:12] <mvo> pochu: no, I *think* nowdays everything is provided by vte, in the past IIRC the exit-status was missing from python-vtw without the reaper
[22:12] <mvo> pochu: but somone will have to verify
[22:12] <pitti> Keybuk, slangasek, Riddell: ok, seems it's working in my local build tree now; I get the first X to vt7, and subsequent X to vt8 (kdm is pretty insistant on the latter)
[22:13] <Riddell> pitti: cool
[22:13] <rickspencer3> I propose we skip discussing the Kubuntu/KDM bug as it is being worked on in parallel
[22:13] <RAOF> :)
[22:13] <TheMuso> sounds good
[22:13] <pitti> Riddell: are you on amd64 or i386?
[22:13] <rickspencer3> work items
[22:14] <pitti> Riddell: -> #u-devel
[22:14] <rickspencer3> pitti, sorry to keep interupting you guys
[22:14] <rickspencer3> we'll be done in like 2 minutes
[22:14] <rickspencer3> so we're pretty much done our work items
[22:14] <rickspencer3> please look and see if you have any left TODO
[22:15] <rickspencer3> and if so, ensure they are done by the scheduled milestone
[22:15] <rickspencer3> lastly, "Top Bugs"
[22:15] <bryceh> rickspencer3, is the multitouch wi's included in that list?
[22:15] <rickspencer3> bryceh, hmmm
[22:15] <bryceh> or are we handling it separately completely
[22:15] <rickspencer3> prolly should be
[22:15] <rickspencer3> but it should be targetted to beta 2
[22:15]  * bryceh nods
[22:15] <baptistemm_> hi there, if someone could sponsor bug 539914 it fixes corruption issue when sending files to devices
[22:15] <ubottu> Launchpad bug 539914 in obexd "Update to version 0.22" [Undecided,New] https://launchpad.net/bugs/539914
[22:16] <rickspencer3> so, top bugs
[22:16] <rickspencer3> seb128 put quite some work into finding important and actionable issues
[22:16] <rickspencer3> though not release blockers, please pick them off and drive this list to zero
[22:17] <rickspencer3> ok
[22:17] <rickspencer3> that's it
[22:18] <seb128> baptistemm_, there is a meeting right now but please subscribe ubuntu-sponsors so it's in the queue for after beta freeze later
[22:18] <rickspencer3> TheMuso, any audio status?
[22:18] <TheMuso> rickspencer3: Nothing big change wise since last week, just bug fixing and triaging.
[22:18] <rickspencer3> good to hear
[22:18] <rickspencer3> ok
[22:19] <rickspencer3> TheMuso, robert_ancell, RAOF, bryceh any questions or other business?
[22:19] <TheMuso> nope
[22:19] <robert_ancell> rickspencer3, no
[22:19] <RAOF> No.
[22:20] <rickspencer3> bryceh, next week is there some way we could check in on the status of your xorg quality project?
[22:20] <rickspencer3> not sure how you would report on that
[22:20] <rickspencer3> maybe just some impressions in next weak's Eastern edition
[22:20] <ccheney> mvo: ok, will apply the workaround as well with my next upload, it seems in the bug report relating to his change that it can still leave OOo in a broken state but that apparently it couldn't be fixed in aptitude
[22:21] <bryceh> rickspencer3, sure
[22:21] <rickspencer3> thanks bryceh
[22:21] <bryceh> rickspencer3, do you mean quality of X, or status of tools for measuring quality of X?
[22:21] <ccheney> mvo: though he was talking to himself in the comment from some other post that isn't in the comments so not sure what he was talking about exactly
[22:21] <rickspencer3> bryceh, I mean quality of x
[22:21] <bryceh> ok
[22:21] <rickspencer3> the thing you are doing with RAOF and jpeterson and tseliot, etc..
[22:21] <rickspencer3> started in #ubuntu-x
[22:21] <bryceh> right
[22:22] <rickspencer3> I think it will be interesting to people, especially if you escape the mythical man month
[22:22] <bryceh> we had a good meeting today, and have a plan.  I'll summarize how we're doing next week.
[22:22] <rickspencer3> thanks bryceh
[22:22] <mvo> ccheney: ok, thanks. I will add a workaround in u-m for beta-1 so that we do not get too many bugreport
[22:22] <rickspencer3> do you feel that you have the people power to do the right things now?
[22:22] <bryceh> I hope so
[22:22] <bryceh> RAOF took on a pretty large chunk of it
[22:23] <bryceh> and hopefully jpeterson can offload his other tasks sufficiently
[22:23] <baptistemm_> g'dnight
[22:23] <RAOF> We'll see how that goes :)
[22:23] <bryceh> I can now easily measure # of bugs, % uploaded, and so on so we can measure this side pretty well
[22:24] <bryceh> rickspencer3, the question will be if we can get bugs closed
[22:24] <bryceh> we've got some intel freezes I'm curious about, and various people reporting kms trouble on nouveau
[22:24] <bryceh> no surprise there; we knew there'd be lots of regressions on nouveau
[22:24] <rickspencer3> bryceh, well ... I wouldn't want you to spend a ton of time measuring bugs instead of getting them fixed or fixing them, so just impression is fine
[22:24] <bryceh> so just need to get a good stabilization effort moving on that.  raof has a good plan
[22:25] <RAOF> What's been surprising to me is how *few* regressions we've had reported.
[22:25] <rickspencer3> bryceh, there's a fall back position for folks if nouveau doesn't it for them, right?
[22:25] <bryceh> RAOF, yeah, people reluctant to actually file bug reports.  odd
[22:25] <bryceh> rickspencer3, blacklisting can be done but it's a really broad brush
[22:25] <bryceh> rickspencer3, the trouble is this
[22:26] <rickspencer3> I guess I meant they can just switch to -nv or something, right?
[22:26] <bryceh> with UMS we had developed a pretty good set of techniques for debugging X problems
[22:26] <bryceh> we had quirks, lots of docs on wiki.ubuntu.com/X, and tools
[22:26] <bryceh> a lot of this stuff is no longer viable for doing debugging with kms
[22:26] <RAOF> rickspencer3: Passing nomodeset=1 to the kernel will disable kms, which will disable nouveau, which will get you one of {nv, vesa}.
[22:27] <bryceh> some is obsolete, some we just don't have the hooks from the kernel to get the info out or put in stuff to test
[22:27] <bryceh> so this all makes debugging the remaining issues a bit of a tough nut to crack
[22:27] <rickspencer3> bryceh, right
[22:27] <bryceh> but hopefully sending bugs upstream for them to look at will still be a viable tactic
[22:27] <rickspencer3> we'll have to start over with debugging, I guess
[22:27] <bryceh> also the kernel team might be able to lend a hand
[22:28] <bryceh> I will draft up some of my thoughts and email the kernel and x team
[22:28] <bryceh> ultimately I think we need some kernel code written to give better debugging abilities
[22:30] <bryceh> not sure if I answered the question or just frightened everyone away ;-)
[22:30] <rickspencer3> sorry
[22:30] <rickspencer3> lots of questions all over
[22:30] <rickspencer3> bryceh, right, we should look at the intel crash handler work and use that as a model
[22:30] <rickspencer3> imho
[22:31] <pochu> mvo: hmm, I'm not sure I get you. gdebi is still using the VteReaper bindings
[22:31] <rickspencer3> where h = "not humble at all"
[22:31] <pochu> mvo: do you mean vte has other functionality to stop using it?
[22:32] <RAOF> It should be possible to get some similar info out of nouveau, but that'll require upstream code.
[22:32] <didrocks> well, time to go to bed :-)
[22:32] <mvo> pochu: yes, its still using the reaper bindings, but I think nowdays it could stop using them because vte got the needed features. I'm not 100% positive though
[22:33] <didrocks> have a good day/evening/night everyone!
[22:33] <RAOF> didrocks: Goodnight!
[22:34] <didrocks> (not sure to be online tomorrow evening as I'll eat some dinner with evil GNOME devs like vuntz ;))
[22:34] <pochu> mvo: ah ok
[22:34] <RAOF> didrocks: Have fun!
[22:34] <didrocks> thanks RAOF
[22:34] <pochu> mvo: nothing apart from gdebi that you're aware of then?
[22:35] <Riddell> didrocks: give agateau a hug if you see him at the event
[22:36] <mvo> pochu: no
[22:37] <Riddell> rickspencer3: I don't believe I've been introduced to RAOF, could you do so? :)
[22:38] <rickspencer3> hell yeah
[22:38] <rickspencer3> RAOF, meet Riddell
[22:38] <rickspencer3> Riddell, RAOF
[22:38]  * Riddell shakes RAOF by the hand
[22:38] <rickspencer3> RAOF, Riddell is the guy who keeps the Kubuntu plane flying each release
[22:39] <RAOF> Yeah; I've picked up as much :)
[22:39] <rickspencer3> he basically does for Kubuntu what the other 10 of us do for Ubuntu
[22:39] <rickspencer3> ;)
[22:39] <RAOF> Riddell: Hi!
[22:39] <Nafai> Riddell is teh awesome. :)
[22:39] <rickspencer3> Riddell, RAOF is one of the UNE guys
[22:39] <bryceh> *cough* X
[22:39] <rickspencer3> so he'll be 50% UNE, and 50% other stuff, I'm hoping mostly x
[22:39]  * rickspencer3 kicks bryceh under the table
[22:40] <RAOF> Yeah.  There's a fair whack of X in there :)
[22:40] <rickspencer3> but for 10.10, RAOF will be virtual bryceh
[22:40] <Riddell> oh aye, we do UNE now in this team
[22:40] <Riddell> RAOF: are you new to canonical or did you move from another team?
[22:40] <rickspencer3> Riddell, YES!
[22:40] <rickspencer3> weren't you at the distro sprint?
[22:40] <RAOF> New to Canonical, although I've been around Ubuntu quite some time.
[22:41] <rickspencer3> Riddell, oops, I see now you weren't asking a question, silly me
[22:42] <Riddell> RAOF: do you code UNE or get code from DX/UX/whatever they're called and make sure it works?
[22:42] <RAOF> A bit of both.
[22:44] <RAOF> What I've done so far has just been some bugfixes merged in to the netbook-launcher.
[22:45] <RAOF> Mostly it should come in from Dx/Ux
[22:47] <kklimonda> chrisccoulson: gconf support in transmission is only so it can register itself as a default handler for meta: links (sorry for missing your question completely, don't know if that's still a question). I'm pretty sure that doing it this way isn't the right way and I was going to investigate it because debian builds with both libraries disabled. charles is against storing configuration in gconf
[22:47] <kklimonda> because at the moment the same settings.json can be used by all Transmission clients.
[22:47] <Riddell> rickspencer3: is Nafai someone I should get to know too?
[22:48] <chrisccoulson> yeah, gconf is very desktop specific
[22:48]  * pitti waves good night
[22:48] <rickspencer3> Riddell, sure
[22:48] <chrisccoulson> kklimonda, i will review the changes then and make sure they're ok to upload
[22:48] <rickspencer3> night pitti
[22:48] <chrisccoulson> but not tonight ;)
[22:48] <rickspencer3> Riddell, Nafai is working on Indicators for Dx
[22:48] <kklimonda> chrisccoulson: sure, no problem :)
[22:49] <rickspencer3> Riddell, Nafai is current contracting
[22:49] <kklimonda> chrisccoulson: transmission isn't going to use gsettings either because daemon is aiming for small, embedded devices.
[22:49] <vuntz> didrocks: it's on thursday, not tomorrow ;-)
[22:52] <Riddell> pleased to meet you Nafai
[22:52] <Nafai> Nice to meet you too
[22:54] <robert_ancell> RAOF, TheMuso, lunch on Friday?
[22:55] <RAOF> robert_ancell: Sounds good to me.
[22:57] <chrisccoulson> meh, there's nobody around here for me to have lunch with :p
[22:58] <TheMuso> robert_ancell: Sounds good.
[23:00] <seb128> chrisccoulson, how far are you from London?
[23:00] <rickspencer3> chrisccoulson, be careful what you wish for
[23:00] <chrisccoulson> seb128 - quite far (about 2.5 hours drive)
[23:01] <seb128> yeah, too far for a lunch ;-)
[23:01] <seb128> but okish for one or two work day if you ever visit the office
[23:23] <Riddell> chrisccoulson, kenvandine: either of you get Kubuntu installed?
[23:23] <chrisccoulson> Riddell, i've got it installed in kvm at the moment, although it's going a bit slow
[23:24] <chrisccoulson> (my laptop is grinding to a halt in general at the moment though)
[23:41] <kenvandine> Riddell, yup, just came back to it and rebooted
[23:41] <kenvandine> lets see if it boots :)
[23:43] <kenvandine> Riddell, booted fine... and i don't think i even saw plymouth
[23:43] <kenvandine> this is on a netbook with intel graphics
[23:44] <kenvandine> Riddell, logged in and looks very shiny
[23:44] <kenvandine> Riddell, so i can't repro your bug here
[23:48] <Keybuk> Riddell: https://edge.launchpad.net/~scott/+archive/ppa
[23:53] <Riddell> kenvandine: oh well thanks for trying