[17:21] <vooze> Is there some way you can make the developers see a bug faster? I have reported it, and its been confirmed because 1 and 3 others are marked as affected. I'm talking about this one (network-manager related) https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1574020
[17:21] <vooze> me and 3 others *
[20:30] <tsimonq2> vooze: weird, mind bumping it on the bug report?
[20:31] <tsimonq2> vooze: added the Lubuntu Packages team, at least it'll get looked at by a few Lubuntu people :)
[21:02] <vooze> tsimonq2: sorry for the late reply. Thank you for giving it some attention. How can i bump it?
[21:03] <tsimonq2> teward: would this be appropriate? ^
[21:03] <tsimonq2> (to bump it)
[21:04]  * teward was pinged
[21:04] <vooze> It's not really a high priority issue, I get that. Just really annoying ;)
[21:04] <teward> tsimonq2: E:ContextFailure
[21:04] <teward> i need context :)
[21:04] <tsimonq2> teward: he wants progress on bug 1574020
[21:05] <teward> that's in Main
[21:05] <teward> it'll get looked at
[21:05] <teward> bumping doesn't really help much
[21:05] <tsimonq2> vooze: alright, teward knows more than me, do what he says ;)
[21:06] <vooze> tsimonq2: alright. Thank you for everything :) I will wait.
[21:06] <tsimonq2> np :)
[21:06] <teward> tsimonq2: especially if the only reason to bump is to get someone to look at it
[21:06] <teward> preferred is to have more info added if you're going to bump, don't just bump for bumping sake
[21:06] <teward> (mark it as "Affects me too" :p
[21:08] <vooze> Feel free to test it out ;) It should take 2 secs on log out :P
[21:08] <teward> only applies if we all ahve that version installed :p
[21:08]  * teward doesn't
[21:09] <tsimonq2> vooze: I've noticed it before :)
[21:09] <vooze> True true ;)
[21:11] <vooze> Well I have to leave. Thank you again for your time and work. :)


[15:52] <kenvandine> cjohnston, hey
[15:53] <kenvandine> cjohnston, any chance the last gwibber version fixed that bug?
[16:16] <kenvandine> cjohnston, i am heading out to find some dinner or something... will try to get back online later tonight and find you :)
[16:34] <TheMuso> RAOF: Feeling better after a shower? :)
[16:34] <TheMuso> Oh and are you on level 2, or in your room?
[16:34] <RAOF> On level 2
[16:34] <RAOF> Yeah, a bit better post-shower.
[16:34] <TheMuso> Are there many others around?
[16:34] <RAOF> Not really.
[16:35] <RAOF> It's quite quiet.
[16:35] <TheMuso> hrm ok. Might head down there in a bit anyway.
[16:35] <RAOF> I'm with jml & poolie.
[16:35] <TheMuso> what room?
[16:36] <RAOF> Um.  In the foyer bit, with the cofee machines and such.
[19:59] <cjohnston> kenvandine: im back.. ping me when you get some time... I think its fixed.. I'll try to pay more attention.


[08:25] <Chipaca> hellooooo
[08:26] <jam> morning Chipaca
[08:26] <Chipaca> hi jam
[08:31] <Chipaca> jam: did we have anything to review for today's meeting?
[08:33] <jam> Chipaca, probably would be good to think about a policy wrt mocking multiple interactions
[08:52] <jam> Chipaca, I added a line to https://github.com/canonical/operator/pull/325/files to do a debug log if we aren't using cyaml, I'm trying to test it out now
[08:52] <mup> PR #325: ops/main.py: Use CSafeLoader <Created by jameinel> <https://github.com/canonical/operator/pull/325>
[08:53] <Chipaca> jam: nice
[08:53] <Chipaca> now i think i need to get ready for a meeting
[08:53] <Chipaca> and by 'get ready' i mean 'put a shirt on'
[08:53] <jam> yeah, in 5min, right?
[08:53] <Chipaca> yeah
[09:17] <mthaddon> just thought you guys might be interested to know https://blog.launchpad.net/ is live with an operator charm on k8s (https://code.launchpad.net/charm-k8s-wordpress)
[09:19] <mthaddon> t0mb0 put it live earlier today ^
[09:23] <jam> mthaddon, very nice to hear
[09:29] <Chipaca> mthaddon: nice
[09:29] <Chipaca> mthaddon: how's the mattermost one coming along?
[09:30] <mthaddon> Chipaca: it's up and running, but still in preview mode (getting themes and plugins in place, etc.)
[09:31] <Chipaca> mthaddon: good one
[09:32] <jam> Chipaca, are you happy with the wording of that log message?
[09:33] <jam> Chipaca, I'm not sure how to test it, as yaml that comes by default on Ubuntu images has cyaml available
[09:34] <Chipaca> jam: import yaml; _nukularize(yaml); main(Charm) --> ooh look a logline
[09:35] <Chipaca> jam: granted i'm not sure how much value that adds, as a test :)
[09:35] <jam> Chipaca, I was more meaning testing it practically that it actually shows up, etc. but yeah, I can add a test of main directly
[09:36] <Chipaca> jam: alternatively we could have an integration test that creates its own venv
[09:37] <Chipaca> jam: it feels like on the outside of what's a reasonable integration-in-unit-dress test
[09:44] <jam> Chipaca, yeah, it was mostly that I wanted to deploy something in a fashion that caused it to trigger, so I could see how obvious it was what was going on.
[09:49] <Chipaca> jam: a charm with PyYAML in its requirements.txt should end up with a non-libyaml yaml unless you're very careful
[09:50] <jam> Chipaca, because you have to have the -dev package installed before fulfilling requirements?
[09:50] <Chipaca> there isn't yet code in charmcraft to not ship PyYAML in the generated env
[09:50] <Chipaca> jam: and cython
[09:50] <jam> Chipaca, and build-essential, right?
[09:50] <jam> (that's one of the big things we're trying to avoid :)
[09:51] <Chipaca> jam: i'm thinking of when you 'charmcraft build' it
[09:51] <Chipaca> jam: meaning you'd need those things on the build machine, but not in the run machine
[10:05] <jam> Chipaca, so how does that work across series?
[10:05] <Chipaca> jam: perfectly
[10:05]  * Chipaca hides
[10:06] <Chipaca> jam: sorry, what do you mean in particular?
[10:06] <jam> Chipaca, I'm just thinking of "I wrote a charm, and I want to support bionic and focal"
[10:07] <Chipaca> jam: we're ignoring that until the new api supports platform properly
[10:07] <jam> Chipaca, if we are defaulting to a venv that *doesn't* have system libs, then you can't get compiled extensions from the platform
[10:08] <jam> I keep coming around to if 'charmcraft build' is doing too much, it has to fill too many holes
[10:08] <Chipaca> jam: but if you run on the same python as you build you should be able to get .so things even now
[10:08] <Chipaca> jam: the plan is that a charm is platform-specific, and built N times once per platform, so hopefully that makes it simpler :)
[10:09] <Chipaca> a .charm i mean, the built artifact
[10:09] <Chipaca> that's where the launchpad builders come in, also
[10:09] <Chipaca> and 'charmcraft remote'
[11:30] <facubatista> Muy buenos días a todos!
[11:42] <Chipaca> facubatista: o/! :-)
[11:46] <facubatista> hola Chipaca :)
[11:46] <Chipaca> jam: is there a reason but main.main and model._ModelBackend get the unit name from the environ?
[11:47] <Chipaca> facubatista: when you have time to look at a long and complicated PR, 326 is there for you
[11:49] <facubatista> Chipaca, ack
[11:52] <jam> Chipaca, I don't quite follow. "is there a reason they get the model name from the environ"?
[11:53] <Chipaca> jam: main.main does gets JUJU_MODEL_NAME from the environ, passes it into model.Model, which then creates a _ModelBackend which again gets the model name from the environ
[11:53] <Chipaca> er
[11:53] <Chipaca> jam: UNIT_NAME i meant sorry
[11:53] <jam> Chipaca, ... I'm not a big fan of 'model' code reading from os.environ. I feel it should be encapsulated at a layer, but not spread throughout the code. That said, I feel like either main() or Backend could be that layer
[11:54] <jam> Chipaca, I did the main() one, someone else did the UNIT_NAME one. I could be convinced that we should move it to ModelBackend
[11:54] <jam> What I don't want is Model itself to look at environ
[11:55] <Chipaca> agreed on that at least :)
[11:58] <jam> Chipaca, fwiw, I'm not super happy about 4+ arguments on Model
[12:01] <jam> Chipaca, I just noticed that main() actually grabs both UNIT and MODEL and then passes them in, to which ModelBackend rereads UNIT name rather than taking it as an arg
[12:01] <jam> Chipaca, what would you prefer? Should we move the environ call out of ModelBackend and pass the unit name in?
[12:01] <jam> Chipaca, or would you rather the Model read the unit name from the backend ?
[12:01] <Chipaca> jam: haven't decided what i prefer yet, i just noticed the duplication and thought to ask if there was context for it
[12:15] <mup> Issue operator#32 closed: The charm tool should offer an initial skeleton <Created by woutervb> <https://github.com/canonical/operator/issues/32>
[12:42] <Chipaca> niemeyer: when you 'transfer' an issue in github, mup gets confused about its url ^ (that is now issue 32 in charmcraft, but it was a different number in operator)
[12:42] <mup> PR #32: Implement interface base layer with examples <Created by johnsca> <Closed by niemeyer> <https://github.com/canonical/operator/pull/32>
[12:53] <mup> Issue operator#240 closed: Shared StoredState between kubernetes workload pods <Created by davigar15> <Closed by jameinel> <https://github.com/canonical/operator/issues/240>
[12:55] <davigar15> jam: Is the issue solved ^
[12:55] <jam> davigar15, 240 is a duplicate of 317 so I closed it to avoid having 2 bugs. I'm actively working on it now.
[12:55] <mup> Issue operator#291 closed: Log event re-emission <bug> <Created by chipaca> <Closed by chipaca> <https://github.com/canonical/operator/issues/291>
[12:56] <davigar15> great!
[12:56] <davigar15> sorry, i didn't see the duplicated message :-)
[13:24] <jam> Chipaca, given the earlier discussion: https://github.com/canonical/operator/pull/327
[13:24] <mup> PR #327: many: move Model.name to be read from _ModelBackend <Created by jameinel> <https://github.com/canonical/operator/pull/327>
[13:24] <jam> It moves both unit name and model name to be read from the backend, and cleans up things quite a bit IMO
[13:25] <mup> PR operator#327 opened: many: move Model.name to be read from _ModelBackend <Created by jameinel> <https://github.com/canonical/operator/pull/327>
[15:00] <facubatista> Chipaca, where, the meeting?
[15:00] <Chipaca> facubatista: standup?
[15:41] <facubatista> Chipaca, so, how do we proceed about the CLA thing
[15:41] <facubatista> ?
[15:41] <Chipaca> facubatista: in particular, or in general?
[15:42] <facubatista> Chipaca, for charmcraft
[15:42] <facubatista> Chipaca, shall we put a travis thing?
[15:42] <Chipaca> facubatista: we shall, if nothing better works
[15:42] <Chipaca> facubatista: i'
[15:43] <Chipaca> facubatista: i've reached out to other managers to find out if anything easier is working
[15:43] <Chipaca> there are CLA-signing web services that integrate with github
[15:43] <Chipaca> but i suspect they don't work with our CLA
[15:43] <facubatista> Chipaca, ack; in the meantime, we should tell this person to sign that somehow?
[15:43] <Chipaca> facubatista: i already have
[15:43] <facubatista> Chipaca, thanks
[15:51] <facubatista> Chipaca, regarding upload-status, there's no harm in making that publicly available, it could be "hidden from the normal help", or even present in the normal help but in an "advanced" section
[15:52] <Chipaca> facubatista: I wouldn't expose it until we're sure we want to support it
[15:52] <facubatista> Chipaca, we need to automatic do that after an upload, until "all is green", but if the developer issues that at any moment, it's fine
[15:52] <Chipaca> facubatista: but for them to do that we'd need to print that long upload id for them to use
[15:52] <Chipaca> and that sounds like a bad idea
[15:53] <facubatista> mmm... ok, let's see later
[15:57] <facubatista> Chipaca, I added four cards to the "core backlog" column (they're in the bottom), after separating all the commands we talked about in four groups
[15:57] <facubatista> Chipaca, we may put those in a new "charmcraft" column?
[15:57] <Chipaca> thank you
[15:57] <Chipaca> yeah
[15:57] <facubatista> Chipaca, I do it
[16:08] <Chipaca> facubatista: thank you
[16:46] <Chipaca> facubatista: i'm going to head out shortly. Anything you need from me?
[17:20] <facubatista> Chipaca, sorry, was lunching; when you have some minutes for the comments in the Charm packaging spec it would be great, thanks
[17:45] <facubatista> *having lunch
[19:03] <Cynerva_> does charmcraft include config.yaml in built charms? i've got a config.yaml alongside metadata.yaml but the .charm file produced by `charmcraft build` doesn't seem to include it
[20:02] <facubatista> Cynerva_, not yet, we have a PR that will bring that soon
[20:17] <Cynerva_> ack, thanks
[20:18] <Cynerva_> ah yep there it is https://github.com/canonical/charmcraft/pull/31
[20:18] <mup> PR charmcraft#31: Include config.yaml in built charm <Created by charness> <https://github.com/canonical/charmcraft/pull/31>
[20:54]  * facubatista eods


[01:30] <rickspencer3> kenvandine, I think I figured out how to write a GUI to choose which desktopcouch databases to synch
[01:30] <rickspencer3> I'll try it tonight, seems like it would take about an hour or so
[01:41] <rickspencer3> kenvandine, http://imgur.com/qnfuD
[02:28] <kenvandine> rickspencer3, sweet!
[02:29] <kenvandine> slip cover... lol
[02:29] <kenvandine> :)
[02:33] <rickspencer3> :)
[02:39] <rickspencer3> kenvandine, accessing the gwibber_preferences couchdb immediately pegs my CPU
[02:39] <kenvandine> wow
[02:39] <rickspencer3> gwibber-server and desktopcouch-se
[02:39] <kenvandine> got a test case?
[02:39] <rickspencer3> I'll package the app I just wrote
[02:39] <rickspencer3> and you can run it yourself
[02:39] <kenvandine> great
[02:39] <rickspencer3> it's 100% reliable
[02:39] <rickspencer3> hold on
[02:40] <kenvandine> i would like to get ryan to do it to
[02:40] <rickspencer3> kenvandine, can i just email you the deb?
[02:40] <kenvandine> sure
[02:40] <kenvandine> or IM it to me :)
[02:40] <kenvandine> empathy rocks
[02:41] <rickspencer3> $quickly package ftw
[02:41] <rickspencer3> sure, good idea
[02:41] <kenvandine> quickly rocks too
[02:41] <rickspencer3> kenvandine, so when you run this, it will list out each of your desktopcouch databases as a button
[02:42] <rickspencer3> see what happens when you click gwibbermessages
[02:42] <kenvandine> ok
[02:43] <kenvandine> i get a crash dialog :)
[02:43] <kenvandine> from slip-cover
[02:43] <kenvandine> but
[02:43] <rickspencer3> oh well
[02:43] <kenvandine> not for other dbs
[02:43] <rickspencer3> it doesn't even run?
[02:43] <kenvandine> let me change my passwords to plaintext so i can run gwibber
[02:43] <kenvandine> :)
[02:43] <kenvandine> it does
[02:44] <kenvandine> just clicking on gwibbermessages gives me a crash dialog
[02:44] <kenvandine> it doesn't seem to crash though
[02:44] <rickspencer3> oh
[02:44] <rickspencer3> I bet my way of getting the records from it doesn't work
[02:44] <rickspencer3> I used a super convenience method
[02:44] <rickspencer3> let me see if there is a better way
[02:45] <rickspencer3> oh crikey
[02:45] <kenvandine> oh... here
[02:45] <kenvandine>   File "/usr/lib/python2.6/dist-packages/desktopcouch/records/server_base.py", line 454, in get_records
[02:45] <kenvandine>     raise KeyError("View doesn't already exist.")
[02:45] <kenvandine> KeyError: "View doesn't already exist."
[02:45] <rickspencer3> I have to do hard things
[02:45] <rickspencer3> right
[02:45] <kenvandine> that was in the terminal
[02:46] <kenvandine> no worries
[02:46] <kenvandine> ok, gwibber is running
[02:46] <rickspencer3> so get_records() doesnt' quite work reliably
[02:46] <kenvandine> let me make sure the cpu doesn't peg
[02:46] <rickspencer3> kenvandine, if you run photobomb first, and go to the gwibber tab, it should work
[02:46] <rickspencer3> slipcover, that is
[02:47] <rickspencer3> actually, I wonder if that will pin the CPU
[02:48] <kenvandine> i just did 3 refreshes
[02:48] <kenvandine> with plaintext password... no load
[02:48] <kenvandine> ok, time for slip-cover again
[02:48] <rickspencer3> I have plane text passwords too
[02:48] <kenvandine> you said gwibberpreferences pegs it?
[02:48] <rickspencer3> yes
[02:49] <rickspencer3> kenvandine, can you see if photobomb pegs it for you?
[02:49] <rickspencer3> bzr branch lp:~rick-rickspencer3/+junk/photobomb
[02:49] <kenvandine> yeah, one sec
[02:49] <kenvandine> so just opening gwibberprefernces pegs it for you?
[02:49] <rickspencer3> yes
[02:50] <rickspencer3> but I've run photobomb, which asks gwibber_preferences to create a view for get_records
[02:50] <rickspencer3> that's why slip-cover works for me on that database
[02:50] <rickspencer3> I'll have to write a few lines to create a proper view
[02:52] <kenvandine> i ran it
[02:52] <kenvandine> waiting now :)
[02:52] <kenvandine> gwibber_messages is pretty big
[02:54] <kenvandine> http://pastebin.ubuntu.com/407861/
[02:54] <kenvandine> rickspencer3, ^^
[02:54] <rickspencer3> wtf
[02:54] <kenvandine> and i am not seeing the CPU load
[02:55] <rickspencer3> kenvandine, do you have quickly-widgets installed from universe?
[02:55] <kenvandine> yes
[02:55] <kenvandine> 10.02.2
[02:56] <rickspencer3> weird
[02:56] <rickspencer3> *sigh*
[02:56] <kenvandine> i wonder how your accessing it that causes it
[02:57] <kenvandine> do you read in all the records?
[02:58] <rickspencer3> kenvandine, yes
[02:58] <rickspencer3> db.get_records()
[02:59] <rickspencer3> kenvandine, photobomb also causes the cpu to pim
[03:00] <kenvandine> not for me
[03:00] <rickspencer3> when you refresh on the gwibber tab?
[03:00] <rickspencer3> it does not peg your CPU?
[03:00] <kenvandine> refresh?
[03:00] <rickspencer3> on photobomb, there is a gwibber tab
[03:01] <kenvandine> oh
[03:01] <kenvandine> let me do that
[03:01] <rickspencer3> you have to hit the refresh button for it to start grabbing photos from your gwibber accounts
[03:01] <rickspencer3> it also reads you gwibber settings database and pulls your facebook credentials
[03:03] <kenvandine> wow... photobomb is using a ton of ram
[03:04] <kenvandine> 2G and growing
[03:04] <rickspencer3> hehe
[03:04] <rickspencer3> a tad leaky?
[03:04] <kenvandine> hehe
[03:05] <kenvandine> not really seeing any load problems though
[03:05] <rickspencer3> kenvandine, so the gwibber page didn't peg your CPU?
[03:05] <kenvandine> nope
[03:05] <rickspencer3> this is soooo weird
[03:05] <kenvandine> you said it does it to desktopcouch too
[03:06] <kenvandine> desktopcouch-service? or beam.smp?
[03:06] <rickspencer3> so certain apps, when they access gwibber preferences, cause the CPU to peg
[03:06] <rickspencer3> kenvandine, both
[03:06] <rickspencer3> all
[03:06] <rickspencer3> but the thing is, the apps that do this are different for different people
[03:06] <rickspencer3> IT MAKES NO SENSE
[03:06] <kenvandine> very weird
[03:06] <kenvandine> so if it is making gwibber-service spike
[03:06] <kenvandine> it must be changing records
[03:07] <kenvandine> otherwise gwibber would never even know it
[03:07] <rickspencer3> like something is listening for record changes?
[03:07] <kenvandine> but, gwibber-service does have "Monitors" setup for the dbs it cares about
[03:07] <kenvandine> yeah, so gwibber sees records added or updated as events
[03:08] <rickspencer3> and then gwibber writes records in response to these events, gets invoked, etc...?
[03:08] <kenvandine> but you are doing a get_record
[03:08] <kenvandine> no
[03:08] <kenvandine> gwibber sees something else writing to it
[03:08] <kenvandine> it wouldn't get an event for it at all if there aren't records changing
[03:08] <rickspencer3> my desktopcouch-se is just running one of my CPUs at 99%
[03:08] <kenvandine> which is weird
[03:08] <rickspencer3> for like the last 5 mins
[03:08] <rickspencer3> right
[03:08] <kenvandine> ok... well... that is familiar :)
[03:09] <kenvandine> is slip-cover still running?
[03:09] <rickspencer3> no
[03:09] <rickspencer3> gwibber though
[03:09] <kenvandine> i bet that is the same thing i was seeing
[03:09] <kenvandine> killall gwibber gwibber-service
[03:09] <rickspencer3> but I never saw this until I accesssed gwibberaccounts
[03:09] <kenvandine> which is weird
[03:10] <kenvandine> we need chad
[04:10] <rickspencer3> kenvandine, oh well, at least  you found that bug in DictionaryGrid for me
[04:10] <rickspencer3> was happy to fix that
[04:10] <rickspencer3> g'night
[04:10] <kenvandine> :/
[04:10] <kenvandine> good night
[04:10] <rickspencer3> kenvandine, we'll figure it out tomorrow
[04:10] <rickspencer3> the answer is staring you guys in the face, I am convinced
[04:11] <rickspencer3> a good night's sleep will prolly help ;)
[04:11] <kenvandine> :)
[07:34] <huats> morning
[07:38] <vuntz> huats: hello
[07:38] <huats> hello vuntz
[07:39] <vuntz> didrocks: any idea why simple-scan is at 0.9.10 in the ubuntu packages, but the latest tarball is 0.9.9?
[08:14] <didrocks> vuntz: robert_ancell probably forgot to create the milestone and upload the tarball. Do you want it? I can apt-get source and push it somewhere
[08:14] <didrocks> vuntz: that's why Quickly rules: it does it for you :p
[08:14] <didrocks> hey huats
[08:14] <huats> hello didrocks
[08:33] <vuntz> didrocks: better to annoy rob when he'll be here :-)
[08:33] <didrocks> vuntz: sure, do not hesitate :p
[08:57] <desrt> vuntz: hey
[08:57] <desrt> didrocks: hello
[08:57] <didrocks> hey desrt, quite late for you, isn't it?
[08:57] <desrt> can't sleep
[08:57] <didrocks> argh :/
[08:57] <desrt> didrocks: might i be able to harass you about some universe stuff?
[08:58] <didrocks> desrt: sure
[08:58] <desrt> normally i bother seb, but he's committed to vacationing today :)
[08:58] <desrt> two things:
[08:58] <didrocks> (yeah, it's a shame :))
[08:58] <desrt> 1) can you guys update to the freshly-released valac version?
[08:58] <desrt> (that's the easy one)
[08:59] <desrt> 2) http://packages.debian.org/source/sid/zeromq
[08:59] <desrt> (that's the hard one)
[09:00] <desrt> i'm not really familiar with how difficult it is to get new package into the archive this late in the cycle if they have upstream versions already existing in debian
[09:01] <didrocks> desrt: nothing too risky in the new vala release? ("Infer type arguments when calling generic methods." <- no impact?)
[09:01] <vuntz> didrocks: it's the stable release
[09:01] <didrocks> vuntz: ok, 0.7.10 isn't? it follows odd number == unstable too?
[09:01] <vuntz> so better to have a stable release than a development one, I'd say
[09:01] <didrocks> right
[09:01] <desrt> didrocks: no.  0.8.
[09:02] <desrt> quite freshly released
[09:02] <didrocks> desrt: yeah, I was asking if "0.7.10" (the current one we have) is unstable. Understood, will update :)
[09:02] <didrocks> for the new package
[09:02] <didrocks> it should be easy to get a Feature Freeze Exception
[09:02] <desrt> i don't think vala really follows the normal stable/unstable versioning scheme in a meaningful way
[09:03] <didrocks> desrt: care about opening a bug telling why this package is necessary? Then we will subscribe ubuntu-archive to get a grant
[09:03] <desrt> didrocks: i'm not sure it *is* necessary :)
[09:04] <desrt> but it seems like a relatively easy (and entirely zero-risk) inclusion
[09:04] <desrt> and there's a good chance that dconf will use it
[09:04] <didrocks> desrt: well, let's say "it's good to have and there is no risk"
[09:04] <didrocks> desrt: just open a bug stating that and I will subscribe to get the grant
[09:04] <desrt> ok.  cheers.
[09:04] <desrt> what do i file against, exactly?
[09:05] <didrocks> updating vala now
[09:05] <didrocks> desrt: ubuntu itself
[09:05] <desrt> ok
[09:09] <desrt> didrocks: what do you guess the chances are?
[09:09] <desrt> god i hate launchpad
[09:09] <desrt> every time i try and use it it's a timeout error :(
[09:13] <didrocks> desrt: for the new package? it's high has there is no impact on existing things
[09:14] <didrocks> desrt: but it will be treated probably after beta2 (next thursday)
[09:14] <desrt> of course
[09:15] <desrt> https://bugs.launchpad.net/ubuntu/+bug/553858
[09:15] <desrt> didrocks: thanks
[09:15] <didrocks> desrt: thanks, subscribing now :)
[09:16] <didrocks> I'm updating vala now and try to build something with it
[09:16] <didrocks> desrt: btw, do you know what's the best practice for vala is concerning upstream?
[09:16] <desrt> didrocks: the best test case for vala is vala itself :)
[09:16] <didrocks> I mean, I see some upstream generated the .c file in the tarball, and some not
[09:16] <desrt> didrocks: bugzilla
[09:16] <desrt> oh.  that.
[09:16] <desrt> the widely accepted practice is to have .c in the tarball
[09:17] <desrt> but not in git
[09:17] <didrocks> sure, only in the tarball
[09:17] <didrocks> ok, I'll track down upstreams which don't do that :)
[09:17] <desrt> well
[09:17] <desrt> there's nothing wrong with shipping tarballs without .c
[09:17] <desrt> it's just non-standard behaviour
[09:18] <didrocks> yeah, I mean, I guess that most of the time, they don't really know it's best for packagers
[09:18] <desrt> and everyone, really
[09:18] <desrt> note also: the automake vala rules do this automatically
[09:18] <desrt> add the .c files to the dist tarball
[09:19] <desrt> so the only time you'll encouter .vala-only is in cases were people have homebrew makefiles or have manually worked-around the standard automake behaviour
[09:19] <didrocks> desrt: oh, so they just don't include it
[09:19] <didrocks> right
[09:19] <desrt> if you're going to file bugs with upstreams it might be useful to point that out
[09:19] <desrt> the vala support came with automake version 1.11
[09:20] <didrocks> yeah, I note that down to be able to help upstream making this
[09:23]  * desrt plays with zeromq a bit as a sleep-deferal strategy :)
[09:25] <didrocks> heh :)
[09:26] <desrt> didrocks: thanks for the vala refresh and the zeromq sponsor
[09:26] <didrocks> desrt: y/w ;)
[09:27] <didrocks> desrt: note that the vala refresh, even in universe, should be pushed manually in the repo by an archive admin
[09:27] <didrocks> desrt: so, probably Monday or Tuesdsay with Easter week-end :)
[09:27] <didrocks> (beta freeze is no more a soft freeze, even for universe)
[09:28] <desrt> yes.  that's quite reasonable.
[10:10] <asac> what is needed to get auot login nowadays?
[10:11] <asac> is that gconf setting?
[10:11] <asac> didrocks: ^^
[10:11] <didrocks> asac: no, it's in /etc/gdm/custom.conf. One sec
[10:12] <asac> ok... thats enough info
[10:12] <didrocks> ok :)
[10:12] <asac> we just wondered if thats still it because it doesnt work here for someone
[10:12] <asac> ;)
[10:12] <asac> we will figure
[10:12] <didrocks> asac: hum, it should work :) the live system use that :)
[10:12] <didrocks> ok, good luck!
[10:12] <Nafai> Hi didrocks!
[10:12] <Nafai> <- can't sleep :)
[10:12] <asac> didrocks: yeah. you probably get a bug ;)
[10:13] <didrocks> hey Nafai, you should go to sleep :)
[10:13] <Nafai> I will go back in a bit
[10:13] <didrocks> asac: I'm sure you will file one and assigne to me :)
[10:13] <Nafai> rick mentioned yesterday that I should collaborate with you on UNE stuff
[10:13] <didrocks> Nafai: how was your first official day as Canonical employee? :)
[10:14] <Nafai> Good, just a lot of "meta" work (reading wiki, subscribing to mailing lists, etc)
[10:14] <didrocks> right, first days is that :)
[10:14] <asac> didrocks: seems he had wrong gnome session file for une
[10:14] <asac> didrocks: installed just ubuntu-netbook
[10:14] <asac> why doesnt that install the right one?
[10:15] <didrocks> asac: asac if you install  ubuntu-netbook, the session is set to une if no default session has been set previously
[10:15] <didrocks> asac: DefaultSession=gnome in custom.conf?
[10:15] <vish> hmm , is seb on vac today?
[10:15] <asac> didrocks: =une was in there
[10:16] <asac> just installed ubuntu-minimal ... then ubuntu-netbook
[10:16] <asac> then a few times worked and rebooted
[10:16] <asac> suddenly it was broken
[10:16] <didrocks> asac: hum, apart from the fact they he unlog, set a different one into gdm (and so populate .dmrc), I don't see what changed it
[10:16] <asac> let me ask
[10:17] <didrocks> vish: right, Lorraine and some countries are on national holidays today
[10:17] <asac> didrocks: ok. afte rinstallin ghtere was  no custom.conf
[10:17] <vish> oh , :(
[10:17] <asac> so he added that manually
[10:17] <vish> didrocks: thanks ..
[10:17] <asac> so guess was a user bug
[10:18] <didrocks> asac: yeah, no custom.conf is quite strange, let's blame the user :)
[10:18] <didrocks> vish: some for next Monday btw
[10:19] <fta> where are the keyboard layout options stored?
[10:19] <vish> didrocks: ah, ok.. do you have any info about the humanity update?  seb  was doing it last night , but it seems to have not landed..
[10:19] <asac> didrocks: whats the gnome-session file installed
[10:19] <asac> ?
[10:20] <didrocks> vish: he maybe pushed it but as we are in beta freeze, an archive admin has to accept it
[10:20] <vish> didrocks: ah , the admins .. thanks
[10:20] <didrocks> asac: gnome-session file? ~/.config/gnome-session or /etc/X11/Xsession.d/55gnome-session_gnomerc?
[10:21] <asac> didrocks: wasnt there a .desktop file?
[10:21] <didrocks> oh, the desktop file
[10:21] <didrocks> right, so, concerning session management
[10:21] <didrocks> you have .desktop file in /usr/share/xsessions/
[10:22] <fta> (n-m, gconf)
[10:22] <didrocks> gnome.desktop for the gnome session, you get the failsafe session and when installing une, you got the une.desktop file
[10:23] <didrocks> basically DefaultSession={name_of_the_file_without_extension}
[10:23] <asac> didrocks: yeah. thx. we have to check something here
[10:32] <didrocks> y/w
[10:36] <asac>   * debian/patches/70_glib2.0-gatomic-arm.patch:
[10:36] <asac>     - dropped since that patch was added without details nor reference
[10:36] <asac>       to a launchpad or upstream bug and it's not clear if it's still required
[10:36] <asac>       now with the change done upstream recently
[10:36] <asac> thats ANNOYING
[10:37] <asac> when seb comes back i will have to talk to him
[10:38] <asac> especially because HE added that patch on his own
[10:38] <asac> two uploads before
[10:39] <didrocks> asac: he will be there on Tuesday
[10:41] <asac> i know
[10:50] <asac> didrocks: what should be in custom.conf to start proper une?
[10:51] <asac> we get a full gnome + the launcher if we use une in there
[10:51] <asac> imo this feels not natural ;)
[10:52] <asac> ok we figured
[10:52] <didrocks> asac: just DefaultSession=une, but if user changed it, it's in .dmrc
[10:52] <asac> using une-efl seems to start full gnome + launcher
[10:52] <asac> why does it need to be like that?
[10:53] <asac> thats a bug i guess?
[10:53] <asac> e.g. using just une works
[10:53] <didrocks> asac: right, I told you that we should create a setting package
[10:53] <didrocks> asac: I pinged you and Jamie about it a while ago
[10:53] <asac> yeah sorry. long time ago that was ;)
[10:53] <didrocks> yeah :)
[10:54] <didrocks> asac: that can be easily done. I can have a look next week if you want. You want the same settings than une?
[10:55] <asac> didrocks: is there anything that strikes you that we wpuldnt want from the une setting
[10:55] <asac> ?
[10:56] <didrocks> asac: hum… we hide some items on the menu but it will make sense for you too… and now that go-home-applet is compatible, I don't see anything you won't want
[11:01] <asac> whats going on:
[11:01] <asac> "You are not the bug assignee nor the maintainer of glib2.0 (Ubuntu), and therefore cannot edit this bug's status. "
[11:01] <asac> core devs cant change bug status anymore?
[11:01] <asac> or is that because launchpad is currently read-only?
[11:05] <didrocks> asac: I guess it's a side effect about the read-only yeah
[11:08] <asac> hmm. its not coming back :(
[11:08] <asac> its supposed to be back since 10 minutes ;)
[11:08] <asac> oh its still one more hour
[11:15] <didrocks> yeah  :/
[12:54] <asac> anyone sees the searchplugin being amazon here?
[12:54] <asac> please test http://people.canonical.com/~asac/tmp/ubufox_0.9~rc1-0ubuntu1_all.deb
[12:54] <asac> to see if its fixed there
[12:59] <didrocks> asac: how can I reset to the default one to check if it's fixed?
[13:01] <chrisccoulson> didrocks - you could try a fresh profile in a guest session
[13:02] <didrocks> chrisccoulson: right, good idea, let's try this
[13:02] <chrisccoulson> didrocks - i tried it in french already :P
[13:02] <didrocks> oh ok, no need so :)
[13:02] <chrisccoulson> you can still test it ;)
[13:03] <didrocks> it's ok there :)
[13:03] <zyga> hello
[13:03] <chrisccoulson> asac - did you see the gnome-shell module proposal on desktop-devel-list?
[13:04] <chrisccoulson> they mentioned briefly about the dependency on spidermonkey, but nobody seems to think it's a real issue :/
[13:07] <asac> chrisccoulson: jump in there and say thats a dead end ;)
[13:07] <asac> one second
[13:08] <asac> let me see if i can find the bugzilla bug
[13:08] <chrisccoulson> asac - yeah, i think i will draft a response later, but i want to do it in a way that doesn't get me shot-down by everybody ;)
[13:11] <didrocks> chrisccoulson: spidermonkey is so bad?
[13:11] <chrisccoulson> didrocks - yes
[13:12] <chrisccoulson> didrocks - we're actively trying to reduce the number of dependencies on spidermonkey, to fit more with the new mozilla support model
[13:12] <asac> chrisccoulson: i need to find the upstream bug where they made it clear that they dont want to make any efforts to maintain a stable API even in securty updates
[13:13] <chrisccoulson> asac - ok, thanks, that would be interesting
[13:13] <didrocks> chrisccoulson: hum, right, that doesn't sound good at all
[13:13] <chrisccoulson> ^^^didrocks - asac's response summarizes quite well why we are doing this ;)
[13:13] <didrocks> chrisccoulson: yeah, I was at the UDS discussion about the new mozilla support model
[13:14] <chrisccoulson> didrocks - so, there is no guarantee of API stability even between minor versions, and consider that we are going to move to a model where we follow major updates throughout the life of a release....
[13:14] <didrocks> so, that's weird that they rely on a mozilla component
[13:14] <chrisccoulson> ....that would make something like gnome-shell unsupportable
[13:14] <didrocks> right
[13:15] <asac> mozilla bug 506890
[13:15] <asac> read that and there you go
[13:16] <asac> chrisccoulson: ^^
[13:16] <asac> reading this ... everyone using mozjs needs to go somewhere else
[13:16] <asac> if they ask "where?" ... i dont have an answer
[13:16] <asac> but the answer is definitly not "stay with mozjs"
[13:16] <asac> they should complain on that bugt
[13:17] <asac> maybe having upstreams complain that they wasted all their effort etc. will change their minds
[13:17] <chrisccoulson> asac - thanks, that's interesting to read
[13:17] <asac> i tried to discuss this in various ways
[13:17] <asac> distro pushing doesnt help
[13:17] <asac> only upstream folks going to that bug might help
[13:17] <asac> they should appeal to mozillas foundation approach ... e.g. they want to be the good guys and want to make the web a better place
[13:17] <asac> imo having a js lib is the way to go
[13:17] <asac> maybe if they notice how many folks they bust they will move a bit
[13:18] <asac> chrisccoulson: the folks commenting there are all senior ... VP etc.
[13:18] <asac> its not that its some random developers saying that
[13:18] <asac> its their official strategy in order to compete against chrome
[13:19] <asac> similar folks should go to chrome and tell them that v8 should become stable
[13:19] <asac> they have the same answer: "dont use us  .. we dont care if there is no other solution ... but its not us" ;)
[13:19] <zyga> asac: may I ask what are you talking about? js library?
[13:20] <asac> yes ...
[13:20] <asac> read above
[13:20] <asac> i think the right way would be someone coming up with a small subset of essential js funcs
[13:20] <asac> and then writing a wrapper for mozjs
[13:20] <zyga> I read but I'm a little puzzled, is the question about having a stable (api-wise) js library?
[13:20] <asac> that can be maintained in case they break api
[13:21] <asac> zyga: yes. if that exists now ( i think there was something for gnome now) ... thats the way to go
[13:21] <asac> we cant really let anything in the archive with a straight face that uses mozjs or v8
[13:21] <zyga> asac: what about jscore from webkit?
[13:22] <zyga> asac: it's not v8 but it's was good enough for a long while
[13:22] <asac> havent checked with them
[13:22] <asac> maybe thats a choice
[13:22] <asac> we should try
[13:22] <asac> but we should first check if its stable with them ;)
[13:22] <zyga> asac: what's the target for that library (I assume it's not a browser)
[13:22] <asac> desktop apps needing js
[13:22] <zyga> asac: I think that's your choice then
[13:22] <asac> everyone uses mozjs ... and complains that we dont make a system lib out of it (e.g. we make it intentionally hard to use it=)
[13:23] <asac> right. i think i pointed a few folks to webkit in the past
[13:23] <zyga> asac: what's the point with mozilla not willing to make it stable api-wise
[13:23] <zyga> (disregarding the fact that mozilla has horrible api that doesn't look like anything else)
[13:23] <asac> but then webkit has problems on its own wrt to stability/security updates from what i was told by security team
[13:23] <asac> zyga: go to that bug and complain
[13:23] <asac> i dont see it
[13:23] <asac> zyga: i tried to discuss a small subset api
[13:23] <asac> but they are not even willing to do that
[13:24] <zyga> asac: jscore is pretty small, do have a look at that
[13:24] <zyga> and it's pure C++
[13:24] <asac> e.g. i would be willing to do a separate source package ... with --build-stable-api-only
[13:24] <asac> if that option existed
[13:24] <zyga> no nifty quirky runtimes
[13:24] <asac> and mozjs developers thought it was a good eceision
[13:24] <asac> but hen that bug above made it clear that noone with seniority in mozilla wants that
[13:24] <zyga> asac: I think webkit is not going forward so rapidly and they don't put everything and the kitchen sink inside
[13:25] <asac> zyga: C++ APIs aren't really famous for its easy ABI stability ;)
[13:25] <zyga> mozilla is more like 'ooh, we have this shiny new js function'
[13:25] <zyga> asac: I know that C++ is not perfect but C++ WITH some klunker like Qt or mozilla code is worse than plain C++
[13:25] <asac> but all js solutions are C++ ... so we just need to find someone who says: yes, we have policy to maintain ABI/API stability for security/stability updates
[13:25] <zyga> asac: what about apple
[13:26] <zyga> asac: apple uses jscore for safari
[13:26] <asac> they use the full webkit stuff ... dont they?
[13:26] <zyga> asac: that sounds/smells/feels like 1) stable 2) maintained 3) secured
[13:26] <asac> imo they will be next feeling pressured to boost their performane most likekly
[13:26] <zyga> asac: yes
[13:26] <asac> with all browser having to catch up with chromium
[13:26] <zyga> asac: but the jscore is a part of the plaftorm (AFAIR, i'd need to check that)
[13:27] <zyga> so breaking the api is a no-no for them
[13:27] <asac> thats what make mozilla drop all this ... as they dont see competitive when they have to keep js api stable
[13:27] <asac> zyga: please check that
[13:27] <asac> zyga: also find whatelese is using htat in the platform
[13:27] <asac> if its just one or too rdepends its easy for them to just roll all at the same time
[13:27] <zyga> asac: I think lots
[13:27] <zyga> asac: basically apple commited to this by putting webkit in the official apis for everything
[13:28] <zyga> from iphone/ipad to the desktop
[13:28] <zyga> I'll try to give you a nice link, wait
[13:28] <fta> funny, if i open https://bugs.edge.launchpad.net/ubuntu/+source/xinit/+bug/320886 both in ff and ch, ff lacks the comments i made ~1h ago
[13:28] <asac> zyga: does jscore work on windows?
[13:28] <zyga> asac: yes
[13:29] <asac> stuff like couchdb need that etc.
[13:29] <zyga> asac: it's on safari for windows after all
[13:29] <asac> ydeah. anyway. i usuallypoint folks to webkit if they want something
[13:30] <asac> so i will just continue to do that ... cant be worse than mozjs
[13:30] <zyga> asac: it's better IMHO
[13:30] <asac> chrisccoulson: so everyone wanting to use mozjs should go jscore of webkit
[13:30] <zyga> mozilla has the momentum but webkit has the efficiency and focus on being slim
[13:30] <asac> otherwise they cant go in main ... and we will not export mozjs as system lib
[13:30] <asac> if they want mozjs they should complain on the upstream bug
[13:30] <asac> chrisccoulson: ^^
[13:31] <zyga> asac: http://webkit.org/projects/javascript/index.html
[13:31] <asac> kk
[13:32] <zyga> asac: jscore builds to a separate .so already
[13:32] <zyga> asac: so it's not really bound to webkit
[13:33] <zyga> asac: I'm not 100% up-to-date with this (I's 1.5 year old experience) but if you want to ship webcore + jscore (webkit) + some apps then you should not need to duplicate everything
[14:25] <baptistemm> someone can approve my mail in ubuntu-devel? thanks
[14:44] <didrocks> well, time for me to take an early week-end, taking the train to help my brother moving this week-end
[14:45] <didrocks> see you on Tuesday ;)
[14:47] <LaserJock> kenvandine: so are all the CPU-at-100% bugs supposed to be fixed for gwibber now?
[14:58] <kenvandine> LaserJock, no
[14:58] <kenvandine> :(
[14:58] <LaserJock> k
[15:28] <rickspencer3> kenvandine, hi
[15:29] <kenvandine> hey rickspencer3
[15:29] <kenvandine> hey seb128
[15:29] <rickspencer3> release meeting in 30 minutes, right?
[15:29] <seb128> hello kenvandine rickspencer3
[15:29] <seb128> how are things going today?
[15:29] <kenvandine> i think it is in an hour
[15:29] <kenvandine> i should check :)
[15:29] <seb128> I noticed none of the dx or ols went through
[15:29] <rickspencer3> kenvandine, let's ask for some help with this couch<->keyring<->gwibber bug
[15:30] <kenvandine> yeah
[15:30] <kenvandine>           value = gnomekeyring.find_items( gnomekeyring.ITEM_GENERIC_SECRET, {"id": str("%s/%s" % (account["_id"], key))})[0].secret
[15:30] <kenvandine> i replaces that with value = "mypassword"
[15:30] <kenvandine> and no load
[15:30] <kenvandine> i tried to get the debugger in there and failed
[15:30] <kenvandine> in python-gnomekeyring
[15:30] <seb128> do you get the bug using a small pygtk test too?
[15:30] <kenvandine> can't figure out where it is happening
[15:30] <seb128> or only in desktopcouch context?
[15:31] <rickspencer3> that's a good question
[15:31] <rickspencer3> hi seb128, btw
[15:31] <rickspencer3> ;)
[15:31] <kenvandine> no, but i can't see how this could be related to couch
[15:31] <rickspencer3> seb128, I tried to write a minimal repro script last night by calling desktopcouch
[15:31] <rickspencer3> sometimes is repro'd, sometimes not
[15:31] <kenvandine> and duplicating this would be a fair bit of code
[15:32] <kenvandine> rickspencer3, but we would want to something that uses threads the same way as gwibber-service
[15:32] <rickspencer3> kenvandine, but could we not write a program that ask the keyring for something
[15:32] <kenvandine> but without using desktopcouch
[15:32] <rickspencer3> like a 2 line python script
[15:32] <rickspencer3> see if that can trigger it
[15:32] <kenvandine> rickspencer3, that wouldn't break it
[15:32] <kenvandine> it is threading related
[15:32] <rickspencer3> so call it from a thread
[15:32] <rickspencer3> we need a reliable repro for this
[15:33] <rickspencer3> I can give that a shot
[15:33] <seb128> kenvandine, duplicating what?
[15:33] <kenvandine> there is no couch code at all in this part of gwibber
[15:33] <seb128> just write a few liners calling gnomekeyring.find_items
[15:33] <seb128> to see if python-gnomekeyring bugs
[15:33] <rickspencer3> seb128, I'll try now
[15:33] <kenvandine> we would need to do it with python multiprocessiing
[15:33] <seb128> if you think the issue is this call
[15:33] <kenvandine> calling it from a script is fine, gotta call it from a thread
[15:33] <rickspencer3> I can put it on a thread and do it in a loop on a thread or something
[15:33] <seb128> so it's a multuprocessing issue?
[15:34] <kenvandine> yes
[15:34] <seb128> urg
[15:34] <seb128> good luck with that
[15:34] <dobey> it's a thread locking issue
[15:34] <seb128> I'm not even sure gnome-keyring is meant to work in those case
[15:34] <kenvandine> dobey's work around was by using gtk.gdk.lock
[15:34] <seb128> lot of libs are not
[15:35] <dobey> the exact same keyring call works fine if i just do it directly in interactive python (without threads, just making the keyring calls)
[15:35] <kenvandine> and it is a real pain that i can't get any trace that shows keyring access at all
[15:35] <dobey> but inside threads, bam, lock.
[15:35] <dobey> at least, if there's a glib main loop
[15:35] <dobey> it's probably ok from a thread without a glib main loop
[15:35] <dobey> though i haven't tested it
[15:36] <dobey> kenvandine: what does the trace show? dbus junk?
[15:36] <rickspencer3> dobey, do you think you could write a minimal repro script?
[15:36] <kenvandine> mostly curl actually
[15:36] <kenvandine> dobey, but it doesn't show anything remotely keyring related, afaict
[15:37] <dobey> rickspencer3: probably, yes. shouldn't be hard
[15:37] <seb128> not sure if that's a keyring bug
[15:37] <kenvandine> seb128, chad has found a version of libgnome-keyring0 that he thinks works with desktopcouch
[15:38] <seb128> or a desktoptouch
[15:38] <kenvandine> but that version doesn't fix gwibber
[15:38] <kenvandine> but it does seem to fix desktopcouch
[15:38] <seb128> which one?
[15:38] <seb128> well
[15:38] <seb128> does the update from yesterday fix desktopcouch?
[15:38] <dobey> desktopcouch *might* just be getting lucky
[15:38] <kenvandine> 2.29.4git20100224-0ubuntu2
[15:38] <seb128> k
[15:38] <kenvandine> seb128, chad said it didn't
[15:38] <seb128> so it's the new codebase
[15:38] <seb128> not 2.28
[15:39] <seb128> the diff is not that much to review
[15:39] <dobey> because it has a weird function that does some main thread check thing
[15:39] <kenvandine> but that version is still broken for gwibber :/
[15:39] <dobey> and it could be that the keyring calls might just always end up being from the main thread anyway in some cases
[15:39] <dobey> which would mask the problem
[15:39] <seb128> good luck with that
[15:40] <dobey> alright, let me get fully awake in the next few minutes, and i'll write a simplified test case
[15:40] <seb128> dobey, do you think it's a keyring bug?
[15:41] <seb128> or it should just be used as it's used now?
[15:41] <dobey> seb128: i think a change to libgnome-keyring is exposing problems in existing code in apps using it
[15:41] <seb128> change = rewrite
[15:41] <seb128> 2.28 to 2.29 is basically a rewrite
[15:41] <seb128> gnome-keyring uses dbus now
[15:41] <dobey> seb128: mainly because threading in gtk+/glib is insane
[15:42] <seb128> the lib is just a wrapper for compatibility
[15:42] <dobey> if people don't get it right
[15:42] <kenvandine> dobey do you think we should be looking at python-gnomekeyring instead of libgnome-keyring0?
[15:42] <dobey> kenvandine: no
[15:43] <kenvandine> ok
[15:44] <dobey> although, i don't think any minor change is going to fix the problem either, if it's switched to using dbus-glib
[15:44] <dobey> and it sems it has, which is the cause of all these problems
[15:45] <seb128> it seems to use libdbus rather
[15:45] <seb128> but as said before yes that's new
[15:45] <seb128> it used to use sockets
[15:45] <seb128> and it's using dbus since this cycle
[15:48] <kenvandine> i love the beta-2 burndown :)
[15:48] <kenvandine> way below the line :)
[15:49] <dobey> heh
[15:50] <dobey> eh, dbus is just an abstraction over sockets
[15:50] <dobey> anyway, let me write simple test cases
[15:52] <seb128> bbl
[16:24] <dobey> huh
[16:24] <dobey> wtf :)
[16:25] <dobey> i wonder if i somehow installed a keyring update that works now
[16:27] <kenvandine> ha
[16:28] <kenvandine> dobey, seb128 did upload another patch that did fix it for gvfs yesterday
[16:28] <dobey> HA!
[16:28] <kenvandine> but not for gwibber :)
[16:28] <dobey> bad gwibber!
[16:29] <dobey> class Dispatcher(dbus.service.Object, threading.Thread):
[16:29] <dobey> formula for BOOM
[16:29] <kenvandine> ?
[16:29] <dobey> it's mixing up main loop and thread interaction all over the dispatcher
[16:30] <rickspencer3> dobey, could I ask you to log a bug on that and briefly describe why it's bad a potential work around?
[16:30] <rickspencer3> and dobey, do you think such a thing could be implicated in the 100% bug?
[16:30] <kenvandine> or comment on bug 554005
[16:30] <dobey> rickspencer3: yes, this definitely could cause threadlocks
[16:30] <rickspencer3> yeah, that's better
[16:33] <dobey> hmm
[16:36] <dobey> kenvandine: how do i run tests in gwibber source?
[16:36] <kenvandine> tests...
[16:36] <kenvandine> we need a test suite :/
[16:36] <kenvandine> that is on my todo list for next cycle
[16:37] <dobey> ok
[16:37] <kenvandine> gwibber desparately needs it
[16:37] <dobey> i think i have a proper fix
[16:37] <dobey> i'll push and you can try
[16:37] <kenvandine> woot
[16:37]  * kenvandine waits to hug dobey...
[16:39] <dobey> kenvandine: merge lp:~dobey/gwibber/gwibber-keyring-unthreaded and see if it's fixed for you
[16:39]  * dobey thinks it should be
[16:40] <Nafai> morning all
[16:40] <kenvandine> dobey, ok... i just tried nearly the same thing and it didn't fix it
[16:41] <kenvandine> i didn't do this
[16:41] <kenvandine> -gobject.threads_init()
[16:41] <dobey> kenvandine: well is it fixed? i ran gwibber-service from my tree and it wasn't eating any cpu, but i don't know if that's because it fixes it or because i don't have anything in the keyring
[16:41] <rickspencer3> hi Nafai
[16:42] <dobey> kenvandine: but desktopcouch-service was grinding my cpu hard
[16:42] <rickspencer3> Nafai, should be a quiet day today, because lot so euro-folks are on holiday
[16:42]  * Nafai nods
[16:43] <Nafai> I talked with didrocks for a moment in the night when I had a bit of a "I can't sleep" moment, we're going to sync up on Tuesday
[16:43] <rickspencer3> Nafai, awesome
[16:43] <rickspencer3> Nafai, apparently Dx has a bug with keyboard access for indicators
[16:43] <rickspencer3> maybe you could ask if they need some help with that?
[16:44] <Nafai> Sure thing
[16:44] <rickspencer3> apparantly if you key into an indicator, and then hit escape, you are rather screwed
[16:44]  * Nafai heads over to #ayatana
[16:44] <rickspencer3> I really want good key access for indicators in Lucid ;)
[16:45] <dobey> kenvandine: did my branch fix it? :)
[16:45] <kenvandine> dobey, it seems fixed!
[16:45] <dobey> yay me!
[16:45] <kenvandine> sorry, busy in release meeting too :)
[16:45] <kenvandine> yay dobey
[16:45]  * kenvandine hugs dobey
[16:45] <kenvandine> let me test a bit before i upload
[16:45] <dobey> kenvandine: tell them to put the new ubuntuone-client in the archive :)
[16:46] <dobey> kenvandine: one second, and i'll re-submit my merge proposal :)
[16:54] <dobey> kenvandine: https://code.edge.launchpad.net/~dobey/gwibber/gwibber-keyring-unthreaded/+merge/22704
[16:54] <kenvandine> thx dobey
[16:54] <kenvandine> dobey, he said he would look at u1 client later today
[16:54] <dobey> yay
[16:54] <dobey> and now, for some lunch :)
[16:54] <kenvandine> dobey, no code change in that merge proposal, right?
[16:55] <dobey> kenvandine: hrmm? that proposal is for the branch i just had you test
[16:55] <kenvandine> ok
[16:55] <kenvandine> just checking
[16:55] <dobey> so it removes the threading from Dispatcher, yes :)
[16:56] <dobey> unless i'm confused and you're asking about u1-client package or something
[17:35] <fta> is there a way to unlock the keyring permanently? i mean, for a home desktop in autologin mode, there's no point in asking a password to start evolution
[17:45] <tgpraveen1> fta: only way is to set blank password for it or something like that iirc
[17:49] <fta> well, it's worked on my previous desktop, but in my fresh install of lucid, i can't find where it's supposed to be done
[17:49] <fta> -'s
[17:59] <Nafai> rickspencer3: looks like they have a fix in the works, do you have any other high priority things I should look at today?
[18:06] <tgpraveen1> fta: previous desktop was pre karmic? it used to work for me alos back then
[18:06] <tgpraveen1> though i dont know how. if you ever do get a fix for this pls do tell me
[18:14] <seb128> rickspencer3, hey
[18:14] <seb128> rickspencer3, why did you reopen the libgnome-keyring bug?
[18:15]  * Nafai takes an early lunch
[18:15] <rickspencer3> seb128, because gwibber was still busted and we needed on for the release meeting
[18:15] <seb128> k
[18:15] <rickspencer3> seb128, you can change it back though
[18:15] <seb128> can we get an another bug?
[18:15] <rickspencer3> seb128, I already did that
[18:15] <seb128> I feel we are mixing issues in the same bug
[18:15] <rickspencer3> seb128, yes
[18:15] <seb128> which makes things harder to work on an track
[18:15] <rickspencer3> I just haven't set the keryring back to fix-released yet
[18:16] <seb128> ok good
[18:16] <rickspencer3> but we've opened a new bug and, etc
[18:16] <seb128> I was just going to hint we should open a new bug
[18:16] <seb128> rather than keep using this one
[18:16] <seb128> excellent
[18:16] <seb128> thanks
[18:16] <seb128> did you get a testcase while I was not there?
[18:17] <seb128> or did you make any progress on the issue
[18:18] <kenvandine> we have a branch of gwibber that stops using threads in the dispatcher
[18:18] <kenvandine> which fixes the load problem... but breaks something else
[18:19] <dobey> hrmm
[18:20] <dobey> kenvandine: does it break something, or are other issues just more apparent now?
[18:21] <kenvandine> no, it breaks functionality
[18:21] <kenvandine> loading_complete seems to never get called
[18:21] <kenvandine> which is from the timeout_add
[18:22] <dobey> i think it's another thread vs. mainloop issue
[18:23] <dobey> but i don't really see from reading the code, how it ever would have worked :)
[18:24] <kenvandine> it worked fine :)
[18:24] <kenvandine> and it still works fine if i add the gobject.threads_init() back
[18:24] <kenvandine> but of course then i get the lock
[18:26] <rickspencer3> Nafai, sort of
[18:26] <rickspencer3> Nafai, https://launchpad.net/bugs/357673
[18:26] <rickspencer3> the deal here is that this is fixed in the kernel, but not on the desktop
[18:26] <dobey> kenvandine: how can it work fine if it's using 100% cpu and thread locked? :)
[18:27] <kenvandine> dobey, it still works... just makes my laptop very hot :)
[18:27] <rickspencer3> if you could look into this and at least see where the fix needs to be made, that would be helpful
[18:28] <rickspencer3> Nafai, this one looks rather harmful for certain users as well:
[18:28] <rickspencer3> https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/548891
[18:28] <dobey> kenvandine: weird
[18:28] <dobey> kenvandine: but it clearly marks this as another thread vs. mainloop issues
[18:28] <kenvandine> yes
[18:28] <dobey> and i really have no idea how it actually managed to work in the first place :)
[18:38] <robbiew> seb128: ping
[18:41] <robbiew> can anyone tell me how to change the background of the login screen?  I apparently did for Karmic, and cannot UNDO for Lucid :/
[18:42] <jcastro> I have a machine that updated to lucid but is still stuck with the karmic wallpaper in gdm so I would like to know how to do that too
[18:44] <seb128> robbiew, sudo -u gdm gnome-appearance-properties or gconf-editor
[18:45] <seb128> robbiew, you can also remove .gconf in /var/lib/gdm
[18:45] <robbiew> thnx
[18:45] <seb128> you're welcome
[20:04] <Nafai> back :)
[20:08] <rickspencer3> hey Nafai
[20:08] <rickspencer3> wb
[20:08] <Nafai> thanks
[20:09] <Nafai> I saw the two bugs you shared after I stepped away
[20:10] <Nafai> Of course the thinkpad one isn't exhibited on *my* Thinkpad :)
[20:13] <rickspencer3> bummer
[20:14] <rickspencer3> Nafai, so when you use hardware buttons to control volume, you get notifications?
[20:14] <Nafai> Yeah
[20:14] <rickspencer3> *sigh*
[20:14] <Nafai> I have a T-61p, which might have a better ACPI implementation
[20:14] <rickspencer3> ok, what about the no keyboard for gdm in kvm one?
[20:14] <rickspencer3> can you repro that?
[20:15]  * Nafai looks
[20:16] <Nafai> I can install VMware and try if you like
[20:27] <rickspencer3> Nafai, well, what else is on your list?
[20:28] <Nafai> other than a rhythmbox bug that MacSlow says he is looking at a potential notify-osd fix for, not mcuh really
[20:28] <rickspencer3> then ya', it would be helpful to get kvm set up and see if you can repro that bug
[20:29] <rickspencer3> also, kenvandine can probably use some help testing gwibber and related fixes
[20:29] <Nafai> ok
[20:29] <kenvandine> :)
[20:29] <kenvandine> Nafai, you a python threading guru by chance?
[20:32] <Nafai> kenvandine: not really, but I'm good enough at Python to take a stab. :)  All concurrency I've done in Python has been asynchronous with Twisted or glib :)
[20:37] <kenvandine> Nafai, if you don't mind, take a look at this
[20:37] <kenvandine> https://code.edge.launchpad.net/~dobey/gwibber/gwibber-keyring-unthreaded/+merge/22704
[20:38] <Nafai> sure
[20:38] <kenvandine> it is to deal with threadlock and the keyring
[20:38] <dobey> hmm
[20:39] <kenvandine> problem is... removing the gobject.threads_init() means it never calls the callback on complete
[20:39] <dobey> kenvandine: do i need to help fix the other issues too?
[20:39] <kenvandine> so anything that depends on that, is busted
[20:39] <kenvandine> but it fixes other issues
[20:39] <kenvandine> dobey, if you can figure out why that callback never gets called :)
[20:39] <kenvandine> that is the only real issue
[20:39] <dobey> because it's being called from a thread
[20:40] <kenvandine> so?
[20:40] <kenvandine> the threads complete
[20:40] <kenvandine> all the individual operations complete
[20:40] <dobey> so it's calling something that doesn't exist on that thread
[20:40] <kenvandine> humm
[20:40] <kenvandine> well... this is the weirdest part
[20:41] <kenvandine> when the next scheduled refresh starts, the first thing that happens is loading_complete gets called
[20:41] <kenvandine> it's like waiting
[20:45] <Nafai> btw, does anyone have a recommendation for a good netbook?  I'm considering buying one.  My wife has an Acer Aspire one that I feel is a little flimsy, so I'd like other options
[20:55] <kenvandine> Nafai, i don't
[20:55] <kenvandine> ok... i might have fixed gwibber now
[20:55] <Nafai> Yay
[20:56] <Nafai> I've just been looking at the API docs for this stuff :)
[20:56] <Nafai> I've got a ton to learn
[20:56] <kenvandine> threading.Thread.__init__(self, target=loop)
[20:56] <kenvandine> setting the mainloop there in MapAsync seems to do the trick
[20:56] <Nafai> let me know if you need me to test
[20:56] <kenvandine> the is no end to the google search results for people complaining about problems with threading in python :)
[20:56] <kenvandine> Nafai, thx
[20:57] <LaserJock> Nafai: my only netbook is a AA1, which I like, maybe you need an iPad :-)
[20:57] <Nafai> LaserJock: haha
[20:57] <Nafai> Now I wouldn't mind a tablet for web surfing and games, since my laptop doesn't leave the office now its primary function is work.  But...no thanks.
[20:58] <LaserJock> I just tried out Gmail's tablet UI, it might not be so bad
[20:58] <Nafai> yeah, I saw some screenshots
[20:58] <LaserJock> but I would require a terminal and that's where I think the iPad and I would part ways
[20:58] <Nafai> probably
[20:59] <Nafai> and I couldn't easily run Emacs on it, either :)
[20:59] <LaserJock> hmm
[20:59] <LaserJock> emacs doesn't run "easily" on a lot of things I use
[20:59] <LaserJock> but when you get the OS loaded initially it seems to go ok ;-)
[21:00] <kenvandine> dobey, mind reviewing my fix?
[21:01] <dobey> kenvandine: which one?
[21:01] <Nafai> I had it running on my G1 in a Debian chroot
[21:01] <Nafai> that was interesting :)
[21:01] <dobey> hrmm
[21:02] <kenvandine> threading.Thread.__init__(self, target=loop)
[21:02] <kenvandine> is the gist of it
[21:02] <kenvandine> in class MapAsync
[21:02] <kenvandine> setting it to use the same mainloop
[21:02] <kenvandine> dobey, that is on top of your branch
[21:04] <dobey> kenvandine: MapAsync doesn't have a loop argument
[21:04] <dobey> kenvandine: url to your diff? :)
[21:04] <kenvandine> it does now :)
[21:04] <kenvandine> one sec
[21:06] <kenvandine> http://pastebin.ubuntu.com/408282/
[21:06] <kenvandine> dobey, ^^
[21:06] <rickspencer3> Nafai, netbook = Dell mini 10v
[21:06] <rickspencer3> the "v" is important
[21:06] <Nafai> I seem to remember you saying you had wireless problems...is that because you got the non-v?
[21:06] <rickspencer3> Nafai, when you run gwibber, do you get your CPU pegged at 100% sometimes?
[21:07] <dobey> kenvandine: also i don't think that works how one expects it to
[21:07] <dobey> kenvandine: i'm surprised that works...
[21:07] <kenvandine> why?
[21:07] <kenvandine> you didn't think this could have worked before :)
[21:07] <dobey> grr, pydoc docs suck.
[21:08] <dobey> well, at this point i am just classifying gwibber code as 'magic' :)
[21:08] <Nafai> rickspencer3: I haven't noticed because the last time I ran gwibber it was crashing on me with some desktopcouch error and I seem to remember you guys talking about it, so I haven't tried it
[21:08] <Nafai> dobey: Usually that's the case when you use threads :)
[21:08] <rickspencer3> Nafai, so do a distupgrade
[21:08] <rickspencer3> the crashers should be fixed
[21:08] <dobey> Nafai: no no. i ♥ threads
[21:08] <dobey> Nafai: and i still think gwibber is magic :)
[21:09] <Nafai> yeah, I just re-launched after this morning's upgrade and it launched fine, no CPU pegging yet
[21:09] <Nafai> dobey: async :)
[21:09] <rickspencer3> but kenvandine and dobey are trouble shooting a threading bug, and if you can repro it, I'd like you to help with testing
[21:09] <dobey> target is the callable object to be invoked by the run() method. Defaults to None, meaning nothing is called.
[21:09] <dobey> kenvandine: ^ that's why i am amazed that works
[21:09] <kenvandine> ok... so this re-introduced the CPU load problem :)
[21:09] <rickspencer3> Nafai, ok .. then please do this:
[21:09] <kenvandine> humm... that isn't what i read
[21:09] <rickspencer3> 1. go to your gwibber settings
[21:09] <rickspencer3> 2. pick identical
[21:09] <kenvandine> but now it works again as expected with plaintext passwords
[21:10] <rickspencer3> 3. change the password, then change it right back to the right one
[21:10] <rickspencer3> 4. click save
[21:10] <dobey> kenvandine: so your fix brought the cpu usage back? :)
[21:10] <rickspencer3> then reboot and see if you get the pegging problem
[21:10] <dobey> hah
[21:10] <kenvandine> yup :)
[21:10] <kenvandine> damn
[21:10] <kenvandine> but now the operations complete :)
[21:10] <kenvandine> shit!
[21:10]  * kenvandine is getting frustrated!
[21:10] <rickspencer3> kenvandine, I can see that you are close
[21:11] <kenvandine> dobey, but without that, even not using the keyring it never called loading_complete
[21:11] <dobey> kenvandine: haha, thraedlocks ftf
[21:11] <rickspencer3> I'm guess there is just a tad more complexity and you just have a bit more to tease out
[21:11] <dobey> ok, let me poke at the code
[21:11] <kenvandine> and google is no help... full of people having the same problems and no solutions
[21:11] <kenvandine> dobey, thx!
[21:11] <kenvandine> dobey, you clearly understand this way better than me :)
[21:13] <dobey> kenvandine: at some point in time, i made it a point to try and understand threads + glib/gtk+ :)
[21:13] <Nafai> ok, I'm getting the CPU pegging when I added my identi.ca account :)
[21:13] <kenvandine> Nafai, yay!
[21:13] <kenvandine> now hang tight to test fixes :)
[21:13] <Nafai> sure thing
[21:13] <kenvandine> or poke at code to make it not suck... your choice
[21:13] <kenvandine> :)
[21:14] <kenvandine> but i think dobey will fix it before we could :)
[21:14] <kenvandine> dobey, from what i have found on google... not many people understand this, at least in python
[21:15] <Nafai> yeah, probably
[21:15] <dobey> kenvandine: most people don't understand it in C either
[21:16] <Nafai> rickspencer3: so the 10v isn't available any more, supposedly the current mini 10 supercedes it.  what was the reason for the "v"?
[21:16] <jcastro> you want the v if it's a 10
[21:16] <jcastro> the normal 10 was pulsbo
[21:16] <kenvandine> dobey, your right, clearly target= is wrong
[21:16] <jcastro> you want a mini 1012 if you want a dell
[21:16] <kenvandine> bad google juice there
[21:17] <jcastro> Nafai: just make sure it doesn't have a GMA500.
[21:17] <dobey> kenvandine: yeah, and calling mainloop.run() on a running mainloop isn't going to be useful
[21:17] <dobey> GMA500 is the debil
[21:17] <jcastro> Nafai: ime the hp mini's have better keyboards, and I find the touchpad on the dell netbook basically unusable
[21:18] <dobey> at least not from another thread
[21:18] <Nafai> jcastro: oh, I do remember playing with an HP, the keyboard did seem nice
[21:19] <rickspencer3> jcastro, the touchpads on the Dell mini's were fixed by tsleliot like 6 months ago
[21:19] <rickspencer3> they work quite fine now
[21:19] <jcastro> rickspencer3: I have a problem with it even after the fix, I think it's just the built in buttons don't jive with me
[21:19] <rickspencer3> meh
[21:20] <rickspencer3> they work find
[21:20] <rickspencer3> fine, even
[21:20] <rickspencer3> though if you can't get the "v", there's nothing to discuss
[21:20] <rickspencer3> you don't want poulsbo graphics :(
[21:20] <Nafai> It says it has an Intel NM10 Express graphics card
[21:21] <rickspencer3> Dell is quite supportive of Ubuntu and FOSS, so I default to them
[21:21] <jcastro> the mini 1012 has all the new pinetrail hotness, but they don't offer that on their ubuntu store yet
[21:21] <Nafai> yeah, the one I'm looking at comes with XP
[21:22] <dobey> i wish fujitsu would make a new U without gma500
[21:22] <jcastro> Nafai: when you decide on one lmk, I am looking for an ubuntu netbook for my dad
[21:22] <Nafai> sure thing
[21:22] <jcastro> but I am waiting on dell to refresh their options.
[21:23] <Nafai> I might be until after UDS, though I'll probably wish it was before when I get there :)
[21:23] <LaserJock> you should get one with Windows 7 on it, it makes you appreciate Ubuntu that much more ;-)
[21:24] <Nafai> :)
[21:24] <LaserJock> I spent hours and hours and hours on mine just to get iTunes set up, I can't believe they actually sell that stuff
[21:24] <rickspencer3> Nafai, are you getting the Gwibber 100% bug?
[21:25] <Nafai> yeah, I was until I quit gwibber :)
[21:25] <kenvandine> LaserJock, :-D
[21:26] <dobey> ugh, reading python modules written in C that wrap C libs hurts
[21:28] <Nafai> dobey: too much refs and unrefs and the like?
[21:28] <dobey> Nafai: too many weird line breaks and the like
[21:28] <dobey> and all the weird PyExc names and stuff
[21:28] <Nafai> ah
[21:28] <Nafai> I wish there was a decent FFI that was used more
[21:29] <Nafai> One thing I like about Haskell.  You wrap C code by written Haskell code
[21:30] <dobey> heh
[21:31] <vish> hmm , this README needs to be removed/modified : /usr/share/notify-osd/icons/hicolor/scalable/status/README
[21:31] <dobey> hrmm
[21:31] <dobey> i think i might need to call C from python
[21:32] <vish> iirc it was either pitti or macslow who made the last upload
[21:38] <dobey> where the heck is glib.threads_init even defined
[21:38] <dobey> grr
[21:40] <dobey> kenvandine: so this sucks
[21:41] <dobey> kenvandine: so i think the 'correct' answer here, is that we need to make a fairly large fix to pygobject :(
[21:41] <kenvandine> :/
[21:42] <dobey> kenvandine: because it doesn't currently wrap gthread.[ch], except for calling g_thread_init() for threads_init()
[21:42] <dobey> kenvandine: and all the mutex stuff is in there
[21:43] <kenvandine> that sounds sub-optimal... and like fixing that would be useful
[21:43] <kenvandine> but yikes!
[21:44] <dobey> yeah
[21:45] <dobey> kenvandine: we might be able to use ctypes to load libgthread and map/call a few methods that we need, as an interim fix though
[21:48] <kenvandine> all this to store passwords in the keyring :)
[21:48] <dobey> no
[21:48] <dobey> the keyring thing is just a little bump. i don't know how gwibber wasn't already having these problems
[21:49] <dobey> i think it was but nobody noticed them until now :)
[21:49] <kenvandine> without the call to gnomekeyring.find_items_sync, everything is fine
[21:51] <dobey> for different perceptions of fine i guess :)
[21:51] <kenvandine> hehe... well it all worked with no CPU load problems... but was insecure, sure
[21:53] <dobey> i mean, i am surprised that it would have worked without threadlocking
[21:55] <dobey> and desktopcouch threadlocks for me still
[21:56] <kenvandine> yeah, chad has found an older version of libgnome-keyring0 that doesn't cause that
[21:56] <kenvandine> 2.29.4git20100224-0ubuntu2
[21:56] <kenvandine> that is the last version that didn't expose this
[21:57] <kenvandine> but, that version doesn't fix gwibber
[21:57] <dobey> well it's weird, because i wrote a test script with the intention of locking up
[21:57] <dobey> and it runs just fine :(
[21:57] <kenvandine> :(
[21:58] <dobey>     Thread(target=get_kr_entries).start()
[21:58] <dobey> all that does is find_items_sync() and return them
[21:58] <dobey> and it succeeds
[22:06] <kenvandine> dobey, so you think those are the two possible fixes? fix pygobject or map the C methods ourself in gwibber?
[22:11] <dobey> yes
[22:12] <dobey> so i've got myself a threadlock now in a simple test
[22:14] <dobey> hmm
[22:21] <dobey> kenvandine: http://pastebin.ubuntu.com/408313/
[22:47] <dobey> kenvandine: or the other option is to just remove all the threading stuff, and use objects/signals instead
[22:48] <dobey> kenvandine: and just make it async
[22:48] <dobey> which it should probably do anyway. dispatcher.py frightens me :)
[22:49] <rickspencer3> signals ftw
[22:59] <dobey> later, gotta get away from the computer :)
[23:01] <rickspencer3> bye dobey


[00:59]  * kenvandine[jfk] waves
[07:40] <baptistemm> hello
[10:27] <mpt> rickspencer3, seb128: What do you think of having a session at UDS about turning GTK accessibility on by default? It's something we wanted for 9.10 but didn't have time, and it got put off for 10.04 because it was an LTS.
[10:28] <seb128> mpt, we can have it if you think that would be useful, I've the feeling it's rather something we should turn on early and get feedback on
[10:28] <seb128> ie there is not a lot to discuss, it will get down to "it has bugs"
[10:29] <seb128> mpt, in fact that's not true, there is https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-gnome3-accessibility-readiness
[10:29] <seb128> mpt, we can discuss it during that session
[10:29] <seb128> accessibility is changing for GNOME3
[10:30] <mpt> ok, I didn't know that
[13:45] <Nafai> didrocks: I probably should be at this session, right? https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-meta-key
[13:47] <didrocks> Nafai: right, I'll be there, you should join
[13:48] <Nafai> ok
[13:52] <Nafai> hmmm
[14:46] <LaserJock> didrocks: ping
[14:46] <didrocks> LaserJock: hey, nice to see you ;)
[14:46] <didrocks> LaserJock: it was a long time!
[14:47] <LaserJock> didrocks: yeah, I've been quite busy with work
[14:47] <didrocks> LaserJock: heh, hopefully summer will be a better time :)
[17:54]  * kenvandine_ waves
[18:04] <Nafai> Hey
[18:04] <Nafai> where are you?
[22:00] <shuthdar> hi all
[22:00] <shuthdar> maybe there's someone who may help me with indicator applet & messaging menu stuff?
[22:01] <liquidmeson> well then, spit it out?
[22:02] <shuthdar> i'm trying to get evolution completely replaced with thunderbird in the applet, to have not just a button to open it, but with additional actions like compose, contacts etc. as well
[22:03] <shuthdar> i added the following into thunderbird.desktop:
[22:03] <shuthdar> X-Ayatana-Desktop-Shortcuts=Compose;Contacts;News
[22:03] <shuthdar> [Compose Shortcut Group]
[22:03] <shuthdar> Name=New Message
[22:03] <shuthdar> Exec=thunderbird -compose
[22:03] <shuthdar> OnlyShowIn=Messaging Menu
[22:03] <shuthdar> [Contacts Shortcut Group]
[22:03] <shuthdar> Name=Contacts
[22:03] <shuthdar> Exec=thunderbird -addressbook
[22:03] <shuthdar> OnlyShowIn=Messaging Menu
[22:03] <shuthdar> [News Shortcut Group]
[22:03] <shuthdar> Name=Read news
[22:03] <shuthdar> Exec=thunderbird -news
[22:04] <shuthdar> OnlyShowIn=Messaging Menu
[22:04] <liquidmeson> you would be following http://www.omgubuntu.co.uk/2010/05/how-to-add-thunderbird-to-messaging.html ?
[22:10] <liquidmeson> http://www.markshuttleworth.com/archives/383 bottom left diamond icon? anyone?
[22:12] <shuthdar> followed that link, contents in .desktop look same as i got myself, but i still can see only thunderbird launcher
[22:14] <liquidmeson> I would either clear out your settings, update your system and retry; or try version #2
[22:23] <liquidmeson> shuthdar, scratch that
[22:23] <Sarvatt> if anyone is interested in a *HUGE* speedup of xchat's scrollback loading - http://sarvatt.com/downloads/patches/xchat_2.8.6-4ubuntu6.debdiff
[22:24] <Sarvatt> loading 32 channels worth on startup is down to 4 seconds instead of close to a minute of 100% cpu usage on this slow atom CPU
[22:24] <shuthdar> after clear settings/update/retry - no effect, will try version #2 now
[22:25] <liquidmeson> shuthdar, http://launchpadlibrarian.net/39060903/libnotify-mozilla.xpi add that to thunderbird
[22:28] <Sarvatt> of course it has dependency problems when building on maverick right now since things are getting a gconf2 (>= 2.28.1-2) dependency from something which is also affecting tomboy and update-notifier in maverick
[22:31] <liquidmeson> shuthdar, i was reading through the comments on omg, and some guy had the same problem as you "The sub-options were displayed after I had updated the ~/.cache/indicators/messages/seen-db.keyfile file.  Replacing the "evolution" text with "thunderbird""
[22:32] <shuthdar> hm.. i'll try that
[22:33] <liquidmeson> shuthdar, this might also work https://launchpad.net/libnotify-mozilla/
[22:34] <liquidmeson> shuthdar, wouldn't know for sure tho cus i just use the gmail indicator :p
[22:35] <shuthdar> liquidmeson, thanks for that, I already installed libnotify-mozilla from bzr.. it added new message alerts, but still no additional entries
[22:35] <shuthdar> liquidmeson, i could use that too, but it's just point of interest to get thunderbird where evolution were :)
[22:41] <shuthdar> liquidmeson, well, after updating seen-db.keyfile everything turned ok. thanks for ur help :)
[22:42] <liquidmeson> cool, cool
[22:42] <shuthdar> i just wonder if it's documented somewhere?
[23:52] <ajmitch> lool: you don't mind if I grab the libsdl1.2 merge? I need to do it to get a SRU fix in for lucid :)


[14:45] <Phuzzy> yo, not sure where else to ask this... is there a working alterrnative to Simple-CDD that could be used with Ubuntu?
[15:20] <mpt> xnox, the standalone installer session has no session menu. Is that to minimize memory use?
[15:21] <xnox> mpt: no it's a bug and regression currently affecting 13.10 released ISOs and Trusty due to different reasons. It was working early in trusty =)
[15:21] <xnox> mpt: but it should be the same as "session menu" in lightdm in 13.10.
[15:21] <mpt> hmm
[15:22] <xnox> mpt: which only has "restart, shutdown" and the like i think.
[15:22] <xnox> mpt: do you want a picture?
[15:22] <mpt> So you can’t access “About This Computer” from the installer session
[15:22] <xnox> can't remember. let me check.
[15:22] <mpt> I guess if you could, that would lead you to the whole System Settings ball of wax
[15:23] <mpt> You also can’t access “Ubuntu Help” … which is mostly irrelevant at that point
[15:23] <xnox> mpt: it's literarly "Supsend, Shut Down..." in lightdm, and I think we even disable suspend during ubiquity =/
[15:24] <mpt> xnox, why disable Suspend?
[15:24] <mpt> or Restart, for that matter?
[15:25] <xnox> mpt: no way to resume back into livecd =) we resume into hard-drive installs only. Restart will not do what you expect, as all shutdowns display "please remove installation media and hit enter" and if you didn't finish installation it will get you back to what you had on your computer.
[15:25] <xnox> which is well, empty or whatever it still had.
[15:26] <mpt> xnox, that seems like what I would expect from Restart, at least.
[15:26] <xnox> those concepts are irrelevant on a read-only livecd which has a sole purpose to destroy & format hard-drives, while telling the user that's what's it's doing =)
[15:27] <xnox> mpt: it's same as shutdown, Plus I think you still get a pop-up with "shutdown or restart"
[15:27] <mpt> Ugh, that awful dialog
[15:27] <xnox> mpt: so the fact that we have two menu items which do the exact same thing is a bit, interesting.
[15:27] <mpt> It’s because of the awful dialog.
[15:28] <xnox> mpt: http://img.chan4chan.com/img/2009-09-19/1253350973912.png
[15:29] <mpt> xnox, if you “Quit” the installer you end up in a live session where you can restart. I’m not sure the effect of restarting is more obvious in that situation than it is inside the installer.
[15:31] <xnox> mpt: true, but live session is suppose to be representetive of the installed system - "common system actions are in the cog, about this ubuntu, help, logout, restart shutdown" "Ok, gotcha"
[15:46] <mpt> xnox, when starting up the installer I get a non-sequitur “IBus Update” notification  that “Super+Space is now the default hotkey”. Should I report that on ubiquity, ibus, or something else? :)
[15:47] <xnox> mpt: i've failed to find where to report this. Last time around i think seb128 suggested that it might be because we have shortcuts missmatch in the default setup, and thus on first login it's "updated" and "notified"
[15:47] <xnox> (e.g. one thing believes the shortcut is one thing, and something else believes it's something rather other)
[15:47] <xnox> mpt: it may even be a ubiquity bug =)
[15:49] <infinity> xnox: Has nothing to do with ubiquity, happens on first login after install, and happened on first upgrade of whatever-package-that-was.
[15:56] <xnox> mpt: bug 1178164 is about kubuntu, not ubuntu. which is totally different UI =)
[15:56] <ubot2> Launchpad bug 1178164 in ubiquity (Ubuntu) "quit button should be "live session" in ubiquity only mode" [Undecided,Confirmed] https://launchpad.net/bugs/1178164
[15:56] <xnox> mpt: or does it apply to both?
[15:56] <mpt> xnox, I encountered that bug report because I was about to report it on Ubuntu
[15:59] <xnox> mpt: ah =)
[16:12] <mpt> xnox, infinity: reported bug 1265854
[16:12] <ubot2> Launchpad bug 1265854 in ibus (Ubuntu) "Non-sequitur "IBus Update" notification when starting installer" [Undecided,New] https://launchpad.net/bugs/1265854
[16:47] <mpt> xnox, what do you think of the standalone-installer session having a session menu that contains only one item, “Start Screen Saver”?
[16:47] <mpt> Useful or silly? (Or both?)
[16:48] <xnox> we disable screensaver.... cause back in the day when installation was taking too long and screensaver kicked in, some people thought installation was finished and e.g. pull the plug mid-install on the machine =(
[16:49] <xnox> mpt: imho just shut-down is useful, since we hide (x) after the installation is not reversible any more.
[16:49] <xnox> mpt: maybe we don't need system cog at all, and just have (x) all the time....
[16:49] <mpt> yeah
[16:49] <xnox> mpt: which goes back to the quit button and other buttons debacle.
[16:49] <xnox> left, right, centre and upside down.
[16:50] <mpt> xnox, so screensaver is disabled for the live session too?
[16:51] <xnox> mpt: i think just during the installer, or that's the intention. not sure how it's actually currently done.
[16:51]  * mpt tries
[16:55] <mpt> The installer won’t launch for me :(
[16:56] <mpt> But then, neither will the Dash open, so probably not Ubiquity’s fault
[17:10] <mpt> xnox, <https://wiki.ubuntu.com/SystemMenu?action=diff&rev2=8&rev1=6> is my conclusions about all the variations, with the live session and installer session being two of those. I would greatly appreciate you pointing out any mistakes. :)
[17:14] <xnox> mpt: i think it's all correct.
[17:15] <mpt> thanks
[20:15] <bdmurray> Does anybody recall a bug regarding configure_face and the .face file causing a crash with the precise installer?
[20:15] <bdmurray> bug 970641 for example
[20:15] <ubot2> Launchpad bug 970641 in ubiquity (Ubuntu) "installer crash" [Undecided,Confirmed] https://launchpad.net/bugs/970641


[08:28] <nixternal> good moin Hobbsee
[08:28] <Hobbsee> hey nixternal
[08:29] <freeflying|away> anyone work on kipi-plugins?
[08:29] <Hobbsee> i've heard it discussed, i'm not sure
[08:29] <DaSkreech> Can I add a URL to ubotu's XGL statement
[08:30] <DaSkreech> http://noiesmo.dnsalias.net/article.php?story=20060602173658632
[08:30] <DaSkreech> noiesmo wrote that up for XGL and Kubuntu
[08:31] <Hobbsee> DaSkreech: looks nice :)
[08:32] <Hobbsee> :)
[08:32] <Hobbsee> i dont think permission is required for the bot - mind you, the ops get annoyed with people adding rubbish to it
[08:32] <DaSkreech> right I didn't want this dimissed as rubbish :)
[08:33] <DaSkreech> He gave his permisson to link to it already btw
[08:34] <Hobbsee> hehe :)
[08:34] <Hobbsee> cool
[08:35] <Hobbsee> i'm not sure what happened
[08:43] <DaSkreech> So how do I add it to Ubotu's info?
[08:45] <DaSkreech> Tad bit long?
[08:46] <DaSkreech> Well don't let it sit on you...
[08:46] <Hobbsee> DaSkreech: got it :)
[08:46] <Hobbsee> hehe
[09:05] <mornfall> bot? what bot?
[09:05] <DaSkreech> haha :-)
[09:10] <mornfall> --> meeting
[09:10] <Hobbsee> mornfall: the one that eats people
[09:36] <Riddell> DaSkreech: cool
[09:36] <DaSkreech> Riddell: Hmm?
[09:36] <Riddell> that link
[09:37] <DaSkreech> Oh yes and apparently he hangs around and updates it as people have problems to make it more generic :)
[09:37] <DaSkreech> very nice guy :)
[09:37] <Riddell> !xgl
[09:37] <Riddell> hmm, that doesn't work
[09:39] <freeflying|away> Riddell: how shall we package kipi-plugins, single or split into several
[09:39] <DaSkreech> Riddell: Maybe when Ubotu gets off of Hobbsee?
[09:39] <DaSkreech> Great
[09:40] <Riddell> freeflying|away: we already have kipi-plugins, just update the existing package
[09:40] <DaSkreech> Now the ipod doesn't work anymore
[09:40] <Riddell> freeflying|away: probably it's already up to date in debian, allee is good like that
[09:40] <Hobbsee> Riddell: it should...
[09:41] <freeflying|away> Riddell: the latest release include some which used be in digikamplugin
[09:41] <Riddell> Hobbsee: no ubotu here, only ubugtu
[09:42] <Riddell> freeflying|away: get the latest from debian and update that then
[09:42] <Hobbsee> Riddell: yes, exactly - which is why yours didnt work
[09:42] <Hobbsee> oh, right...i thought you tested in #kubuntu as well
[09:42] <freeflying|away> Riddell: okey
[09:42] <Riddell> freeflying|away: will need libkipi updated to
[09:42] <Riddell> too
[09:44] <Hobbsee> work, back later.
[09:46] <DaSkreech> Riddell: What's the link for the last Kubuntu meeting
[09:46] <DaSkreech> I missed it :-(
[09:47] <Riddell> https://wiki.kubuntu.org/Kubuntu/Meetings
[09:47] <DaSkreech> Thanks
[09:47] <DaSkreech> Hmm
[09:48] <DaSkreech>  what does the media player inthe Konqueror side bar run on?
[09:53] <DaSkreech> ok
[09:53] <DaSkreech> Riddell: When do Wiki pages become out of date?
[09:53] <DaSkreech> When the distro release is no longer supported?
[10:01] <nixternal`zzz> g'nite all
[10:05] <Riddell> DaSkreech: it uses kaboodle
[10:05] <Riddell> they're out of date when they're no longer needed
[10:05] <DaSkreech> ok need to figure out how to get it to play mp3s ;-)
[10:08] <Riddell> arts-mpeg
[10:08] <Riddell> and adoke-mpeg
[10:09] <martoss> hi there
[10:09] <Riddell> hi martoss
[10:09] <martoss> i can't login through kdm anymore
[10:09] <martoss> the problem seems to be, that i sheduled a shutdown
[10:09] <martoss> via shutdown -h
[10:10] <martoss> and my girlfriend shut down via the k-menu
[10:10] <martoss> now, only root is allowed to log in, although i rebooted
[10:10] <martoss> no shutdown is running anymore...
[10:11] <martoss> is this a bug or just my misusage?
[10:11] <Riddell> i've not heard of the problem, but it's a bug
[10:11] <Riddell> can you login from the command line?
[10:12] <martoss> any ideas how to solve it?
[10:12] <martoss> i already looked through /var
[10:12] <martoss> but couldnt find anything
[10:13] <Riddell> looking at /var/log/kdm.log might help
[10:13] <DaSkreech> Riddell: I have akode2-mpeg is that alright?
[10:13] <Riddell> DaSkreech: libarts1-mpeglib libakode2-mpeg
[10:14] <DaSkreech> Riddell: ok do I have to restart konqueror?
[10:15] <martoss> hmm, nothing in kdm.log
[10:15] <Riddell> DaSkreech: arts
[10:17] <Riddell> oops
[10:17] <martoss> maybe rebooting again helps...
[03:44] <bddebian> Heya
[03:45] <Hobbsee> hey bddebian!
[03:45] <seaLne> $time_of_day_greeting
[03:46] <Hobbsee> hehe
[04:42] <seaLne> was there a reason the live dvd isn't setup to be able to use itself for installing packages?
[08:51] <toma> weee!
[08:52] <DaSkreech> haha
[09:01] <nixternal> wee right back at ya
[09:01] <nixternal> 10 minutes late...better late then never right ;)
[09:18] <toma> right ;-)
[11:17] <DaSkreech> hi mornfall
[11:17] <DaSkreech> Hows oprofile?
[11:22] <mornfall> i just got xen with network *and* nat working
[11:22] <mornfall> you can't have everything at once :p
[11:23] <DaSkreech> haha :-) What are you running on Xen?
[11:24] <mornfall> nothing much right now
[11:24] <mornfall> moving public services to xen dmz
[11:24] <mornfall> and then, probably installing some fedora and maybe kubuntu instead of a chroot
[11:24] <mornfall> but that has to wait till i have more disk space
[11:25] <mornfall> i also enabled selinux (no policy yet)
[11:25] <mornfall> fun times lie ahead
[11:26] <\sh> mornfall: my actual company is working on a default policy for selinux for our machines....I told our security guy to write ajmitch to help him
[11:27] <\sh> mornfall: ubuntu-server that is ;)
[11:28] <mornfall> try fedora, it has pretty good selinux setup out of the box :P
[11:33] <\sh> mornfall: ah thx, I got my bit of rpm yestday and today ;)
[11:35] <\sh> suses sles9 rpm implementation is not able to do "Requires: jre1.4 or jre1.5"
[11:43] <mornfall> pfff, sles :p
[11:44] <\sh> mornfall: what should I do....at least 4 people want to change to debian/ubuntu-server..but management said for this time: "No ways..wait after product launch"
[11:49] <mornfall> i would probably rather switch to rhel than ubuntu-server... but whatever
[11:50] <mornfall> well, or debian :)


[02:42] <Black_Phantom> hi all how do I install the latest linux kernel using apt ?
[04:13] <mattsh> hey all
[04:14] <mattsh> what is a good environment to test a kernel module during development?
[10:19] <Wellark> morning!
[10:19] <Wellark> any change getting this applied to next karmic kernel update: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=dcfcb256cc23c4436691b0fe677275306699d6a1
[10:21] <Wellark> I have a Nokia Booklet and I'm running karmic on it and without the patch the booklet soft-lockups every time I insert a SIM card
[10:21] <Wellark> I'm the author of the patch, btw
[11:24] <alex_joni> Wellark: best thing to do is file a bug at LP
[11:27] <Wellark> alex_joni: thanks! I'll do that on monday.


[15:08] <ubotu> Launchpad bug 113626 in launchpad "pending-reviews should run and display the output of make lint" [Undecided,Confirmed] https://launchpad.net/bugs/113626
[15:08] <botbotdingzip> hi, Im an uber newby.. I have to learn this thing for university. how does this cvs thingy work
[15:09] <barry> botbotdingzip: hi, there's a launchpad reviewers meeting going on, so apologies if we're less responsive for a bit.  the meeting will be done in about 42 minutes.
[15:09] <botbotdingzip> sorry
[15:09] <intellectronica> botbotdingzip: if you want to learn cvs itself, then this isn't really the place. if you want to learn how it works with LP we can find someone to help you as soon as we finish this meeting
[15:09] <botbotdingzip> thx
[15:10] <barry> we have a couple of things on the plate for the pending-review script.  does someone want to take ownership of it, get it into our tree somewhere, and do some enhancements of it?
[15:10]  * barry like the mythical lp hacker who has copious amounts of free time?
[15:10] <sinzui> time is an illusion
[15:11] <statik_> is this the script jamesh has been running?
[15:11] <barry> statik_: yep
[15:11] <barry> afaik, it's just sitting on devpad in ~jamesh
[15:12] <barry> i propose to remove this action item.  i don't think mentioning it here every week will help get the bug addressed.
[15:12] <statik_> i propose tha jamesh put it in the tree, mthaddon takes care of making it run, then i willvolunteer to help with enhancements
[15:12] <barry> statik_: that sounds good to me.  i'll ask jamesh to check it in somewhere
[15:13] <barry> statik_: shall i assign this bug to you? :)
[15:13] <statik_> sure
[15:13] <barry> statik_: you rock
[15:13] <barry>  * barry will coordinate with kiko for ''reviewer's sprint'' at all-hands
[15:48] <BjornT> mwhudson: why can't you do that with comments?
[15:48] <mwhudson> BjornT: you can, i guess
[15:48] <mwhudson> i tend to think of comments as lower level
[15:49]  * barry prefers doctests anyway
[15:49]  * BjornT too :)
[15:49] <mwhudson> perhaps a meeting isn't the place to hash this out
[15:49] <intellectronica> all of that seems not to answer the question, really
[15:50] <BjornT> mwhudson: that could be true. but in that case, i think the docstring should be properly formatted according to PEP-257
[15:50] <barry> we're almost 5 minutes over.  mwhudson... yes thanks. can you move this to the mailing list?
[15:50] <barry> BjornT: yes, agreed.  if there /is/ a docstring, it should be consistent with all our other docstring conventions
[15:51] <barry> i hate to cut this short.  but i will. :)
[15:51] <mwhudson> well, i think you're wrong, but --> mailing list
[15:51] <mwhudson> :)
[15:51] <barry> unless there is nothing else...
[15:51] <barry> 5
[15:51] <barry> 4
[15:51] <barry> 3
[15:51] <barry> 2
[15:51] <barry> 1
[15:51] <test___> hi
[15:51] <barry> MEETING ENDS
[15:51]  * flacoste goes back to reviews
[15:51] <barry> apologies once again for going long.  that's two weeks in a row :(
[15:52] <test___> barry pvt sg plz
[15:52] <test___> private message please one question
[15:53] <intellectronica> botbotdingzip: so, what is it you needed help with?
[15:53] <test___> how do get kubuntu dvd?
[15:55] <salgado> test___, http://shipit.kubuntu.org
[15:55] <test___> why any many it send me?
[16:01] <spiv> barry: Btw, I don't like doctests much.
[16:01] <spiv> barry: I have some blog posts drafted about that, I'll be sure to give you links when I get around to polishing them and publishing them :)
[16:01] <barry> spiv: i don't like doctests in docstrings much, but i've come to really like separate file doctests.
[16:02] <barry> spiv: please do!  i've come 180 degrees on this :)
[16:03] <spiv> It's largely because the "long narrative" style of tests is deficient in many respects.  But if I say anymore I'll just start rewriting my blog posts badly, so for more elaboration on my thoughts you'll just have to be patient :)
[16:04] <barry> spiv: cool :)
[16:04] <spiv> (I will say I don't think doctest files are always bad, for some purposes they are good, but not as often as people seem to use them.  I definitely don't think they should be a default format for writing tests, and it's that point I want to convince people of.)
[16:05] <barry> spiv: i've actually come to think the opposite.  i think a well written doctest file with good narratives can usually (but agreed, not always!) be quite thorough and still serve the primary purpose of good documentation.
[16:05] <barry> spiv: maybe a good discussion to have over beers at all hands :)
[16:06] <spiv> barry: Oh, one other thing I should clarify about my opinion:
[16:06] <spiv> barry: I'm talking about doctests for *tests*, not so much about doctests for documentation.
[16:08] <spiv> And most of the time good tests != good documentation, and that's not because of the format they are written in, but inherent in their conflicting goals.
[16:08] <spiv> (and "testable documentation" is good, but not the same as "tests")
[16:08]  * spiv -> bed
[16:09] <barry> spiv: yes, i think this would be a fun discussion to continue!
[19:03] <Schnitz_> is a moderator of the launchpad-beta-testers team here? i'd like to be accepted for membership because i need/want to use ppa for  uploading some packages for needs-packaging bugs i think i've fixed
[19:04] <matsubara> mrevell: ^
[19:05] <mrevell> thanks matsubara
[19:05] <mrevell> Hi Schnitz_
[19:05] <mrevell> Schnitz_: I look after that team. What's your LP username?
[19:06] <mrevell> don't worry, I've found you. Just a moment and I'll approve your membership.
[19:07] <mrevell> Schnitz_: Okay, you're in! Welcome to the beta team :)
[19:13] <Schnitz_> mrevell: thank you, ubuntu dev people are really more friendly than others!!!
[19:14] <mrevell> Schnitz: It's my pleasure!
[19:46] <evarlast> Schnitz: isn't PPA awesome?
[20:16] <Schnitz> evarlast: yeah ppa is great
[20:43] <thumper> morning
[21:06] <ubotu> New bug: #153721 in launchpad "+packages contains invalid links [to ppas?]" [Undecided,New] https://launchpad.net/bugs/153721
[21:09] <kiko> dupe
[21:20] <ubotu> New bug: #153725 in launchpad "regression: packages page doesn't show only contributions to ubntu" [Undecided,New] https://launchpad.net/bugs/153725
[21:27] <kiko> dupe
[21:27] <kiko> cprov, what are the above bugs dupes of?
[21:27] <kiko> (or matsubara)
[21:27] <matsubara> kiko: the first one is duped already (bug 115078)
[21:27] <ubotu> Launchpad bug 115078 in soyuz "Broken link in /people/me/+packages" [Undecided,Confirmed] https://launchpad.net/bugs/115078
[21:28] <cprov> kiko: bug 135669 ?
[21:28] <ubotu> Launchpad bug 135669 in soyuz "PPA uploads are showing up on lp.net/~user/+packages" [High,Fix committed] https://launchpad.net/bugs/135669 - Assigned to Celso Providelo (cprov)
[21:28] <kiko> yeah.
[21:29] <kiko> the latter one is a dupe of that
[21:29] <matsubara> duped
[21:29] <matsubara> thanks cprov
[21:29] <cprov> matsubara: np
[21:31] <sistpoty> hi, I just reported bug #153725 and before bug #153721 (and then a light bulb burned and my fuse went out), could you please set the priority of the former appropriately, as it hinders my work as MOTU council member?
[21:31] <ubotu> Launchpad bug 153725 in launchpad "regression: packages page doesn't show only contributions to ubntu (dup-of: 135669)" [Undecided,New] https://launchpad.net/bugs/153725
[21:31] <ubotu> Launchpad bug 153721 in launchpad "+packages contains invalid links [to ppas?] (dup-of: 115078)" [Undecided,New] https://launchpad.net/bugs/153721
[21:33] <sistpoty> oh, thanks for marking the latter as duplicate, didn't stumble on it when searching for "packages"
[21:44] <sistpoty> thanks (and sorry that I didn't find the dupes) :)
[21:50] <ScottK> sistpoty: You could always file a bug against LP's duplicate finding function.
[21:51] <sistpoty> ScottK: I could, but could I find dupes when doing so? ;)
[22:07] <geser> does the "Launchpad Janitor" still expire duplicate bugs? see the last comment on bug #129553
[22:07] <ubotu> Launchpad bug 129553 in wide-dhcpv6 "Please sync wide-dhcpv6 (universe) from Debian unstable (main) (dup-of: 129216)" [Undecided,Invalid] https://launchpad.net/bugs/129553
[22:07] <ubotu> Launchpad bug 129216 in wide-dhcpv6 "[Sync request] Sync wide-dhcpv6 (20070507-2) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/129216
[22:12] <ScottK> geser: When I asked yesterday I was told it had accidentally been left on, but was off as of yesterday.  Are those new ones?
[22:13] <geser> from 2007-10-13
[22:13] <geser> I'm catching up my mails
[22:14] <kiko> ScottK, btw, I did some research on pyspf, and have some results, and something for you to read, but it might have to be later as I am about to dive into a phone call
[22:14] <ScottK> kiko: I'll be here for ~ 30 min and then gone for some time.
[23:18] <jelmer> the beta seems to be like russian roulette atm - known problem?
[23:22] <kiko> jelmer, the beta? do you mean edge.launchpad.net?
[23:22] <kiko> if so, yes
[23:22] <kiko> we're having problems with the DC machines
[23:23] <jelmer> ah, k - thanks
[23:25] <superm1> has bzr died again?
[23:25] <superm1> last i checked my public key hasn't changed, but i'm still gettingPermission denied (publickey).
[23:25] <superm1> bzr: ERROR: exceptions.AssertionError: end of file reading from server.
[23:28] <pochu> kiko: have you updated this page? I was going to do it, but it's already there.
[23:28] <kiko> pochu, which page?
[23:29] <kiko> superm1, we had a server hiccup. can you try again?
[23:29] <superm1> sure
[23:29] <pochu> kiko: oops, this one: https://edge.launchpad.net/emesene/trunk
[23:29] <superm1> kiko, same thing is still happening, and if i try sftp:// instead, bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; EOF during negotiation
[23:29] <ajmitch> kiko: I guess this is affecting wiki auth as well
[23:29] <kiko> pochu, I can't remember. maybe I did.
[23:29] <kiko> ajmitch, yes.
[23:30] <ajmitch> oh well
[23:30] <pochu> kiko: ok. anyway thats fine :)
[23:31] <kiko> ajmitch, superm1: working on it.
[23:31] <kiko> pochu, I've got only half a head right now!
[23:31] <superm1> okay thanks kiko :)
[23:32] <mthaddon> superm1, can you retry now?
[23:32] <superm1> mthaddon, this time around it denied the public key again
[23:32] <superm1> eof from server still
[23:33] <ajmitch> kiko: great, thanks
[23:34] <mthaddon> superm1, sorry, authserver also was down - please try now
[23:35] <superm1> mthaddon, looking more promising.  yup
[23:35] <superm1> works
[23:35] <superm1> thanks :)
[23:35] <mthaddon> superm1, sorry for the inconvenience
[23:37] <kiko> heh