[05:01] <plars> 250/12
[05:02] <plars> wrong window, sorry
[07:09] <ara> morning all :-)
[08:13] <ara> do you guys experience this bug: https://bugs.launchpad.net/ubuntu-website/+bug/352195
[08:13] <ubot4> Launchpad bug 352195 in ubuntu-website "Last u of "ubuntu" logo is not shown complete in the Jaunty start page " [Undecided,New]
[08:16] <torkiano> ara, yes
[08:17] <ara> torkiano: can you set it as confirmed then?
[08:17] <torkiano> sure
[08:19] <torkiano> ara, confirmed
[08:19] <ara> torkiano: ta!
[08:22] <torkiano> ara, same behaviour with midori browser (webkit based), so confirmed that is a website fault
[10:43]  * eeejay_afk tries jcollado's branch
[10:44] <ara> eeejay: thanks for reviewing :)
[10:45] <eeejay> ara: will these changes make *_constants.py obsolete?
[10:45] <ara> eeejay: yup
[10:58] <eeejay> ara: jcollado: if my suggestion seems reasonable, I could merge it into the branch
[11:00] <jcollado> eeejay: I use the self.__class__.whatever notation just to keep in mind that I'm using a class variable, but if you find the short notation better, that's OK.
[11:01] <eeejay> jcollado: i understand what you are saying, makes sense
[11:01] <eeejay> jcollado: it is confusing when you change a property in one instance, and it magically changes in another instance too :)
[11:02] <jcollado> eeejay: self.whatever = something isn't the same as self.__class__.whatever = something. That's the error that I try to avoid.
[11:02] <jcollado> Anyway, since those variables are expected to be used as constants (read-only), then it shouldn't be any problem.
[11:03] <jcollado> (to use the short notation)
[11:03] <eeejay> jcollado: the effect is not the same?
[11:03] <jcollado> No, in the first case your overwriting the class variable with an object variable
[11:04] <jcollado> so you're changing self.whatever only for that object
[11:04] <eeejay> jcollado: i am pretty sure it changes the class variable (if it is pre-defined)
[11:04]  * eeejay checks
[11:05] <eeejay> you are right
[11:06] <eeejay> dang
[11:07] <eeejay> jcollado: in that case, i actually think removing __class__ is a better idea
[11:07] <eeejay> jcollado: thinking of users who need to write scripts
[11:07] <jcollado> eeejay: Yes, it's fine
[11:07] <eeejay> jcollado: they don't need to deal with the fact that it is class properties at all
[11:08] <eeejay> jcollado: if they want to rename WINDOW in an instance (self.WINDOW = 'foo'), it won't mess with other instances/subclasses
[11:08] <eeejay> jcollado: ie. it will work as expected
[11:09] <jcollado> eeejay: I agree.
[11:09] <eeejay> ok, so i am pushing to the branch, and give two thumbs up :)
[11:10] <jcollado> eeejay: Thanks.
[11:43] <eeejay> ara: what should I do with https://bugs.launchpad.net/gnome-desktop-testing/+bug/347216
[11:43] <ubot4> Launchpad bug 347216 in gnome-desktop-testing "Ability to run single or selected testcase" [Undecided,New]
[11:43] <eeejay> ara: I am not sure where to commit it first, if at all
[11:44] <ara> eeejay: that was already solved in ubuntu-desktop-testing/trunk
[11:44] <ara> eeejay: (from tweaks)
[11:44] <eeejay> ara: really? oops.
[11:44] <ara> eeejay: as per gnome-desktop-testing. I have requested a bzr import
[11:44] <eeejay> ara: cool
[11:44] <ara> eeejay: i am mergeing those changes to SVN, but after the import we could work with branches
[11:45] <ara> eeejay: I will send an email to desktop-testing-list when it is available
[11:45] <eeejay> ara: I thought gnome.org already had a bzr proxy
[11:51]  * eeejay waits for jcollado's branch to land in trunk. i'll merge it into dx
[12:28] <jtholmes> heno ping
[12:33] <jtholmes> last nights daily-live left some of the debconf info in the yes/no buttons of the weak password question
[12:33] <jtholmes> in the installer
[12:33] <jtholmes> kde_ui
[12:49]  * ara -> lunch
[14:05] <BUGabundo> hy
[14:05] <BUGabundo> latter tonight I'm going to install a few older Dells with Jaunty daily 32bits
[14:05] <BUGabundo> are there any tests anyone in here need me to check?
[14:33] <jtholmes>  BUGabundo just know that the weak password question has the wrong text and the fix should occur in tomorrows daily build
[14:33] <BUGabundo> a la Fedora?
[14:33] <BUGabundo> I remember reading something about that
[14:34] <BUGabundo> does that mean I can't have a password that is the same as username?
[14:34] <jtholmes> a l kubuntu dont know about ubuntu
[14:34] <BUGabundo> this are "trash" installs for a Class next Saturday
[14:35] <jtholmes> ok just a heads up on the button text for weak passwd it works just fine just incorrect text in yes/no buttons
[14:37] <BUGabundo> ok
[14:37] <BUGabundo> thanks
[20:08] <BUGabundo2> hey
[20:09] <BUGabundo2> just tested todays daily on a DELL gx 270
[20:09] <BUGabundo2> since this machine has an intel 865 i cant use it
[20:09] <BUGabundo2> installing it with VESA suck
[20:13] <jtholmes> BUGabundo, for my info why cant u use the 865
[20:13] <BUGabundo> i know
[20:13] <BUGabundo> its on the release notes
[20:13] <jtholmes> ok thanks
[20:13] <jtholmes> i will look there
[20:14] <BUGabundo> bug 304871
[20:14] <ubot4> Launchpad bug 304871 in xserver-xorg-video-intel "[i845G] Fatal server error: Couldn't bind memory for BO front buffer (Jaunty)" [High,In progress] https://launchpad.net/bugs/304871
[21:21] <rmcbride> Anyone seen any behavior like https://bugs.edge.launchpad.net/ubuntu/+source/openssh/+bug/352154 ? A bunch of my team have this as a Nemisis since upgrading to Jaunty Beta
[21:21] <ubot4> Launchpad bug 352154 in openssh "ssh-agent stops responding" [Undecided,New]
[21:23] <cjwatson> rmcbride: very likely not openssh's fault at all, but due to seahorse
[21:23] <cjwatson> rmcbride: echo $SSH_AUTH_SOCK
[21:23] <cjwatson> it's only openssh if it's something like /tmp/ssh-BLAH/agent.BLAH
[21:24] <rmcbride> cjwatson: ah, yea. OK that makes sense. One of our Devs spotted it first and wrote the bug based on observed behavior. I'm just following up because I'm seeing it on my dev system now.
[21:24] <cjwatson> rmcbride: do actually do that $SSH_AUTH_SOCK check so that we can confirm though
[21:25] <rmcbride> /tmp/keyring-gk1OMb/socket.ssh
[21:25] <cjwatson> right. I blame something that ain't openssh. :)
[21:25] <rmcbride> OK. SHall I move that to seahorse, and add language to that effect?
[21:25] <cjwatson> 21:23 <cjwatson> rmcbride: very likely not openssh's fault at all, but due to seahorse
[21:26] <cjwatson> 21:23 <cjwatson> rmcbride: echo $SSH_AUTH_SOCK
[21:26] <cjwatson> oops
[21:26] <cjwatson> rmcbride: I've reassigned it
[21:26] <rmcbride> cjwatson: awesome! thanks!
[21:26] <cjwatson> (this is by way of getting it off my plate, since I maintain openssh ...)
[21:27] <rmcbride> heheh