[00:00] <Keybuk> server glx version string: 1.2
[00:00] <Keybuk> client glx version string: 1.4
[00:00] <Keybuk> GLX version: 1.2
[00:00] <Keybuk> OpenGL version string: 1.4 Mesa 7.7.1
[00:00] <Keybuk> fwiw
[00:01] <RAOF> Ok.
[00:05] <rickspencer3> my count is over 1300
[00:05] <rickspencer3> but it goes up and down
[00:06] <RAOF> Mine is ~2200 but again goes both up and down
[00:08] <Keybuk> at the point mine was ~2200, the bytes counter had overflowed to be negative
[00:08] <rickspencer3> I just played sourbraten, and my byte count and object count both went down
[00:08] <Keybuk> it's certainly not as *bad*
[00:09] <Keybuk> will run it for a few more hours and see if still goes up
[00:09] <rickspencer3> though I don't know for a fact that saurbraten uses glx, I just like it
[00:09] <Keybuk> or maybe it just climbs and plateaus around here
[00:09]  * Keybuk fires up hulu-desktop
[00:15] <rickspencer3> well, first of all, I think I just got paid to play tetris
[00:15] <rickspencer3> second of all, the bytes and object counts seemed similar before and after, though the deallocation was not immediate
[00:15] <asac> hmm. i remember to read something about some i8xx graphics drivers causing problems a few days ago. was that resolved?
[00:16] <rickspencer3> asac, not really
[00:16] <rickspencer3> well, in what sense do you mean "resolved"?
[00:16] <asac> is that the chip a mini 9 might have?
[00:16] <rickspencer3> asac, I would presume the mini 9 has 945, but don't know for sure
[00:16] <RAOF> asac: No; the 8xx chips are old.
[00:17] <asac> well. just wonder if something got blacklisted, because someone complains about a changed UNE experience since a few days ago.
[00:17] <asac> and i thought maybe its because its now falling back to -efl
[00:17] <asac> bug 568096
[00:17] <rickspencer3> ah
[00:17] <asac> bug 568084
[00:17] <asac> bug 568073
[00:17] <asac> i reassigned them to netbook-launcher, but now i realized that a fallback to -efl might cause that confusion
[00:18] <rickspencer3> asac, this is mattgriffin, right?
[00:18] <asac> yes ;)
[00:18] <rickspencer3> I just asked him to do lspci | grep VGA
[00:18] <asac> so its Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)
[00:18] <asac> he pasted it to me now ;)
[00:18] <rickspencer3> asac, yeah
[00:18] <asac> ok so nothing changed on that front i guess?
[00:18] <rickspencer3> no, that is not blacklisted
[00:19] <asac> too bad ;)
[00:19] <rickspencer3> and it is working for me
[00:19] <asac> would be an easy explain
[00:19] <rickspencer3> maybe he just logged into an efi session by accident?
[00:19] <rickspencer3> efl, I mean
[00:20] <asac> yeah maybe :)
[00:20] <asac> asked him
[00:21] <asac> he uses "Session: Ubuntu Netbook Edition" ... so probably not
[00:26] <asac> ok seems he just needed a reboot. maybe his graphics driver was in bad state after upgrade or something. i asked him to come back if he can reproduce this
[00:29] <rickspencer3> asac, yeah
[00:29] <rickspencer3> if there is a problem in our detection code, we'll let didrocks know
[00:29] <rickspencer3> this is the first I have heard of such an issue
[00:29] <asac> right. didnt hear either. lets really see
[00:29] <rickspencer3> I'll chalk it up to to a fluke, but keep my eye on it
[00:30] <rickspencer3> RAOF so my objects and bytes seem to go up and down quite a bit, with no very clear relationship to apps I am running, or when I run them at least
[00:48] <rickspencer3> RAOF, ping
[00:53] <RAOF> rickspencer3: Pong
[00:53] <rickspencer3> RAOF, so, what is your conclusion regarding glx testing?
[00:54] <rickspencer3> is the leak mitigated, fixed, not affected?
[00:56] <RAOF> rickspencer3: The leak is certainly affected by dropping the glx patches; it looks very much like it fixes it.
[00:56] <rickspencer3> ok
[00:56] <rickspencer3> and have you concluded that your "no fonts" issue is or is not impacted by rolling back to glx 1.2?
[00:57] <rickspencer3> RAOF, ^ ?
[00:58] <RAOF> I'm less certain there.
[00:58] <rickspencer3> hmmm
[00:58] <rickspencer3> njpatel thinks that you had a font caching issue
[00:59] <rickspencer3> and that a reboot would fix it
[00:59] <rickspencer3> RAOF, in any case, do you think we should roll back to glx 1.2 for release?
[00:59] <RAOF> The gem testing page has only a single comment from a non-DRI2 driver, which is I think where the problems would be.
[00:59] <rickspencer3> you mean where the corruption that you saw would be?
[01:00] <rickspencer3> RAOF, are you still seeing the problem?
[01:01] <RAOF> Yes, but only with LIBGL_ALWAYS_INDIRECT=1, which could be skewing the results.
[01:01] <rickspencer3> ?
[01:34] <Nafai> rickspencer3: https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/558841/comments/15
[01:44] <rickspencer3> Nice Nafai, keep going!
[01:44] <rickspencer3> really getting there
[01:44] <Nafai> yeah
[01:44] <Nafai> learned a lot the last few days :)
[01:44] <rickspencer3> good
[01:45] <rickspencer3> on the job training ;)
[01:46] <Nafai> definitely.  in this job, I imagine if you aren't getting it at some point, you aren't doing something right :)
[01:46] <rickspencer3> :)
[02:40] <rickspencer3> hi RAOF, bryceh, Sarvatt
[02:41] <RAOF> Yo.
[02:41] <rickspencer3> Looks like on the Gem Leak testing page, someone had an issue with nouveau
[02:41] <rickspencer3> "gem leal" sounds so classy
[02:41] <bryceh> rickspencer3, hey
[02:42] <rickspencer3> hey bryceh
[02:42] <rickspencer3> bryceh, do you have the capability to test nouveau ?
[02:42] <bryceh> were we not expecting it to hit nouveau?  I assumed it was applicable to all open drivers
[02:43] <RAOF> I was rather expecting nouveau's lack of 3D to help it avoid leaks in DRI2 :)
[02:43] <bryceh> ah true
[02:43] <rickspencer3> bryceh, they say they still had the leak *after* applying the PPA
[02:43] <bryceh> oh
[02:43] <rickspencer3> so it could be a regression or such
[02:43] <bryceh> well, it's certainly possible they're seeing some unrelated bug.
[02:44] <rickspencer3> or that
[02:44] <rickspencer3> they are the only ones who reported on nouveau so far
[02:44] <rickspencer3> is there any one else who try to reproduce it?
[02:44] <RAOF> Or that they're using xorg-edgers to get 3D, and the x-updates xserver doesn't have a higher version number than the server in edgers.
[02:44] <bryceh> it's not unusual for when a given bug gets high profile, that people with similar but unrelated issues glom onto it
[02:44] <rickspencer3> bryceh, right
[02:45] <bryceh> heh, this is why I like to always include a ContactInfo column in testing tables like this
[02:45] <rickspencer3> so does someone we know who can give us reliable info have nvidia and can test with nouveau?
[02:45] <RAOF> I'll disable nvidia on my testing laptop and give it a whirl.
[02:45] <rickspencer3> bryceh, they put their name their
[02:45] <rickspencer3> thanks RAOF
[02:46] <rickspencer3> RAOF, can you include those results on the wiki please?
[02:46] <RAOF> rickspencer3: Certainly.
[02:46] <rickspencer3> thanks man
[02:48] <rickspencer3> thanks guys
[02:48] <rickspencer3> if Sarvatt shows up at all, tell him I owe him a beer for sure!
[02:51] <Sarvatt> Ahh I'm here! I was off testing a nouveau machine out and adding my results to the page
[02:51] <Sarvatt> the situation is much better with the PPA xserver on nouveau, clutter apps no longer fail to start entirely like they were before
[02:52] <Sarvatt> bug 561734
[02:53] <RAOF> I should try that with my locally patched xserver, too.
[02:56] <Sarvatt> they wont work, it's only fixed by going back to glx 1.2
[03:01] <RAOF> We could probably fix them by dropping the “backport glx 1.4 to swrast” patch, I'd wager.
[03:12]  * Sarvatt nods
[03:26] <Keybuk> RAOF: just had an X lock-up with the PPA packages
[03:27] <RAOF> I take it this was not a regular occurance pre-PPA? :/
[03:27] <RAOF> Keybuk: Doing anything in particular?
[03:27] <Keybuk> hasn't happened in recent memory pre-PPA
[03:27] <Keybuk> I had clicked a link in chromium
[03:30] <RAOF> Got any logs?  /var/log/Xorg.0.log.old should be the previous log; dmesg can also be instructive.
[03:30] <Keybuk> just checking now
[03:31] <Keybuk> nothing obvious in Xorg.0.log.old
[03:31] <Keybuk> last thing printed is about mode lines
[03:32] <Keybuk> kernl.log has nothing before my Emergency Sync
[03:32] <RAOF> Hm.  Did only X die, dropping you back at gdm, or did everything freeze (or equivalent)
[03:32] <Keybuk> everything froze, only SysRq worked
[03:32] <Keybuk> felt like a pipe underrun
[03:33] <RAOF> You've got an intel card, don't you; 965 from memory?
[03:33] <Keybuk> correct
[03:33] <RAOF> The mouse froze, too?
[03:33] <Keybuk> no
[03:33] <Keybuk> sorry
[03:33] <Keybuk> 945
[03:33] <Keybuk> yes, mouse froze
[03:33] <Keybuk> and couldn't VT switch
[03:34] <RAOF> Ok.
[03:35] <RAOF> I'll look over the patches we dropped in the PPA packages.  I don't think there'll be anything obvious, though :(
[03:35] <Keybuk> 40-xserver-xorg-video-intel.rules:#SUBSYSTEM=="drm", ACTION=="change", ENV{ERROR}=="1", RUN+="/usr/share/apport/apport-gpu-error-intel.py"
[03:35] <Keybuk> is commented out?
[03:36] <Keybuk> upstart/udev logs suggest I had those change events just before reboot
[03:36] <RAOF> Hm.  I thought that i915 would also complain in dmesg when that happened.
[03:37] <RAOF> We disabled that reporting earlier; we'd got lots of data and not much to actually do with it.  It was also hard to assign duplicates.
[03:38] <RAOF> Maybe you could uncomment in the hope that this'll happen again and we'll get some logs
[03:38] <Keybuk> yeah, done that
[03:39] <RAOF> Given that the driver couldn't reset the gpu we'll hopefully get useful logs.
[03:39] <RAOF> You also were still seeing a possible gem objects leak, even with the PPA xserver?
[03:39] <Keybuk> yes
[03:39] <Keybuk> I'm logging the gem_objects file every couple of seconds
[03:39] <Keybuk> and after a few hours usage, will plot
[03:39] <Keybuk> see whether I'm imagining it or not
[03:40] <RAOF> Ok.
[04:00] <Keybuk> so far, it looks like it's just going up and down
[04:00] <Keybuk> and not increasing in any kind of fashion over time
[04:03] <WyGuy> I Am having trouble with my laptop
[04:03] <WyGuy> can anyone help
[04:57] <rickspencer3> Keybuk, you're bumming me out here
[04:57] <rickspencer3> I have i965 and haven't seen issues since like Alpha 1
[04:57] <rickspencer3> I have this dream where I am running, and xorg-xserver is chasing me ..
[04:58] <rickspencer3> but I can never quite run fast enough
[07:22] <pitti> Good morning
[07:27] <RAOF> pitti: Goooood morning
[07:27] <pitti> hey RAOF! how are you?
[07:27] <pitti> https://wiki.ubuntu.com/X/Testing/GEMLeak looks good, no regressions so far
[07:28] <RAOF> Yeah.  And I've managed to convince myself that we're testing the right codepaths, too.
[07:29] <pitti> this *sniff* really makes lucid fun again
[07:29] <pitti> no more 1-minute shutdowns, the weird keyboard behaviour in sudo'ed gnome-terminals has gone, and everthing is fast and snappy again
[07:30] <RAOF> I've also got a package in the (other) x-testing PPA that I'm pretty sure fixes the memory leak without reverting the GLX 1.4 backport.  I'll leave that off the GEMLeak page until we've got more testing of the reverted packages; reverting the GLX patches is safer.
[07:32] <pitti> RAOF: oh, you rock
[07:33] <RAOF> I'm just reading X server code to convince myself that the patch I've picked will work everywhere :)
[07:49] <RAOF> Ok.  I'm off for a walk while it's still light.
[07:58] <ogra> yay, my gem objects count isnt gone negative yet
[07:59] <ogra> looks like a massive improvement
[07:59]  * ogra will monitor it over the rest of the day but getting up and still having a positive value is a good sign
[08:00] <pitti> it's pure ♥
[08:08] <baptistemm> hello
[08:15] <didrocks> good morning
[08:16] <pitti> bonjour didrocks
[08:16] <didrocks> Guten Morgen pitti
[08:21] <dpm> morning all
[08:23] <didrocks> hey dpm
[08:24] <dpm> pitti, I've got a general question on post-release updates and GNOME. Are GNOME .1 releases only packaged and uploaded on a needed basis? I.e. are we going to see some 2.30.1 modules in Lucid?
[08:24] <dpm> heya didrocks, how are you?
[08:26] <pitti> dpm: yes, we'll upload some .1 and .2
[08:27] <pitti> but not all of them
[08:27] <pitti> dpm: and good morning!
[08:28] <dpm> pitti, yes, of course, good morning! :)
[08:28] <dpm> pitti, thanks
[08:42] <seb128> hello there
[08:44] <didrocks> hey seb128 ;)
[08:44] <seb128> lut didrocks
[08:44] <seb128> didrocks, how are you?
[08:45] <pitti> bonjour seb128
[08:45] <didrocks> I'm fine thanks. Still trying to update my book in the evening and a lot of screens to update :/
[08:45] <seb128> pitti, guten tag
[08:45] <pitti> seb128: FYI, the keyring stuff is all sorted and uploaded for final
[08:45] <seb128> pitti, yeah, I was going to hug you for that one
[08:45] <seb128> just reading my bug email, Stef replied to me yesterday
[08:45] <pitti> yes, to me too
[08:45] <seb128> I'm out of internet for some days though so didn't read the reply yesterday
[08:46] <pitti> seb128: oh, your internet connection is broken?
[08:46] <pitti> who am I talking to right now then? ;-)
[08:46] <seb128> changing dsl subscription
[08:46] <seb128> they cut my line but didn't set the new one
[08:47] <pitti> eww
[08:47] <seb128> I'm working from my parents' now
[08:47] <pitti> 3G for the win?
[08:47] <pitti> ah, I see
[08:47] <seb128> going to my parents for the win :p
[08:47] <seb128> they have nice working dsl and space where I can work
[09:28] <mvo> seb128: I just ran into a case where on hardy -> lucid gdm would restart (or get restarted by libc6). not fun, debugging now
[09:30] <seb128> mvo, ok
[09:56] <chrisccoulson> hello everyone
[09:56] <didrocks> hey chrisccoulson
[09:56] <chrisccoulson> hjey didrocks, how are you?
[09:56] <didrocks> chrisccoulson: I'm fine, thanks, you?
[09:57] <chrisccoulson> yeah, i'm not too bad, but i've got a headache for the 3rd day in a row :(
[09:58] <didrocks> urgh, medecines don't help? :/
[09:59] <pitti> hey chrisccoulson; oh, hope you'll get better soon
[09:59] <chrisccoulson> thanks :)
[09:59] <pitti> chrisccoulson: do you have uber-urgent things to do today? perhaps take off some hours, enjoy the sun for a walk?
[10:00] <chrisccoulson> pitti - i need to start looking at updating firefox in hardy
[10:01] <pitti> chrisccoulson: still, that certainly can wait until tomorrow?
[10:01] <huats> morning
[10:01] <chrisccoulson> pitti - yeah, possibly. i'd like to make a bit of a start today though :)
[10:02] <chrisccoulson> i'll probably take a long lunch break ;)
[10:02] <pitti> chrisccoulson: well, your decision of course; just take care of yourself, please ;)
[10:02] <didrocks> hey huats
[10:02] <huats> hello didrocks
[10:03]  * didrocks -> out for an hour. Have to buy some stuffs :)
[10:03] <pitti> mmm, stuffs
[10:04] <didrocks> pitti: birthday present to be precise ;)
[10:04] <pitti> didrocks: ooh, happy birthday! *hug*
[10:04] <didrocks> not for me :-)
[10:04] <pitti> ah, you mean for someone else
[10:05]  * pitti hugs you anyway
[10:05] <didrocks> I don't buy present to myself ;)
[10:05]  * didrocks hugs pitti
[10:05]  * seb128 hugs didrocks
[10:05]  * didrocks hugs seb128
[10:05] <RAOF> Hugs all round!
[10:05] <pitti> didrocks: I sometimes do
[10:05]  * pitti hugs seb128 and RAOF, too
[10:05]  * RAOF hugs all comers
[10:05]  * didrocks hugs RAOF too
[10:05] <didrocks> pitti: oh really? well, that's better than bad surprise :)
[10:06] <pitti> didrocks: well, sometimes I say "I have always wanted this, so let's get it now" :)
[10:06] <chrisccoulson> seb128 - can you recreate the gnome-appearance-properties crash? i couldn't recreate it yesterday to test if my patch works
[10:06] <seb128> chrisccoulson, yes, with the steps I described on the upstream bug, did I give you the upstream bug number?
[10:06] <seb128> https://bugzilla.gnome.org/show_bug.cgi?id=614256
[10:06] <chrisccoulson> seb128 - you did, but i still couldn't make it crash
[10:06] <seb128> chrisccoulson, ^
[10:07] <seb128> well let's say it's crash half of the time
[10:07] <seb128> but I get the valgrind errors almost every time
[10:07] <seb128> chrisccoulson, I'm happy to try your patch there
[10:07] <chrisccoulson> seb128 - please do :) http://paste.ubuntu.com/420307/
[10:08] <chrisccoulson> i found locking issues in a few places which could cause that crash
[10:08] <seb128> how did you found those, I'm just being curious on how to debug such issues
[10:08] <seb128> by reading the code?
[10:09] <seb128> the game is to have all gtk calls in g_t_e g_t_l section?
[10:10] <chrisccoulson> seb128 - yeah, that's basically what you need to do. functions that are triggered from gtk events are already inside the lock though, so it's not as obvious
[10:12] <seb128> (it's building)
[10:21] <seb128> pitti, btw about fast-user-switch-applet will you clean it next time you do cleaning there or should I?
[10:21] <pitti> seb128: oh, please go ahead
[10:22] <seb128> pitti, ok
[10:23] <chrisccoulson> seb128 - if the patch doesn't work, i've found something else to try too
[10:23] <seb128> chrisccoulson, it's rather than the bug doesn't work now
[10:24] <chrisccoulson> heh ;)
[10:24] <seb128> I've no crash on error
[10:24] <seb128> *shrug*, it's always like that when you want to test a change
[10:24] <chrisccoulson> i'll try a bit more here and see if i can make it crash
[10:24] <seb128> I'm building the upstream tarball now just to see if I get it again with this one
[10:25] <seb128> when I opened the bug GNOME bug I was getting the error every time and the crash every second time without valgrind
[10:35] <seb128> chrisccoulson, ok, sorry but I don't get the bug now
[10:35] <seb128> I didn't get it either previous cycles when I tried
[10:35] <chrisccoulson> seb128 - ok, no worries
[10:35] <seb128> it must depends of the lune phases or something
[10:36] <seb128> chrisccoulson, still add your patch to the upstream bug, let get it in .1 if we can and in the first sru round and see if that works for users
[10:37] <vish> seb128: hi.. i think the Bug #493762 was confused for Bug #403691 , 493762 is about the shortcuts in the menu dropdown the "Crtl+A" and those shortcuts... which upstream is implementing in clearlooks , hylke just closed upstream bug since gtk devs didnt like the idea
[10:38] <seb128> vish, ok if you say so, I don't really see the point or care to be honest but if gtk guys said they would not do the change we will not change gtk either
[10:39] <vish> seb128: yup , i was asking before i can mark it invalid instead ;)
[10:39] <seb128> vish, do whatever you think is correct with the bug ;-)
[10:39] <vish> thanks :)
[13:39] <seb128> pitti, I've subscribed you to some gdm locale issues cf LANGUAGE being set because I think you have a clue about that, feel free to ignore those bugs if you don't though
[13:39] <pitti> seb128: thanks, I'll have a look
[13:40] <seb128> pitti, + one crasher svu reported in one of your xkb changes we will want to fix in a sru I think
[13:40] <seb128> pitti, but not hurry for those anyway it's sru material not for lucid now
[13:40] <seb128> pitti, thanks
[13:51] <desrt> *yawn* good morning
[13:51] <seb128> hey desrt!
[13:52] <desrt> seb128: how's the cycle turning out?
[13:52] <desrt> describe your current state of mind:
[13:52] <desrt>  [ ] relaxed
[13:52] <desrt>  [ ] average
[13:52] <desrt>  [ ] omg!
[13:52] <seb128> lol
[13:52] <james_w>  [ ] all of the above
[13:52] <desrt> lol was not an option :p
[13:52] <seb128> I think it's mostly relaxed now ;-)
[13:53] <desrt> oh.  that's good news for this cycle, then :)
[13:53] <seb128> lucid seems mostly good
[13:53] <desrt> really happy to hear that
[13:53] <seb128> still some issues and will be better after some GNOME stable updates and sru updates
[13:53] <seb128> but it's a decent shape
[13:53] <desrt> so i may as well install the release candidate on production machines and just upgrade it when the real one is available?
[13:53] <seb128> yes
[13:53] <desrt> awesome
[13:55]  * desrt finds himself more in [x] omg territory
[13:55] <desrt> seb128: i think you were a little bit too negative about all-of-gnome-porting-to-GSettings
[13:56] <desrt> because judging by the volume of bugs that i'm currently receiving, it feels like that's pretty much what's happening :p
[13:57] <seb128> desrt, you mean too many people doing porting before the thing has settled? ;-)
[13:57] <desrt> i just like to think of it as lots of people porting :)
[13:57] <desrt> the settling won't change much
[13:57] <desrt> backend api only, really
[13:57] <seb128> ok, happy to do that
[13:57] <seb128> I didn't have too much doubt on people being active on porting btw
[13:58] <didrocks> desrt: so, for people waiting to port the backend, they should still wait a little? (looking at the desktopcouch backend)
[13:58] <desrt> didrocks: yes.  definitely.
[13:58] <seb128> I just say there is lot to port and some things will be less trivial and doing everything will let little time for debugging
[13:58] <desrt> didrocks: but uh.. it doesn't really work like that?
[13:58] <desrt> you should really not be writing a backend almost ever
[13:59] <desrt> at least not for the purposes of storing user settings
[13:59] <desrt> seb128: oh btw... about the login settings and default settings and stuff
[13:59] <desrt> g_settings_new_with_context (..., "login-screen");
[13:59] <desrt> or "defaults"
[14:00] <didrocks> desrt: well, rodrigo seemed to be interested (see d-d-l)
[14:17] <rickspencer3> good morning all
[14:18] <desrt> hi rick
[14:18] <rickspencer3> pitti, RC today?
[14:18] <rickspencer3> hi desrt
[14:18] <pitti> good morning rickspencer3
[14:18] <pitti> rickspencer3: yes, looks good; all but one test case done
[14:18] <rickspencer3> good afternoon pitti
[14:18] <rickspencer3> pitti, nice
[14:18] <pitti> and unapproved is huge, time to review/flush it :)
[14:18] <rickspencer3> pitti, GEM Leak?
[14:19] <pitti> rickspencer3: not uploaded yet, but testing feedback is very promising
[14:19] <rickspencer3> good
[14:19] <pitti> some 20 people have tested, and there was only one problem reported by lool which is under investigation
[14:19] <rickspencer3> did anyone figure out Keybuk's issue?
[14:19] <pitti> ?
[14:19] <seb128> hey rickspencer3
[14:19] <rickspencer3> hi seb128
[14:20] <seb128> keybuk's issue?
[14:20] <seb128> we are not on the same timezone that you guys, dunno about this one
[14:20] <rickspencer3> Keybuk was having hideous memory leak and even a freeze
[14:20] <rickspencer3> with his i965
[14:20] <seb128> k, same card there works just great
[14:20] <rickspencer3> which is quite odd
[14:20] <rickspencer3> seb128, right, same with me
[14:21] <ogra> seb128, there are different revs of the 965
[14:21]  * ogra has a rev 03 for example
[14:21] <seb128> ogra, right
[14:21] <seb128> ogra, I was just pointing it's not happening for every intel 965 users
[14:22] <ogra> yeah
[14:22] <ogra> surely not for me
[14:22] <didrocks> hey rickspencer3
[14:22] <pitti> rickspencer3: you mean with ~xup2?
[14:22] <rickspencer3> Hiya didrocks
[14:23] <rickspencer3> pitti, er
[14:23] <rickspencer3> I mean Keybuk installed the PPA, and reports that after that he still has memory leaks, and instability on top of that
[14:23] <pitti> darn
[14:23] <rickspencer3> I asked RAOF to try to get to the bottom of it yesterday, but not sure what the status is
[14:25] <seb128> he got a fixed patch uploaded to the ppa apparently but I guess that's sru material for after lucid?
[14:25] <rickspencer3> pitti, did you see that RAOF has also fixed the leak in the patches?
[14:25] <rickspencer3> seb128, right
[14:25] <pitti> rickspencer3: I did
[14:26] <pitti> I already hugged him for that :)
[14:26] <rickspencer3> I'm thinking that rolling back for release is the safest bet, but then we have RAOF's fix that we can SRU if needed
[14:26] <seb128> rickspencer3, did keybuk reboot or just restarted xorg?
[14:26] <rickspencer3> (assuming Keybuck's issue is a fluke)
[14:26] <rickspencer3> seb128, dunno
[14:27] <seb128> it's a bit hard to have an opinion with the informations we have I guess
[14:27] <rickspencer3> yes
[14:28] <rickspencer3> since RAOF didn't mention Keybuk's issue in his status mail, I am going to be hopefully optimistic ;)
[14:35] <kenvandine> i haven't seen any stability issues and my laptop hasn't gotten slower :)
[14:40] <rickspencer3> kenvandine, are you also i956?
[14:41] <kenvandine> no
[14:41] <kenvandine> GM45 and 945GME
[14:41] <kenvandine> i hadn't noticed it on my netbook actually
[14:41] <kenvandine> but my laptop was noticable
[14:52] <didrocks> james_w: for the issue of having debian/ directory removed at first merge-upstream use, do you prefer existing branch or command to create them? (I've just done a short testcase)
[14:52] <james_w> didrocks: I don't mind
[14:52] <seb128> pitti, you are sure there is nothing in the xorg stack still use libhal for device detection?
[14:52] <didrocks> james_w: ok, filling a bug report now with a testcase so
[14:52] <seb128> bug #558451 collects quite some duplicates, most happening on usb devices disconnection
[14:52] <james_w> if you have minimal commands that is usually more useful
[14:53] <james_w> but knowing real branches can be useful for actually testing that you fixed the whole problem :-)
[14:53] <pitti> seb128: pretty sure, yes; why?
[14:54] <pitti> seb128: perhaps libgnomevfs sets up some monitoring by itself?
[14:55] <seb128> pitti, "why" -> because I don't like gdm crashing it means you loose the running sessions so I would like to figure what is going there but I don't read much from the stacktrace
[14:55] <pitti> seb128: right, I know that "why" :)
[14:55] <pitti> seb128: I didn't see your next IRC comment when I asked
[14:55] <seb128> ok ;-)
[14:55] <pitti> gdm has no hal code whatsoever
[14:56] <pitti> sudo dpkg -P libhal1 -> that's just 5 remaining deps on my system
[14:56] <seb128> pitti, I'm wondering if we can consider that there is 2 issues there, one being libhal being used for some reason, one being that it crashes
[14:56] <pitti> libgnomevfs2-0, libgnome-pilot2, gimp, and hal itself
[14:56] <seb128> http://launchpadlibrarian.net/43235039/gdb-gdm-session-worker.txt
[14:56] <pitti> seb128: the first is quite clear though -- gdm needs to stop using libgnome
[14:57] <seb128> pitti,
[14:57] <seb128> $ ldd /usr/lib/gdm/gdm-session-worker | grep libgnome
[14:57] <seb128> $
[14:57] <pitti> it doesn't look like a call, but like a dbus signal callback?
[14:58] <seb128> pitti, right, my gut feeling is that the issue is with something xorg input detection code
[14:58] <seb128> "gdm crashed while installing virtualbox-ose packages"
[14:58] <seb128> is the description on this bug
[14:58] <seb128> virtualbox-ose?
[14:58] <pitti> seb128: hm, g-s-w doesn't link against hal either
[14:58] <pitti> weird
[14:59] <pitti> how could it ever crash in libhal then?
[14:59] <pitti> seb128: sorry, have a confcall now, bbl
[14:59] <seb128> as said the stacktrace makes no sense to me
[14:59] <seb128> pitti, no need to be sorry, thanks for the quick chat that was useful ;-)
[14:59] <pitti> ok, so it's a mystery
[15:00] <seb128> I will try to see if there is a common pattern between those bugs
[15:00] <seb128> like using all virtualbox or something
[15:06] <chrisccoulson> seb128 / pitti - it is pam_usb.so which is using HAL
[15:06] <chrisccoulson> http://launchpadlibrarian.net/43439314/ProcMaps.txt
[15:06] <seb128> chrisccoulson, what would we do without you
[15:06] <chrisccoulson> (i don't even have that on my system)
[15:07] <chrisccoulson> heh ;)
[15:07] <seb128> me neither
[15:07] <seb128> libpam-usb
[15:07] <chrisccoulson> yeah, that does seem to pull in libhal1
[15:09] <seb128> chrisccoulson, thanks, reassigning there
[15:10] <seb128> chrisccoulson, thanks a lot ;-)
[15:11] <didrocks> james_w: bug #568440, tell me if I need to push a branch or not :)
[15:11] <james_w> didrocks: thanks, I'll take a look
[15:14] <chrisccoulson> seb128 - you're welcome :)
[15:14] <james_w> didrocks: that should be sufficient for investigation, thanks. And sorry for not believing you :-
[15:14] <james_w> )
[15:16] <didrocks> james_w: no pb, sorry for being so long to give you a good and easy testcase :)
[15:16] <chrisccoulson> hmmm, is there any way of telling an application at runtime to load its gtkbuilder UI files from somewhere else?
[15:18] <seb128> chrisccoulson, I think g-c-c has hacks for that
[15:19] <seb128>     if (g_file_test (GNOMECC_UI_DIR "/gnome-default-applications-properties.ui", G_FILE_TEST_EXISTS) != FALSE) {
[15:19] <seb128>         builder_result = gtk_builder_add_from_file (builder, GNOMECC_UI_DIR "/gnome-default-applications-properties.ui", NULL);
[15:19] <seb128>     }
[15:19] <seb128>     else {
[15:19] <seb128>         builder_result = gtk_builder_add_from_file (builder, "./gnome-default-applications-properties.ui", NULL);
[15:19] <seb128> chrisccoulson, ^
[15:19] <chrisccoulson> seb128 - thanks, will look at that
[15:20] <seb128> I guess if that's for local hacking you can just hack the gtk_builder_add_from_file call
[15:22] <chrisccoulson> yeah, i think hacking the gtk_builder_add_from_file call will be easiest for now
[15:25] <chrisccoulson> cool, my locking changes don'e seem to have broken anything anyway
[16:00] <pitti> re
[16:00] <pitti> chrisccoulson: pam_usb??
[16:00] <chrisccoulson> hey pitti
[16:01] <pitti> ok, that explains it, thanks a lot!
[16:01] <pitti> sounds like a cool package, but hal??
[16:26] <Nafai> Good morning #ubuntu-desktop!
[16:30] <kenvandine> hey nafa
[16:30] <kenvandine> hey Nafai
[16:32] <qense> I got a bug report against Nautilus Actions complaining that you cannot press "Choose" if you want to pick the directory you're currently in. Is that an issue with the way nautilus-actions uses the file chooser, or is it a problem with the file chooser?
[16:35] <seb128> qense, what ubuntu version?
[16:35] <seb128> qense, this issue should be fixed in lucid gtk
[16:35] <qense> seb128: lucid, nautilus-actions is 2.30.2
[16:35] <seb128> ok so I don't know
[16:35] <seb128> it works now in file-roller for example
[16:36] <seb128> would need a code example to know about your particular case
[16:36] <seb128> Nafai, kenvandine: hey
[16:36] <qense> All I can give you is the bug number: bug 568014
[16:36] <qense> I'll take a look in the code myself.
[16:36] <Nafai> Hi kenvandine, seb128
[16:37] <seb128> qense, ok thanks
[16:39] <didrocks> hey kenvandine, Nafai
[16:41] <qense> seb128: The file chooser is defined in the UI file at <http://git.gnome.org/browse/nautilus-actions/tree/src/nact/nact-assistant-export.ui>, if you're interested. I read <http://git.gnome.org/browse/nautilus-actions/tree/src/nact/nact-assistant-export.c> quickly and it seems that the code only searches the selection.
[16:43] <didrocks> pitti: now that RC is out, do we consider the poppler change for final or as an SRU?
[16:43] <pitti> didrocks: "the poppler change"?
[16:44] <didrocks> pitti: we discussed it at the beginning of the week: bug #33288
[16:47] <seb128> didrocks, sru
[16:47] <seb128> it doesn't seem anything important for lucid CDs and is non trivial change
[16:47] <didrocks> seb128: ok, I'll push it to -proposed
[16:47] <seb128> it requires testing and not rushing
[16:47] <seb128> thanks
[16:47] <didrocks> thanks :)
[16:49] <pitti> didrocks: ugh, http://launchpadlibrarian.net/39815138/rough_poppler_0.12.4-0ubuntu1.1.debdiff ?
[16:49] <pitti> didrocks: yes, SRU please
[16:49] <pitti> wow, a 5-digit bug
[16:50] <didrocks> pitti: I've a slightely different version that I backed out some days before (see comments), but yeah, it's quite huge
[16:51] <didrocks> and yeah, closing a 5-digit bug is good for the mind :)
[16:52] <chrisccoulson> mclasen - there?
[17:00] <seb128> pitti, bug #559847, do you think it's worth getting in your gdm sru if you get the other xsession include change too?
[17:00] <didrocks> Xreset.d?
[17:02] <pitti> seb128: looks easy enough, although it smells a bit FFish
[17:02] <seb128> didrocks, read the bug?
[17:02] <didrocks> seb128: reading, but LP was slow to draw the page :)
[17:03] <didrocks> didn't know about that trick :)
[17:05] <seb128> chrisccoulson, I think you should just add your patch upstream with the open question, mclasen doesn't maintain g-c-c anyway so he will probably not decide on it
[17:06] <seb128> I'm not sure why it could not been done in an g_idle though
[17:06] <seb128> seems easier to do that fighting with getting lock right
[17:06] <jcastro> seb128, kenvandine: sometime early in M can we have someone look at the original Tomboy patch for app indicators and make sure it works, clean it up, etc. I would like to resubmit that upstream early.
[17:06] <jcastro> qense, you might be interested in this ^^
[17:06] <seb128> jcastro, sure, seems a job for whoever worked on the change or talked to upstream, who was that?
[17:07] <kenvandine> jcastro, yeah... I think it is more up to the DX guys
[17:07] <jcastro> seb128, DBO iirc.
[17:07] <kenvandine> jcastro, like supporting the pins?
[17:07] <kenvandine> yeah, DBO did it
[17:07] <jcastro> but maybe qense might be able to help?
[17:07] <kenvandine> i worked on it too
[17:07] <jcastro> this would make him 3 for 3!
[17:07] <kenvandine> jcastro, wasn't the hold up supporting the pins?
[17:07] <qense> jcastro: It sounds like a good idea to make the applications that couldn't use the indicators this cycle use it very early in the Maverick cycle so we can improve them and get them perfect.
[17:08] <qense> kenvandine, jcastro: indeed it was
[17:08] <seb128> kenvandine, I doubt dxteam will have time for application changes though
[17:08] <jcastro> kenvandine, also, I talked to sandy and he's cool with us putting it in maverick as is so we can try it.
[17:08] <kenvandine> seb128, but to support some notion of pinning
[17:08] <jcastro> qense, yep
[17:08] <seb128> kenvandine, they will be busy enough on the stack and on the new indicators
[17:08] <kenvandine> seb128, ido will need changes
[17:08] <seb128> right, that's the stack
[17:08] <kenvandine> seb128, indeed... but this might be related
[17:08] <jcastro> kenvandine, what I was thinking is get it in very early, and then see how we feel about the non-pins.
[17:08] <kenvandine> we need to find out their plans
[17:09] <chrisccoulson> seb128 - yeah, i'll add the patch that i have so far, but i could probably keep going forever ;)
[17:09] <kenvandine> jcastro, i am actually ok without the pins :)
[17:09] <seb128> well jcastro seems to want to get what we had re-submitted
[17:09] <qense> I could help with Tomboy, I'm one of the few people that ever worked with the C# bindings for AppInd, so I've got some experience.
[17:09] <seb128> not to get pins done
[17:09] <chrisccoulson> the IO is done in a thread so the UI stays responsive
[17:09] <chrisccoulson> but it's weird that the progress dialog is updated from the IO thread
[17:09] <chrisccoulson> anyway, i'll put that to one side for now
[17:09] <seb128> chrisccoulson, right
[17:10] <jcastro> kenvandine, right, I am ok without the pins too. If we get it in early we'll know for sure if we care about pins or not.
[17:10] <seb128> chrisccoulson, seems reasonable, thanks for looking at it
[17:10] <qense> Aren't the pins just checkboxes with a fancy icon?
[17:10] <kenvandine> jcastro, but didn't sandy say he wouldn't take the patch without it?
[17:10] <kenvandine> qense, essentially, yes
[17:10] <jcastro> kenvandine, all we need to ensure is that it falls back for systems without the app indicators
[17:10]  * Nafai is a smart alec: http://twitter.com/travisbhartwell/status/12647279520
[17:10] <jcastro> kenvandine, initially, but this is my second try
[17:10] <kenvandine> Nafai, long walk :)
[17:10] <qense> jcastro: For that I would have to get the fallbacks working properly in C#.
[17:11] <Nafai> kenvandine: indeed :)
[17:11] <kenvandine> jcastro, ok, well i am fine with getting it back into M :)
[17:11] <chrisccoulson> lol @ Nafai
[17:11] <jcastro> kenvandine, and what I want to say is "ken and I thought we would miss the pins, but you know what, it's so much better this way."
[17:11] <qense> That could get tricky, but I've still got a branch somewhere on my system with a start of a fix for that.
[17:11] <jcastro> kenvandine, good with the bad, etc.
[17:11] <kenvandine> jcastro, indeed... at first i was annoyed without the pins
[17:11] <jcastro> qense, ok, so for M we need to prioritize c# fallbacks. We'll bring that up at UDS.
[17:12] <kenvandine> brb... i am trying to figure out why suspend isn't working here... sick of not being able to sleep the laptop!
[17:12] <jcastro> kenvandine, if it ends up everyone misses the pins then we just go back to lucid behavior. I want to try though.
[17:12] <qense> jcastro: There are two problems: GAPI in the current GTK# is incomplete, lacking the essential virtual method support, and the way the library swaps strings and enums around breaks the bindings.
[17:12] <jcastro> and if people love the pins it will force us to look at other ways of solving Tomboy's problem
[17:13] <qense> jcastro: Would using checkboxes instead of the pins be acceptable?
[17:14] <jcastro> I think we should holistically look at the entire workflow for using tomboy
[17:14] <qense> I would find that a bit unclear.
[17:14] <seb128> kenvandine, what laptop model do you have?
[17:14] <qense> We could, but isn't the way Tomboy works more something for the Tomboy team? ;)
[17:14] <jcastro> qense, yeah but we can help them there I think.
[17:14] <seb128> kenvandine, dell studio?
[17:15] <jcastro> qense, the onus will be on me to communicate that with sandy.
[17:16] <qense> jcastro: Fortunately you're good at communicating with upstreams -- you've already infiltrated the GNOME board! -- so that'll probably work out just fine.
[17:16] <qense> I just don't think we should spend talking half the AppInd session about Tomboy. :)
[17:21] <arand> didrocks: In the debdiff for Bug #33288 there's a lot of comment gtk-doc version changes, since not mentioned in the changelog, is that proper for a SRU?
[17:22] <didrocks> arand: hum, let me check, maybe building the package generated it without I noticed
[17:23] <didrocks> arand: argh, bummer, building the package build the doc and the clean rule doesn't clean it
[17:23] <didrocks> so, reject the package to -proposed so that I can reupload a clean one
[17:24] <arand> didrocks: Um, I'm not an SRU/reviewer.
[17:25] <arand> didrocks: Just peeked at the debdiff since I follow the bug (the earlier proposed debdiffs were mine).
[17:26] <didrocks> arand: oh ok, and you cleaned the gtk-doc each time? that should be something we fix in debian/rules itself and see if upstream can ship and uptodate doc package. Well in any case, fixing it now
[17:27] <arand> didrocks: I don't think I did anything in particular, I did the patches (many in my case), dch -i and debuild -S...
[17:28] <didrocks> arand: yeah, but you didn't debuild (without -S) to build it, right?
[17:29] <arand> didrocks: Nope, I tested that in pbuilder... Hmm let's see...
[17:30] <seb128> didrocks, I tend to not double build things but build, rm and dpkg-source -x
[17:30] <seb128> didrocks, you often get noise in the diff.gz otherwise
[17:30] <seb128> didrocks, or get the debian dir in bzr and bzr-buildpackage ;-)
[17:31] <didrocks> seb128: oh, really? so, even for anything not in bzr, you debuild, copy your change elsewhere ; rm ; push back your changes and debuild -S ?
[17:31] <arand> didrocks: what pbuilder spat out seems to also have nothing but the changelog and patch in the debdiff..
[17:31] <seb128> didrocks, why copying?
[17:32] <seb128> didrocks, debuild does create the diff.gz and .dsc
[17:32] <seb128> didrocks, I just dpkg-source -x *.dsc
[17:32] <seb128> rm and dpkg-source
[17:33] <didrocks> seb128: oh ok, I'm so used to debuild -S :)
[17:33] <didrocks> arand: well, strange, maybe it's conditionnaly triggered if you have gnome-doc-utils or gtk-doc-tools as I've on my laptop
[17:33] <seb128> didrocks, I agree that non buggy clean target is better though so feel free to fix such bugs ;-)
[17:34] <didrocks> seb128: yeah, I added that on my TODO :)
[17:34] <didrocks> seb128: can you reject a package from -proposed so that I can upload a clean one,
[17:34] <didrocks> ?
[17:35] <seb128> didrocks, I prefer to let the sru team do that
[17:35] <seb128> well I probably can yes, let me have a look
[17:36] <didrocks> so that I can repush without annoying more people :)
[17:37] <seb128> didrocks, done, let me know if you receive the rejected email
[17:37] <didrocks> seb128: I confirm you have the power :)
[17:37] <didrocks> seb128: rock, pushing the new one now. rock ;)
[17:37] <didrocks> arand: thanks for the notice!
[17:38] <arand> didrocks: Glad to help :)
[17:38] <arand> didrocks: btw, I tried installing t pbuilder spat out seems to also have nothing but
[17:39] <didrocks> arand: "it" being gtk-doc-tools and gnome-doc-utils?
[17:40] <arand> didrocks: btw, I tried installing gtk-doc-tools, and from the debuild -S I still seem to get a clean debdiff...
[17:41] <arand> Yea, misspaste there, bothering that middle-mouse-paste doesn't work through virtual machines...
[17:41] <didrocks> arand: yeah, as told previously, I runned debuild first
[17:41] <didrocks> (not debuild -S)
[17:42] <arand> didrocks: ah, right, yea, misread that...
[17:52] <fredp> tedg: hi! I was reading the lwn article on appindicators (<http://lwn.net/Articles/384274/>) and was reminded of <http://mail.gnome.org/archives/desktop-devel-list/2010-February/msg00051.html>, did you get feedback from gnome-shell developers?  (the thing is the release team meets in ~2 weeks and that's most certainly a blocker, so any update would be welcomed)
[17:53] <tedg> fredp: Nope, they've been silent on the issue.
[17:56] <fredp> (mmm, not really a surprise), so I think you should engage them into a discussion, I don't know of difficult would be to add a proof of concept "appindicator area" in javascript, but it sure would be nice.
[17:57] <fredp> (and I do realize the ubuntu calendar makes it hard to concentrate on this right now :/ )
[17:57] <kenvandine> seb128, T400
[17:57] <kenvandine> suspend works from gdm, but not from a logged in session
[17:57] <kenvandine> it appears to be network related
[17:58] <seb128> ok
[17:58] <kenvandine> pm-suspend.log  says suspend worked, but the sleep light keeps blinking
[17:59] <kenvandine> works fine from in gdm though... so it is something that gets setup at login
[18:00] <kenvandine> apw spent a bunch of time messing with it a while back with no luck
[18:00] <fredp> tedg: ^^^
[18:01] <tedg> fredp: Heh, I think that *you* should engage them in a conversation :)
[18:03] <fredp> tedg: that's politics, and hard :)
[18:03]  * Nafai lunches a little early today
[18:06] <tedg> fredp: And it's not a fight I want to have.  I posed it to the desktop list, and then got flamed by every redhat employee on the list.  It's no fun.
[18:07] <pitti> I'm off for an hour, back later
[18:10] <mclasen> fredp: in what way do you think it is a blocker ?
[18:10] <fredp> mclasen: it's a blocker for considering libappindicator as an acceptable external dep.
[18:11] <mclasen> tedg: you did not get flamed. you got some initial api review, and then you retracted into your cave...
[18:12] <fredp> and as I see how similar some goals are, in appindicator and gnome-shell status zone, I'd like to see people working together.
[18:12] <tedg> mclasen: Hmm, I guess we have different impressions of what happened then.  Perhaps it depends on which side you were on.
[18:12] <mclasen> tedg: might well be. in either case, it is pretty clear by now that you are intent on doing your own thing...
[18:15] <tedg> mclasen: Sure, whatever.  The way it was setup is that by doing nothing, it would be rejected.  So of course, nothing was done.  Which would always be the case when that's how the decisions was set up.
[18:16] <mclasen> tedg: you mean you set it up that way by not following up  ?
[18:16] <mclasen> thats certainly the impression I got...
[18:16] <fredp> bye.
[18:17] <tedg> mclasen: What e-mail wasn't followed up on?  The only question was to use GtkActions, which I'm perfectly happy to do, and said as much.
[18:17] <tedg> mclasen: But, at the time, is also after API freeze...
[19:29]  * kenvandine -> lunch
[19:45] <pitti> re
[19:48]  * didrocks goes off after dinner, Julie's birthday anniversary, don't want to work this evening :)
[19:55] <pitti> seb128: http://ddebs.ubuntu.com/pool/main/g/glib2.0/ *grin*
[20:06] <seb128> didrocks, enjoy!
[20:06] <didrocks> seb128: thanks (yeah, still triaging bug mails ;))
[20:06] <seb128> didrocks, joyeux anniversaire de ma part également
[20:07] <seb128> pitti, don't go to oem, we need you there ;-)
[20:07]  * seb128 hugs pitti
[20:07] <didrocks> seb128: je transmets, elle te dit "merci même si je te connais pas" :)
[20:07] <didrocks> (x2) ;)
[20:07] <seb128> lol
[20:07]  * pitti hugs back seb128 and bows to the new tech lead
[20:08] <seb128> I still have to figure if that techlead thing is good curse ;-)
[20:24] <Nafai> yawns
[20:24] <bryceh> Nafai, morning
[20:25] <Nafai> Hey :)  Afternoon here.  Just woke up from my customary lunch-time nap.  Wish I would stop having insomnia at night
[21:05] <pitti> good night everyone
[21:06] <seb128> you too pitti!
[21:17] <seb128> pedro_, hey
[21:18] <pedro_> seb128, hey hey
[21:18] <seb128> pedro_, btw fast-user-switch-applet got dropped from lucid since it doesn't work with the new gdm and is replaced by the gdm one and indicator-session
[21:18] <seb128> pedro_, not sure if you have tools to clean bugs on such cases or just let those open in launchpad
[21:22] <pedro_> seb128, ok, well ~70 bugs open is not too much so i'll clean that. Better to give a response to the reporters instead of leaving those just laying around
[21:22] <pedro_> seb128, thanks for the info ;-)
[21:24] <seb128> pedro_, you're welcome, thanks
[21:29] <dobey> hey seb
[21:31] <seb128> hey dobey
[21:32] <dobey> seb128: can you answer anything about dev membership application process, or should i find someone else to bug?
[21:33] <seb128> dobey, you should better try with dholbach or persia I guess
[21:33] <dobey> seb128: ok, thanks
[21:33] <seb128> I've not been following what happens there closely
[21:33] <seb128> np
[21:34] <dobey> ok. i know there were some changes to the process, and reading the wiki is confusing me, so i wanted to poke for some clarification :)
[22:12] <bryceh> seb128, you moved 566683 to xorg-server but this is not correct
[22:12] <bryceh> seb128, with kernel modesetting, resolution and output selection is done by the kernel, not X any longer
[22:12] <bryceh> seb128, so all these types of bugs you should be assigning to linux, not X
[22:13] <rickspencer3> bryceh, you don't have to sound so happy about that ;)
[22:13] <bryceh> rickspencer3, heh
[22:13] <seb128> bryceh, oh ok, thanks for letting me know, I usually try to move those one steps closer from where the issue is but I don't know enough the graphical stack to aim right ;-)
[22:13] <seb128> bryceh, but noted for next time
[22:13] <bryceh> seb128, thanks
[22:13] <seb128> I guess it's the same when people reassign the other way and know xorg and not GNOME
[22:14] <seb128> they pick a random source ;-)
[22:14] <bryceh> yeah with our move to KMS, 90% of X issues being reported really are kernel drm bugs, so it seems we've turned into launchpad ping pong players ;-)
[22:14] <bryceh> seb128, yeah it's true
[22:15] <seb128> I was a bit happier about bugs being assigned to xorg to be honest :p
[22:15] <seb128> at least those get replies
[22:15] <seb128> I never get any reply on the linux bugs I file usually
[22:15] <seb128> it feels like pushing those to null
[22:17] <bryceh> I suppose that's kind of a compliment
[22:17] <seb128> it is ;-)
[22:17] <bryceh> well I do try to handle even bugs that are kernel bugs if I'm not 100% sure, and then hand them over when there's a patch available
[22:19] <bryceh> however with how limited our X manpower is, seems better to focus on issues that really are in X components
[22:25] <seb128> bryceh, oh sure, I just wish the kernel team was responsive on some issues sometime but I guess they have the same manpower issue than every team there
[22:26] <bryceh> yep
[22:26] <bryceh> seb128, if it's an issue you think should get prioritization, what I've been doing is ping JFo, which seems to work effectively
[22:27] <seb128> thanks for the hint, I don't have a specific issue right know but it's good to know ;-)
[22:28] <bryceh> seb128, I just wish we didn't get so many bug reports in general.  Makes it hard to think.  Some days I feel like I'm just looking at bug report after bug report without finding any that I can actually *do* something about
[22:29] <bryceh> seb128, btw are you able to convert bug reports into questions in launchpad?  Lately when I've tried it I just get launchpad OOPSes
[22:29] <seb128> bryceh, I did convert some today yes
[22:29] <bryceh> hmm
[22:30] <bryceh> will have to try again
[22:30] <seb128> I spent 2 days doing bug reading and cleaning now
[22:30] <bryceh> seb128, have you ever looked into if bugs put to answers actually get adequate follow up?
[22:30] <seb128> I need a break tomorrow, I will do some sru for a change ;-)
[22:31] <seb128> bryceh, no, I tend to use the "convert to question" when the bug are "things are not working, can you explain what to do"
[22:31] <seb128> I've enough bugs I don't follow up on already, I can't be bothered to know if questions get answered or not, would be interesting to know but I can't help triaging those
[22:32] <bryceh> I don't know if it's the same in gnome, but with X we get a *ton* of bug reports which really aren't high enough quality to be able to work on easily, but are probably really a bug somewhere, but the user needs a lot of handholding in order to make a proper bug report about it.  So I have wondered if sending to answers would accomplish that or if it'd just be dumping the bug
[22:32] <seb128> I think it's mostly dumping the bug
[22:32] <bryceh> mm
[22:32] <seb128> but my view is that if the bug is a common on or an another one if will come as a proper bug soon enough
[22:33] <bryceh> ok, probably better to just close bugs as invalid then with directions on how to make better bug reports
[22:33] <seb128> common one
[22:33] <seb128> we can't deal with every weird issue happening to one user anyway
[22:33] <bryceh> yeah
[22:34] <seb128> well closing as invalid tend to create conflicts with some users who don't agree their issue is invalid
[22:34] <seb128> at least converting to a question avoid that and let a chance for somebody on the answer tracker to pick the case
[22:34] <seb128> I guess most don't get far but at least some users get help there
[22:35] <bryceh> hmm, interesting
[22:35] <bryceh> probably easier for peer-help on gnome bugs than on X though
[22:35] <bryceh> but might be worth experimenting with
[22:38] <seb128> well at least you have proper documentation so you can close bugs with an url to how to open a proper bug
[22:38] <seb128> you = xorg team
[22:38]  * bryceh nods
[22:38] <seb128> we should try to get that but it's harder for GNOME, too many different components
[22:39] <seb128> it's nice that we have ubuntu-bug symptoms now though
[22:40] <seb128> we can at least close the "I don't get sound" bugs opened on totem or rhythmbox with a "could you run ubuntu-bug audio and open a new bug using it"
[22:40] <bryceh> seb128, have you found many people use that to report bugs?  I've not seen much evidence X reporters have been using it
[22:40] <bryceh> ah I see
[22:40] <bryceh> interesting
[22:41] <seb128> no, we don't but it's pretty easy to close the bug and tell them to reopen one with the command
[22:41] <seb128> which will land on the right source with all the useful logs
[22:41] <seb128> we are using it quite a lot for the storage symptom and it working well
[22:41] <seb128> it has udisks gvfs udev logs which is often enough to see where it's buggy
[22:42] <asac> bug 558651
[22:44] <seb128> asac, typically a bug which should be opened using the storage symptom indeed ;-)
[22:44] <asac> heh
[22:45] <seb128> I closed it asking for that now
[22:45] <asac> gvfs-afc-volume-monitor ... where is that?
[22:45] <seb128> there is no reason the afc backends trigger on those
[22:45] <seb128> the gvfs backend used for iphone devices
[22:46] <seb128> I'm wondering if that usb drive has a similar usb id or something
[22:46] <asac> good question.
[22:46] <asac> seb128: should that bug be opened when the drive is plugged in?
[22:47] <seb128> asac, the storage symptom ask you to remove the device then click a button then connect the device
[22:47] <seb128> asac, and it gets the udev log of what happens when you connect it
[22:47] <asac> hmm
[22:47] <asac> lets see
[22:47] <seb128> it's made of awesome, pitti wrote it ;-)
[22:48] <seb128> you can pick the first case
[22:48] <seb128> device not mounting
[22:48] <seb128> it will provide the logs we need
[22:48] <asac> lets hope that really gives more info.
[22:49] <seb128> well it will give udev udisks and gvfs logs for sure
[22:49] <asac> hmm
[22:49] <seb128> which will be enough to match the device id to the afc ones
[22:49] <asac> ok
[22:49] <asac> seb128: what package is afc stuff in?
[22:49] <seb128> asac, usbmuxd: /lib/udev/rules.d/85-usbmuxd.rules
[22:49] <seb128> if you want to see the ids
[22:50] <asac> seb128: where is the mapping to afc done?
[22:50] <asac> guess it just matches two rules and hence we get that dialog?
[22:51] <seb128> asac, see the rules I just copied
[22:51] <seb128> well an usb device should not considered by the afc backend at all
[22:51] <seb128> the udev rules set USBMUX_SUPPORTED for devices which match
[22:52] <seb128> and gvfs use that to say it's an iphone like device and mount it with afc
[22:52] <seb128> you might get 2 events yes
[22:52] <seb128> or you might get one player and one camera mount
[22:52] <seb128> since iphone have both a multimedia player and a camera
[22:54] <asac> hmm.
[22:54] <asac> the bug says it "fails due to pending operation" ... then "two nautilus windows open"
[22:56] <seb128> asac, the afc backend should be ignore that device to start
[22:56] <seb128> be ignoring
[22:56] <seb128> asac, so I would want to look first at why it doesn't
[22:57] <seb128> asac, I would not be surprised that it does timeout because it init an afc device dialog and your device is not one and doesn't reply
[22:57] <asac> seb128: i still dont see where and how that backend is hooked up. the .rules only calls usbmuxd
[22:58] <seb128> asac, gvfs monitors connecteds devices
[22:59] <seb128> asac, and route those through the volume monitor, gphoto monitor or afc monitor according to the type of device
[22:59] <seb128> asac, the afc backend should only kick in if the USBMUX_SUPPORTED property is set in udev
[23:00] <asac> seb128: afc stands for?
[23:01] <seb128> asac, I'm not sure, apple something
[23:02] <seb128> asac, "Apple File Communication Protocol (AFC). " says google
[23:02] <seb128> asac, it's the protocol they set up for iphones
[23:04] <seb128> asac, http://en.wikipedia.org/wiki/Apple_Filing_Protocol
[23:06] <seb128> asac, hum, maybe not that wikipedia page no ;-)
[23:13] <bryceh> seb128, huh, still getting lp oopses on trying to convert bugs to questions
[23:13] <seb128> bryceh, do you have a bug example? does it depends of the text you put in the entry when converting?
[23:14] <james_w> what's the oops number?
[23:14] <bryceh> sorry, I cleared it already
[23:14]  * bryceh tries again
[23:15] <bryceh> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/568111/+create-question
[23:15] <bryceh>  (Error ID: OOPS-1573EC1257)
[23:18] <seb128> bryceh, https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/568111
[23:18] <seb128> worked for me
[23:19] <seb128> bryceh, could depend of the text you enter maybe? I didn't put any there
[23:23] <james_w> looks like some inefficient SQL that makes a lot of queries and so could well be a non-deterministic timeout depending on the cumulative time
[23:30] <TheMuso> Good morning.
[23:31] <Nafai> Morning TheMuso
[23:37] <RAOF> Good morning gentlemen
[23:38] <Nafai> Hey RAOF
[23:38] <RAOF> I appear to have managed to use up my brother's internet bandwidth allocation :(
[23:40]  * RAOF hugs the unshaped mirror.internode.on.net
[23:40] <Nafai> uh oh
[23:40] <Nafai> I can't imagine having to worry about a bandwidth allocation
[23:41] <bryceh> aha
[23:41] <bryceh> seb128, yeah if I give no text it goes to a question
[23:41] <bryceh> *sigh*
[23:41]  * bryceh wanders off to file a launchpad bug report
[23:42] <RAOF> I generally purchase a plan sufficient for my needs :)
[23:42] <RAOF> bryceh: Good morning.
[23:42] <bryceh> hi RAOF, how goes?
[23:42] <RAOF> Apart from this internet now being sloooooow, well.
[23:42] <TheMuso> Nafai: Thats how it has been for many years in Australia.
[23:43] <Nafai> So I hear
[23:45] <RAOF> Now that I've sucked Alexander's internet dry, I guess I'll be working somewhere else today.  My internet gets turned on Tuesday.
[23:46] <TheMuso> RAOF: he probably hates you right about now.
[23:46] <TheMuso> :)
[23:46] <RAOF> He didn't even have a working computer this month!
[23:47] <RAOF> But I have managed to get him capped just as the fixed computer arrives, so yes.  It's only 3 days until rollover date, though.
[23:47] <RAOF> He can suck it up!
[23:47] <TheMuso> Thats not too bad.
[23:48] <TheMuso> If he is on a new plan, the shaping is 128kbps now anyway.
[23:48] <Nafai> up or down?
[23:48] <TheMuso> Nafai: down
[23:50] <Nafai> man, I'm spoiled, I guess
[23:50] <TheMuso> Nafai: We are a fair way away from the rest of the western world, and need to pay for our pipes somehow.
[23:50] <Nafai> true
[23:51] <TheMuso> Nafai: There are many people in Australia 8who can barely get any form of broadband at all.
[23:51] <TheMuso> Wireless is their only option, which is not cheap, and quotas are pittifully small.
[23:51] <Nafai> I've got this "Internet World" poster above my desktop, showing major connections between cities, and the one between Sydney (I guess) and the US is a huge arc
[23:52] <TheMuso> heh
[23:52] <RAOF> That's a cool picture
[23:53] <TheMuso> We recently had another pipe between Australia and Guam come online, however the company who funded it is now owned by I think our forth largest ISP's parent company.
[23:53] <TheMuso> So its likely it will be reserved for that ISP's customers.
[23:53] <TheMuso> and will cost more for other ISPs to use it.
[23:53] <Nafai> of course
[23:54] <Nafai> telestra?  I think that's the one I've seen aussies complain about :)
[23:54] <TheMuso> Telstra, yes.
[23:55] <TheMuso> My dealings with them have been quite ok actually. As long as you don't have to speak to anyone on the phone, they have reliable infrastructure.
[23:56] <TheMuso> brb got to hang out some washing (laundry for you overseas folks.)
[23:57] <rickspencer3> Hi RAOF
[23:57] <rickspencer3> TheMuso,
[23:57] <rickspencer3> Nafa
[23:57] <rickspencer3> Nafai, even
[23:57] <Nafai> hey :)
[23:57] <RAOF> rickspencer3: Good morning
[23:58] <rickspencer3> I kind of think of you guys + robert_ancell as the "afternoon people" now
[23:58] <rickspencer3> RAOF, pitti wanted to roll back glx before release, right?
[23:58] <rickspencer3> not wait for an SRU