[03:44] <pitti> Good morning
[03:45] <pitti> rodrigo_: wasn't input support recently discussed upstream at least for ibus? that should solve most use cases anyway
[06:41] <BigWhale> Good Morning.
[07:13] <rickspencer3> hi pitti
[07:14] <pitti> hey rickspencer3, how are you?
[07:14] <rickspencer3> pitti, I am doing well
[07:14] <rickspencer3> I am excited today
[07:14] <rickspencer3> looking forward to the increased manual testing cadence
[07:14] <rickspencer3> jono told me that they are going to go for complete test runs every 2 weeks!
[07:15] <rickspencer3> pitti, how are you doing?
[07:15] <pitti> nice!
[07:15] <pitti> rickspencer3: I'm great, thanks! Making good progress on our jenkins autopkgtest tests
[07:15] <rickspencer3> yeah
[07:15] <rickspencer3> nice to see us continuing to make progress on quality in 12.10
[07:17] <rickspencer3> pitti, is it true that we go for weeks without ARM images?
[07:17] <rickspencer3> ogra_, ^
[07:17] <pitti> I'm not sure
[07:17] <pitti> I haven't really followed them so far
[07:18] <pitti> but last Friday I got a Panda board delivered, I was going to set it up today
[07:19] <rickspencer3> ok
[07:19] <rickspencer3> so, I don't know why we would think that we need to wait for milestones to fix that
[07:19] <pitti> http://cdimage.ubuntu.com/daily-preinstalled/20120619/ seems current, though
[07:19] <rickspencer3> I don't consider this to be a good state of affairs if we are going days without an image, we should figure out the problems and solve them
[07:19] <rickspencer3> ok
[07:19] <rickspencer3> I was wondering if it was a point in time thing
[07:19] <pitti> rickspencer3: I think infinity, ScottK, you, and me are mostly talking past each other
[07:20] <rickspencer3> pitti, well, I tried to clarify on my last response
[07:20] <pitti> rickspencer3: yes, that's the point of the stable+1 team
[07:20] <pitti> it seems we all violently agree
[07:20] <rickspencer3> I think there were a few discussions mixed together
[07:20] <pitti> and the main point of dissent is the nomenclature
[07:20] <rickspencer3> well, I really just wanted to know about not freezing, to be honest
[07:20] <rickspencer3> (for the milestones)
[07:20] <pitti> IMHO, when we all rally around testing on certain points in time (say, every two weeks) to shake out bugs found in manual testing, why not just call this a "milestone"?
[07:21] <pitti> because that's exactly what milestones have been
[07:21] <rickspencer3> pitti, right
[07:21] <pitti> we can call it differently, of course
[07:21] <rickspencer3> but we can't do that if we freeze the archive and everything
[07:21] <pitti> we haven't actually frozen the archive for alphas in years
[07:21] <rickspencer3> well, we sort of do
[07:21] <pitti> it was a soft-freeze, so people still backed up a bit
[07:22] <pitti> but we need that if we want to be able to put out a known-good image
[07:22] <rickspencer3> well, people tell me that it caused them a lot of extra work, and it went slow
[07:22] <pitti> using -proposed by default shoudl help a lot here
[07:22] <rickspencer3> I think Thierry's idea was ideal
[07:22] <rickspencer3> just use the "last known good" image
[07:22] <rickspencer3> which I think we can easily do these days
[07:22] <pitti> "a lot of extra work" and "slowing down developers" should be, quite frankly, blatant lies
[07:22] <rickspencer3> oooh
[07:22] <pitti> you can queue up stuff in bzr, in PPAs, work on bugs, work in upstream trunks, etc.
[07:23] <rickspencer3> well, that all sounds like extra work and slowing down development to me
[07:23] <rickspencer3> lol
[07:23] <pitti> except for the release team, of course, who do have to work fulltime on the images
[07:23] <rickspencer3> yup
[07:23] <pitti> rickspencer3: not to me; we do stuff in bzr, at upstream, etc. anyway
[07:23] <pitti> the only thing that you need to hold back a bit is uploading to the dev release
[07:24] <pitti> but that's not causing any extra work
[07:24] <pitti> it's just causing some delay of landing stuff
[07:24] <rickspencer3> well, I think that delay is lost velocity
[07:24] <pitti> you can upload to a PPA if you want other folks to test
[07:24] <pitti> well, you can't have both
[07:24] <rickspencer3> can't have both what?
[07:24] <pitti> we can't produce a known-good image for public testing _and_ have uploading go on at full speed
[07:24] <rickspencer3> I think we produce lots of known-good images
[07:24] <rickspencer3> good enough for public testing
[07:25] <rickspencer3> I think we do it *most* days, in fact
[07:25] <pitti> well
[07:25] <pitti> we produce a lot of images where jenkins thinks they are good
[07:25] <pitti> if they actually _were_ good, the release team wouldn't need to work three times and 10 respins to actually _make_ them work
[07:26] <pitti> s/times/days/
[07:26] <rickspencer3> yeah, but we know we need the respins because of the manual testing
[07:26] <pitti> well
[07:26] <rickspencer3> so, those respins are usually about fixing installer bugs and such
[07:26] <pitti> we need the respins because of the bugs only found by manual testing
[07:26] <pitti> correct
[07:26] <rickspencer3> yeah, so those bugs don't really block testing, do they?
[07:27] <pitti> if the daily image on milestone date minus two days were good, we would just use it
[07:27] <pitti> sure they do
[07:27] <pitti> we had a lot of cases where the installs completely fell over
[07:27] <pitti> or the result didn't actually work
[07:27] <rickspencer3> yeah, but those installs falling over are test results, no?
[07:27] <rickspencer3> so we fix the bugs
[07:27] <pitti> correct
[07:28] <pitti> and then need to re-test again until we have an image which really works
[07:28] <rickspencer3> right
[07:28] <pitti> once we have that, we unfreeze and publish that
[07:28] <rickspencer3> so
[07:28] <pitti> which is the really easy part
[07:28] <rickspencer3> a. it's not really frozen, is it, as we keep changing the installer
[07:28] <pitti> (well, there's documentation and announcements to write, and so on)
[07:29] <rickspencer3> b. we should be doing that at will, not only a few times per cycle
[07:29] <pitti> that's what we call a freeze - only upload minimal changes that fix the breakage, and not upload other stuff which introduces breakage again
[07:29] <rickspencer3> so, I think making sure the installer works is very very good
[07:30] <rickspencer3> but I think having the whole milestone process is a lot of effort for that one focused area
[07:30] <rickspencer3> we could just have people test the installer weekly, etc...
[07:30] <rickspencer3> and fix the bugs soon after they are introduced
[07:30] <pitti> we could, but I really doubt it would go as well
[07:30] <pitti> infinity hit the nail on the head
[07:30] <pitti> although he expressed it differently
[07:30] <rickspencer3> oh?
[07:30] <pitti> you need to _make_ time for this
[07:31] <rickspencer3> indeed
[07:31] <pitti> otherwise it will not happen
[07:31] <rickspencer3> but we need to make time for it more than a few times per cycle
[07:31] <pitti> we don't have a lot of devs who say "gosh, I'm bored today, let's test some images"
[07:31] <pitti> rickspencer3: I agree
[07:31] <rickspencer3> it takes a lot more time to fix bugs weeks or months after they are introduced
[07:31] <pitti> so if anything, we need more milestones, not fewer
[07:32] <rickspencer3> lol
[07:32] <pitti> that's what I meant with "we can certainly discuss about the frequency"
[07:32] <rickspencer3> well, we need more frequent testing, and higher standards for "daily quality"
[07:32] <pitti> but I don't see how we can drop the entire concept and process
[07:32] <rickspencer3> pitti, well, we drop it when it is no longer useful to us
[07:33] <rickspencer3> and it is no longer useful to us when our daily quality exceeds what we get from milestones today
[07:33] <pitti> when our automated daily testing is good enough one day, we won't need it, yes
[07:33] <rickspencer3> to be clear, I'm not arguing to drop milestones, I didn't actually bring that up
[07:33] <rickspencer3> oh, I think some manual testing is always needed
[07:33] <pitti> right, it won't happen in the next two years
[07:33] <rickspencer3> I think automated testing tells you how worth it is to do manual testing
[07:33] <rickspencer3> actually, I think it will happen soon
[07:33] <pitti> (automatic testing being sufficiently good, I mean)
[07:33] <rickspencer3> right
[07:34] <pitti> e. g. for the installer we do not test the UI at all
[07:34] <rickspencer3> but I think we can rally the testing community to give us more actionable and more frequent feedback
[07:34] <pitti> the preseeding is by and large a special-case code path
[07:34] <rickspencer3> pitti, it seems like the installer is such a special case for us, we should be much more focused on it
[07:34] <pitti> and we don't test GL, graphics, unity, sound, etc.
[07:35] <rickspencer3> like we have all of this release machinery and effort built around the whole distro, when it really comes down to ensuring the installer works
[07:35] <pitti> I'd actually like to drop the preseeding and do real interaction with the installer UI/widgets
[07:35] <pitti> well, it's installer + kernel + X.org + unity + sound + different hardware platforms
[07:37] <rickspencer3> interestingly, xorg and unity do a lot of testing outside of the distro testing cadence
[07:37] <pitti> right; the more dev release daily users we have, the better (and they are growing, I think)
[07:38] <rickspencer3> yeah, and the better our daily quality, the more we will get
[07:38] <rickspencer3> but I think the community team can help by bringing rigor more rigor to the dev release testers
[07:38] <rickspencer3> I bet there are a lot of people who would love to contribute in that manner
[07:39]  * micahg would love a way to automate UI testing :)
[07:40] <rickspencer3> micahg, sounds like you find a nice weekend project ;)
[07:41] <pitti> yeah, it's also one of the things I'd like to work on
[07:41] <pitti> I already test apport that way (GTK and KDE)
[07:41] <pitti> by emitting clicks to the buttons and other UI parts, and checkign the state of the program and widgets afterwards
[07:42] <pitti> it's still a lot of overhead, we need to think about how to make this radically simpler
[07:42] <pitti> but it does work in principle
[07:42] <rickspencer3> didn't someone make a desktop recorder kind of app at some point?
[07:43] <rickspencer3> like you click around and it generates Python code for your clicks?
[07:43] <pitti> dogtail
[07:43] <pitti> it requires a11y enabled, and only works for blackbox testing
[07:43] <pitti> but for this kind of installer test, blackbox might actually suffice
[07:46] <rickspencer3> in the meantime, it sounds like we should see if we can arrange some people to test the installer on more like a weekly basis
[07:46] <rickspencer3> (by manual testing, I mean)
[07:49] <jibel> micahg, ldtp is good for UI testing of GTK apps but not all components are exposed in Ubiquity. For Qt, the testability driver is very good.
[07:49] <micahg> jibel: I need non-GTK :), I'd ideally like to automate distro firefox testing :)
[07:50] <pitti> I thought firefox was gtk2?
[07:50] <micahg> yes, for some things
[07:50] <jibel> ldtp works quite fine with firefox, but identifying links in pages is a real pain
[07:50] <micahg> jibel: links can be done other ways
[07:51] <jibel> well, you can mix technologies
[07:52] <micahg> right
[07:52] <micahg> jibel: ok, I'll have to look at ldtp at some point then, thanks
[07:52]  * micahg loves 500 errors when searching for stuff 
[07:56] <didrocks> good morning
[07:57] <pitti> hey didrocks
[07:57]  * pitti hugs didrocks for the lost game, but at least you are in the quarter finals
[07:57] <didrocks> hey pitti
[07:58] <didrocks> pitti: are we? I'm totally disconnected from football world :)
[07:58]  * didrocks hugs pitti nevertheless
[08:07] <seb128> hey
[08:07] <Sweetshark> good mooooorning desktoppers!
[08:08]  * Sweetshark survived a good flamefest yesterday: http://nabble.documentfoundation.org/ANN-Please-use-Gerrit-from-now-on-for-Patch-Review-td3990754.html
[08:10] <Sweetshark> seb128: whats the current state with libreoffice SRU/MRE, btw? i somehow lost track there ...
[08:10] <pitti> bonjour seb128
[08:10] <pitti> hey Sweetshark
[08:10] <seb128> hey Sweetshark, pitti
[08:10] <pitti> seb128: hope you aren't too sad about the game
[08:10]  * Sweetshark waves at pitti 
[08:10] <seb128> Sweetshark, it has been acked in principle, it just needs a courageous SRU team member to press the button
[08:11] <Sweetshark> seb128: lets make that a big red botton with the text "nuke" on it ...
[08:11] <seb128> pitti, if we had to play bad once it was better to be this game, I hope we do better against Spain!
[08:12] <seb128> Sweetshark, yeah, RAOF said he was looking at libreoffice yesterday, not sure how far he went, otherwise we will need to chase down slangasek to ack it, I don't think the other SRU team members will do it
[08:12] <Sweetshark> seb128: spain-croatia wasnt really showing any spanish dominance, so you should stand your chances ...
[08:13] <seb128> Sweetshark, yeah, we both had a day off, let's see how that plays out for the next game...
[08:19] <micahg> seb128: I finally managed a backtrace for my weird bug: Bug #1015443
[08:19] <ubot2> Launchpad bug 1015443 in thunderbird "Thunderbird hangs the desktop when escaping from password prompt" [High,Triaged] https://launchpad.net/bugs/1015443
[08:27] <micahg> seb128:the thing is, I can't seem to reproduce on my metal precise system in the same env
[08:29] <seb128> micahg, is that an unity-2d issue again? ;-)
[08:29] <micahg> seb128: no, I can reproduce in lucid and natty w/out unity
[08:29] <micahg> I am thinking it might be an X/driver issue of some sort though
[08:30] <micahg> since I can't reproduce in the host env
[08:30] <seb128> micahg, is that blocking the tb13 update?
[08:30] <seb128> micahg, what happened to firefox 13.0.1?
[08:30] <micahg> seb128: yes
[08:30] <micahg> seb128: well, I wanted to try to get TB out, but ran into this again, I'll go back to finishing FF now
[08:31] <seb128> micahg, that doesn't seem worth blocking the update honestly, especially if that happens only in vms
[08:31] <micahg> seb128: well, I don't know what video driver combinations would trigger it
[08:31] <micahg> if that's indeed the issue, if it's only VMs, I agree :)
[08:32] <seb128> micahg, are you sure it's a new issue in 13?
[08:32] <micahg> seb128: yes, I reverted to 12 and can't reproduce
[08:34] <seb128> micahg, did you open an upstream bug?
[08:34] <micahg> seb128: no, as I don't know if it affects upstream or not (depends if it's a thunderbird bug or a bug elsewhere in the stack)
[08:35] <seb128> micahg, we really have an issue there in the velocity of how we deal with problems and we need to sort that
[08:36] <seb128> micahg, we are over a week late for that update already, and that bug seems nowhere close from being resolved or debugged :-(
[08:36] <micahg> seb128: yes, indeed, we'll be testing 14 in advance
[08:36] <seb128> micahg, it usually doesn't hurt to take upstream input on issues
[08:36] <micahg> seb128: unfortunately, when I tried to reproduce last week, I couldn't, so I figured that maybe it was fixed by the unity update
[08:37] <micahg> seb128: but, we are slated to do beta testing this time around, so that should give us more time to fix issues as they pop up
[08:38] <seb128> micahg, ok, at least that's a move in the right direction ;-)
[08:38] <seb128> micahg, can you go finish the firefox update, I will try to see with chrisccoulson if we can help on the tb hang you are having
[08:38] <micahg> seb128: yep, doing so now
[08:39] <seb128> thanks
[08:40] <micahg> seb128: FWIW, the protocol testing that I managed to do before it froze each time seemed to be fine
[08:41] <seb128> micahg, does going to a vt and killing tb release the lock, i.e do you get your desktop back if you do that?
[08:42] <micahg> seb128: let me see, ISTR no, but I'll try again
[08:42] <seb128> micahg, the "hang" description is weird, keyboard working and no mouse?
[08:43] <micahg> ooh, yeah, it does release it
[08:45] <micahg> more info, mouse moves (menubar appears, but clicks aren't recognized)
[08:45]  * micahg adds to the report
[08:45] <mvo> pitti: do you remember the set_data/get_data in gobject we talked about some time ago? I use it in the tests in software-center quite a bit to store various bits and piece of information, is it coming back as a compat function for gobject or do I need to rip it all out and replace ?
[08:47] <seb128> micahg, chrisccoulson: if stopping tb releases it then it seems that tb keeps an active grab
[08:54] <pitti> mvo: it's meant to be put back, but as deprecated API; so at some point it will disappear
[09:05] <seb128> pitti, did you see that davidz commented on the gvfs,loop mounting bug saying there were perhaps 2 bugs in there?
[09:06] <pitti> seb128: I saw that, yes; I was hoping to get a confirmation on the Ubuntu bug that we are really talking about the same bug
[09:07] <seb128> pitti, ah right, I did a ping on launchpad then ;-)
[09:07] <seb128> pitti, thanks
[09:14] <mvo> pitti: ok, thanks, I have a look at this then
[09:15] <pitti> mvo: I had an intial attempt for a backwards compat patch, but it doesn't work for many kinds of classes
[09:15] <pitti> since then I didn't find time to get back to this
[09:16] <pitti> presumably I'll revert the removal of it and add a g_warning() to it
[09:16] <pitti> and we'll remove it in GNOME 3.8
[09:20] <mvo> pitti: ok, thanks
[09:24] <pitti> mvo: done now
[09:33] <rickspencer3> seb128, was there an SRU for nautilus lately?
[09:34] <seb128> rickspencer3, we got one to -updates a week ago and a new SRU candidate in proposed the same day
[09:34] <seb128> rickspencer3, any issue?
[09:34] <rickspencer3> seb128, well, nautilus just crashed on me on 12.04
[09:35] <rickspencer3> but if there was not update ...
[09:35] <rickspencer3> nothing really to see here
[09:35] <rickspencer3> :)
[09:35] <rickspencer3> whoopsie-daisey will let you know if there is a problem ;)
[09:35] <seb128> rickspencer3, yeah, I doubt it's due to an update, you just likely hit one not-so-new bug
[09:36] <seb128> rickspencer3, right
[09:36] <seb128> rickspencer3, what were you doing when the issue happened?
[09:36] <rickspencer3> renaming a newly created directory
[09:39] <seb128> rickspencer3, I've seen report suggesting issues around that in the past :-(
[09:39] <rickspencer3> I'm sure it will be fixed in the next SRU ;)
[09:39] <seb128> rickspencer3, could be bug #985848
[09:39] <ubot2> Launchpad bug 985848 in nautilus "nautilus crashed with SIGSEGV in icon_rename_ended_cb()" [Medium,New] https://launchpad.net/bugs/985848
[09:40] <rickspencer3> exactly
[09:40] <seb128> rickspencer3, that one is ranked 11 on the nautilus bugs on errors.ubuntu.com with a frequency of 73
[09:40] <rickspencer3> there you go
[09:40] <seb128> I hope we get to it at some point
[09:41] <seb128> rickspencer3, thanks for point it ;-)
[09:42] <rickspencer3> after the SRU, we should see if the crash stops getting reported
[09:42] <rickspencer3> will be a good test of whoopsie-daisy
[09:45] <mitya57> hi everybody,
[09:45] <mitya57> is there any reason for still having revert_git_* patches in g-c-c and g-s-d?
[09:58] <aquarius> pitti, ping - does apport only have a CLI interface (ubuntu-bug) and not a (trivial) GUI interface (dash -> File A Bug -> enter package name in a zenity popup) from deliberate policy (filing bugs is technical, thus terminal-only) or because no-one's had a chance to make a simple GUI handler?
[09:58] <pitti> aquarius: actually we have had a GUI for this until precise
[09:58] <pitti> Help -> Report a bug..
[09:59] <aquarius> pitti, yep, that's perfect for GUI programs (and I know it's gone away now), but it's harder for "ubuntu-bug linux", for example :)
[10:00] <pitti> achiang: we also used to have that, but quickly tore it down
[10:00] <pitti> we got a massive increase in absolutely useless and misassigned bugs
[10:01] <seb128> mitya57, the same reason we added them to start?
[10:03] <aquarius> pitti, no problem; it's policy to not have such a tool, which is fine with me. I was debating writing a quick one, but figured that you might not have it by decision rather than by lack of resources, which is in fact the case :)
[10:03] <mitya57> seb128: we added them because we wanted the new version but were in UIF, didn't we?
[10:03] <pitti> aquarius: right
[10:03] <mitya57> s/UIF/FF/
[10:03] <pitti> aquarius: the compromise that we found was bearable was to call ubuntu-bug without arguments
[10:04] <seb128> mitya57, no, we added them because compiz still uses gconf and not gsettings and because we don't use systemd and don't have their datetimed service
[10:04] <seb128> mitya57, neither of those assumptions changed
[10:05] <seb128> mitya57, though the compiz on gsettings update is being worked on this week
[10:05] <aquarius> pitti, cool, I didn't know about that :)
[10:06] <mitya57> seb128: ok, thanks
[10:06] <seb128> aquarius, we don't lack bugs reports and we don't need to make bugs easier to file ;-)
[10:06]  * aquarius grins
[10:07] <seb128> mitya57, did you ask for a reason? i.e are they creating any issue?
[10:07] <aquarius> seb128, I did wonder if that was the case, which is why I asked rather than saying "here is a gui thing!" :-)
[10:07] <mitya57> seb128: no, just wondering
[10:07] <seb128> mitya57, btw https://launchpad.net/~ubuntu-desktop/+archive/ppa has g-s-d and g-c-c with the gconf->gsettings reverts dropped if you want to test it
[10:09] <mitya57> seb128: I'll test that when I'll update my quantal WM to the latest quantal :)
[10:11] <xclaesse> will Quantal have EDS 3.5 with the new storage format?
[10:12] <seb128> xclaesse, not decided yet but it's likely yes
[10:12] <seb128> xclaesse, do you need it or do you recommend against it? ;-)
[10:13] <xclaesse> seb128, we definitely need it for Folks
[10:13] <xclaesse> master is already ported to the new API
[10:13] <seb128> ok
[10:13] <seb128> let's see how that goes
[10:15] <xclaesse> seb128, cool :)à
[10:15] <xclaesse> seb128, the problem is that once the format is migrated, you can't go back
[10:15] <xclaesse> which is problematic for testing :p
[10:15] <seb128> right, well going backward in versions is an issue for distros in any case
[10:16] <seb128> but we tend to not jump on such transitions, especially for evolution which has a record of making those bumpy for a while
[10:16] <seb128> so it might take some weeks before we get the new version of e-d-s
[10:16] <xclaesse> seb128, I was planning to upgrade to quantal once it has the newer EDS, so I can use latest folks again :p
[10:17] <seb128> xclaesse, we will let you know when that happens ;-)
[10:17] <xclaesse> even when building newer EDS in jhbuild, it will migrate your DB and you're screwed
[10:18] <xclaesse> seb128, thanks :)
[12:33]  * achiang waves to pitti :)
[12:34] <pitti> hey achiang
[12:34] <pitti> achiang: argh, tab failure, sorry :)
[12:34] <achiang> pitti: np. my error checker fixed it. but it's been a while since i said "hi" anyway. :)
[12:35] <pitti> achiang: indeed, how are you these days?
[12:36] <achiang> pitti: a bit tired. in korea for work, the taxi drivers decided to have a national strike today. so i got to explore the korean bus and metro system to get where i needed to go. 2 hours later, i am back from the customer site back to hotel
[12:37] <pitti> achiang: argh; consider it a real-life sightseeing tour?
[12:38] <achiang> pitti: "forced" tourism... sounds kinda funny. :) wie gehts?
[12:38] <pitti> achiang: quite well, thanks; I'm getting into my new QA role, and making some progress
[12:39] <achiang> pitti: good to hear! you sounded quite excited in your blog post so i think we're all excited by proxy. :)
[12:39] <pitti> lol
[12:40] <pitti> I'm keeping a record on G+ (quite nice, and QA team policy anyway0
[12:42] <achiang> :)
[12:42] <achiang> ok, time to write a few status emails and then perhaps... bed
[12:42] <achiang> cheers, pitti
[12:48] <popey> chrisccoulson, did you know enigmail is broken in quantal?
[12:50] <chrisccoulson> popey, yeah :)
[13:16] <seb128> micahg, how is the tb debugging going?
[13:16] <micahg> seb128: hrm, I thought chrisccoulson was going to do that :(
[13:16] <seb128> micahg, he said he can't reproduce the issue
[13:16] <seb128> micahg, I fear you will have to do it
[13:17] <seb128> micahg, he has also other stuff to work on for quantal...
[13:17] <seb128> micahg, let we know if we can help on specific topics, but it doesn't seem we are in a position to just do the debugging and resolve the issue for you there
[13:18] <micahg> seb128: awesome, ok, I guess I'll look into this further when I start later today
[13:18] <seb128> micahg, ok, thanks, let us know how it goes
[13:18]  * micahg wonders if he missed scrollback somewhere
[13:20] <seb128> micahg, well, scrollback never said chrisccoulson was going to work on,fix that issue either ;-)
[13:20] <seb128> micahg, but I did chat with him out of the channel and we can't reproduce the issue which makes it hard to work on it
[13:40] <mterry> mvo, darn, I was hoping you had been hiding some amazing UI driving framework that you had been too lazy to use.  :-/
[13:40] <mterry> mvo, the best I've used is ldtp, but it's very rickety
[13:44] <mvo> mterry: yeah, excatly, I wasn't overly impressed with that one :/
[13:48] <mterry> mvo, well, I'm happy to write various tests, but since doing so might involve various code changes (for instrumentation) and since code is moving around a lot in my branches, would you mind if I did a big test branch after all these intermediate branches land?  (ala the indentation one)
[13:56] <mvo> mterry: that is fine with me (for the given reasons)
[13:56] <mterry> mvo, cool, I'll comment on the merge request page saying that's my plan
[13:58] <mvo> ta
[14:23] <xclaesse> seb128, I just released telepathy-gabble 0.16.1 stable release, I would appreciate if that can make its way into ubuntu precise
[14:23] <xclaesse> seb128, it fix issue connecting to MSN's xmpp server
[14:24] <xclaesse> that just regressed last week because of a change on their server
[14:24] <xclaesse> details: http://blogs.gnome.org/xclaesse/2012/06/20/problems-with-windows-lives-xmpp-server/
[14:28] <seb128> xclaesse, thanks for the notice, we will SRU that
[14:28] <seb128> kenvandine, ^ did you see bug reports about that?
[14:28] <seb128> kenvandine, did you want me to have a look to that SRU?
[14:29] <kenvandine> i hadn't seen a bug about that... but that doesn't mean we didn't get a new one
[14:29] <kenvandine> seb128, if you could please :)
[14:29] <kenvandine> i couldn't do it today
[14:29] <xclaesse> thanks ç
[14:29] <xclaesse> !
[14:30] <xclaesse> we got upstream reports
[14:30] <xclaesse> dunno about lp
[14:31] <xclaesse> there are over 10k users of that, so surely a lot of people noticed it
[14:31] <xclaesse> btw, it went from ~1000 to ~9000 just in a few days after LTS release :D
[14:31] <seb128> xclaesse, ;-)
[14:32] <xclaesse> compared to fedora's release almost unoticed in the chart :p
[14:32] <seb128> xclaesse, I will check our bug reports, I just want one to attach to the SRU (we need a bug for tracking purposes)
[14:32] <seb128> kenvandine, no worry, I will do it
[14:33] <kenvandine> seb128, you rock!
[15:54] <seb128> Laney, ping https://bugs.launchpad.net/ubuntu/+bug/1011361 ;-)
[15:54] <ubot2> Ubuntu bug 1011361 in ubuntu "[needs-packaging] libpwquality" [Wishlist,Triaged]
[15:54] <seb128> Laney, I saw robert_ancell uploaded it, it's in quantal NEW queue
[15:55] <Laney> heh
[15:56] <Laney> I think it would be good to put it in exp, but I'm not sure I want to be uploader ;-)
[15:57] <seb128> Laney, start by putting it in the pkg-gnome svn? ;;-)
[15:57]  * Laney checks if Robert is a member there
[15:58] <Laney> using SVN scares me these days, all of the actions being pushed out immediately
[16:00] <seb128> Laney, he is a member of pkg-gnome, I dropped him an email about the topic but he didn't seem interested
[16:01] <seb128> Laney, he mentioned "the ridiculous amount of Debian paperwork for new packages"
[16:01] <Laney> one bug?
[16:01]  * Laney will look at it then
[16:01] <seb128> Laney, though he discussed with mbiebl apparently who said the package seemed to be fine
[16:01] <seb128> just commit it to the svn and as a base for whoever will be wanting to pick that up ;-)
[16:01] <Laney> sure
[16:02] <seb128> Laney, one bug, well apparently he failed to open this one
[16:02] <Laney> I would have to review it for ubuntuisms though
[16:02] <seb128> thanks for the ridiculous bts email system :p
[16:02] <Laney> which is why I'd rather he did it, as he'd know
[16:02] <seb128> Laney, I doubt there is any, I reviewed it quickly, it seems fine
[16:02] <Laney> ok, will do
[16:20] <mbiebl> Laney, seb128: didn't have time really to look at libpwquality as I had other stuff on the todo list and
[16:21] <mbiebl> libpwquality being 3.5 was a low prio
[16:21] <Laney> it's ok, not a high priority indeed
[16:21] <Laney> I'll maybe put it in exp
[16:21] <mbiebl> I think I made a few quick remarks regardign the location of the pam modules
[16:22] <mbiebl> which was wrong /usr/lib/security iirc
[16:29] <Laney> mbiebl: you mean it should be in a multiarch path?
[16:31] <mbiebl> Laney: they usually go to /lib/security or /lib/$(MA)/security
[16:31] <Laney> yeah, looks (from the .install file) like this is going to /lib/security
[16:31] <Laney> laney@raleigh> head libpam-pwquality.install                                                                                                                                  ~/temp/libpwquality-1.1.0/debian
[16:31] <mbiebl> ok, then robert has fixed this already
[16:31] <Laney> lib/security/*.so
[16:31] <Laney> cool
[23:33] <bryceh> RAOF, TheMuso, robert_ancell: we missed our meeting time yesterday, but I'm assuming no one had agenda items?
[23:33] <RAOF> Correct.
[23:34] <robert_ancell> bryceh, yep
[23:35] <TheMuso> Correct.
[23:38] <bryceh> great, thanks
[23:48] <TheMuso> /c/c