[12:59] <Keybuk> hmm
[12:59] <Keybuk> queue-builder still doesn't appear to be working automatically
[01:02] <Keybuk> 22:50:03 INFO    Rebuilding Build Queue.
[01:02] <Keybuk> 22:50:03 INFO    creating lockfile 22:50:03 ERROR   Cannot Acquire Lock.
[01:02] <Keybuk> 
[01:03] <kiko> who else is holding that lock?
[01:04] <Keybuk> seems to be the slave scanner
[01:04] <Keybuk> which runs every, single, minute
[01:04] <Keybuk> no wonder the queue builder doesn't get a change
[01:04] <Keybuk> uh, chance
[01:05] <kiko> why should the slave scanner hold that lock?
[01:05] <Keybuk> no idea
[02:46] <doko> $ sudo apt-get install python-tk
[02:46] <doko> Reading package lists... Done
[02:46] <doko> Building dependency tree
[02:46] <doko> Reading state information... Done
[02:46] <doko> Some packages could not be installed. This may mean that you have
[02:46] <doko> requested an impossible situation or if you are using the unstable
[02:46] <doko> distribution that some required packages have not yet been created
[02:46] <doko> or been moved out of Incoming.
[02:46] <doko> Since you only requested a single operation it is extremely likely that
[02:46] <doko> the package is simply not installable and a bug report against
[02:46] <doko> that package should be filed.
[02:46] <doko> The following information may help to resolve the situation:
[02:46] <doko> The following packages have unmet dependencies:
[02:46] <doko>   python-tk: Depends: python2.4-tk (>= 2.4.3)
[02:46] <doko> E: Broken packages
[02:46] <doko> python-tk is now built from python-stdlib-extensions
[02:47] <doko> resulting in a python-tk_2.4.3-1ubuntu2 package
[02:48] <doko> although the package is built, it's not shown in the archive ...
[02:48] <doko> Kamion, Kinnison, Keybuk: ^^^
[03:39] <Keybuk> doko: what you say makes no sense, I'm afraid
[03:39] <Keybuk> the last upload of python-stdlib-extensions was 2.0ubuntu1
[03:40] <Keybuk> by yourself, about 8 hours ago
[03:40] <Keybuk> not 2.4.3-1ubuntu2
[03:41] <Keybuk> python-tk_2.4.3-1ubuntu2 comes from the python-defaults package
[03:42] <Keybuk> if you want the binary built by python-stdlib-extensions to replace that, it needs to at least have a higher version number ;)
[04:00] <mpt> Gooooooooooooooooooooooooood afternoon Launchpadders!
[06:28] <spiv> Hmm, bzrlib failure when merging into sqlobject.
[06:35] <jamesh> spiv: so we have a common way to get to the sync() or syncUpdate() methods of sqlobjects that are security wrapped?
[06:42] <spiv> Are you asking "do we" or "should we"?
[06:43] <spiv> Anyway, I think the answers are "no" and "yes", respectively ;)
[06:43] <spiv> flush_database_updates() makes me nervous, it's a big hammer and we overuse it.
[06:44] <spiv> But we really want to be able to do syncUpdate one way or another, because it's so useful in tests.  So I think it's OK to allow it through the security proxies.
[06:48] <jamesh> that should have been 'do we'
[06:49] <jamesh> do you think an extra interface as a parent would be the way to do it?
[06:50] <jamesh> there is sqlos.interfaces.ISQLObject, but it exposes a lot more than we'd usually want to
[06:50] <jamesh> (destroySelf and set)
[06:50] <spiv> I think that would be the way, yeah.  It's a large change, though.
[06:50] <jamesh> I suppose sync() and syncUpdate() are always safe.
[06:50] <spiv> Which is why I'm ambivalent about it, I can't quite convince myself it's worth the benefit.
[06:51] <jamesh> (although overusing them can be a perf issue)
[06:51] <spiv> They should be.
[06:51] <spiv> Right, but lots of things are perf issues when overused :)
[06:51] <spiv> And they're much less of a perf issue than flush_database_updates.
[06:51] <jamesh> of course, they should be cheaper than flush_database_updates() ./..
[06:57] <jamesh> got any ideas about an interface name?
[06:57] <spiv> I'd say "ISQLObject" if we didn't already have one.
[06:58] <spiv> ISQLObjectSyncable?
[06:58] <jamesh> in practice there is nothing wrong with duplicate interface names ...
[07:00] <spiv> It's potentially confusing, and annoying if we want to import both into the same module for some reason.
[07:00] <spiv> But maybe it's ok here.
[07:00] <jamesh> would I have a rubberstamp for adding ISQLObjectSyncable?
[07:01] <kwwii> moin
[07:01] <spiv> I'm ok with that, but it's probably worth getting a 3rd opinion.  A pity SteveA's at europython.
[07:01] <kwwii> one small question: does the "fix committed" status mean that the bug should now be fixed?
[07:02] <spiv> kwwii: It generally means it's fixed in the development version, but not yet in the released version.
[07:02] <jamesh> kwwii: "fix committed" is meant to mean "the fix has been committed to version control", and "fix released" means "a new release with the fix is available"
[07:02] <kwwii> spiv: cool, thanks :-) I won't waste anyones time in responding that the bug is still there
[07:02] <spiv> If you're talking about Launchpad, then it means we've committed a fix into our sourcecode repository, and it will be included in an upcoming production update.
[07:03] <kwwii> jamesh: excellent, good thing I asked
[07:03] <spiv> Which usually happen weekly.
[07:03] <jamesh> kwwii: for distributions, that might mean "I've made a fixed package", and "it has been accepted into the repository and you should be able to install it"
[07:03] <kwwii> cool
[07:06] <kwwii> ok, back to work...thanks for the quick answer :-)
[08:20] <spiv> I've figured out some of the intermittent bzr failures.
[08:21] <spiv> It's running too fast ;)
[08:21] <spiv> I've posted an analysis to the lp list.
[08:22] <jamesh> so it is throwing away the subsecond accuracy of the stat data?
[08:23] <spiv> jamesh: look at the _fingerprint function in bzrlib/hashcache.py
[08:24] <spiv> jamesh: The short answer is "yes"
[08:24] <jamesh> spiv: yeah.  I was looking at your email.
[08:24] <spiv>     # we discard any high precision because it's not reliable; perhaps we
[08:24] <spiv>     # could do better on some systems?
[08:25] <jamesh> I wonder what systems subsecond accuracy is not reliable?
[08:25] <jamesh> I mean, it might not be present on some systems, but I'd expect it to be reliable if present
[08:26] <jamesh> (assuming you account for the errors introduced by python converting the times to floats
[08:27] <spiv> Yeah, that comment is a mystery to me.
[08:27] <jamesh> e.g. using long(fs.st_mtime * 1000000) should be as reliable
[08:28] <spiv> bzr annotate blames r866, by mpool.
[08:29] <spiv> Which is very slightly less than a year old :)
[08:39] <jamesh> the floating point comparison is the only issue I can think of,  The Python stat values are created with the following:
[08:39] <jamesh>                 fval = PyFloat_FromDouble(sec + 1e-9*nsec);
[08:43] <jamesh> I don't seem to get any subsecond accuracy even after calling os.stat_float_times(True)
[08:44] <jamesh> wonder if ext3 records it
[08:48] <jamesh> spiv: looks like ext3 doesn't do nanosecond accuracy in mainline, so even if bzrlib wasn't truncating to integer times, the problem would persist
[08:49] <Keybuk> ext3 doesn't do nanosecond accuracy
[08:49] <Keybuk> however the page cache *does*
[08:49] <Keybuk> and you're almost never going to have a file flushed out of the cache within a second
[08:50] <jamesh> spiv: so time.sleep() would probably fix it :)
[08:53] <jamesh> or play around with the times with os.utime()
[08:55] <Keybuk> isn't bzr supposed to discard hashcache entries from the same second?
[08:55] <spiv> I don't know what it's supposed to do, but I can tell you what it does ;)
[08:57] <spiv> When comparing the working tree to the hash cache, it checks the stat information, intentionally ignoring subsecond information, to check if the files are the same.
[08:57] <spiv> So we're seeing intermittent failures because sufficiently rapid sequences of commits of simple (i.e. single file) trees in the test suite are occasionally bombing out because they think there's nothing to commit.
[08:58] <spiv> (in bzr's own test suite)
[08:58] <Keybuk> right
[08:59] <Keybuk> the theory from waaayyy back was that if it found a hash cache entry which, rounded to the nearest second, was the same time as NOW, then it would ignore it
[08:59] <jamesh> I wonder if the problem has been addressed since we last updated bzr in our tree?
[08:59] <spiv> jamesh: nope
[08:59] <spiv> jamesh: well, the _fingerprint function at least hasn't changed.
[09:00] <spiv> jamesh: I guess there could be smarts like Keybuk just described elsewhere, but _fingerprint would be the sensible place to put it.
[09:00] <spiv> Keybuk: that sounds like a good idea, but I haven't seen any sign of it in my skimming of the source.
[09:29] <mpt> oh, there's already a bug report about it
[09:29] <mpt> reported by me, even!
[09:30] <mpt> Forgetful minds think alike
[10:10] <one> ?
[10:16] <one> ?
[10:32] <doko_> Keybuk: no, python-tk isn't built from python-defaults
[10:33] <Keybuk> it was
[10:33] <Keybuk> https://launchpad.net/distros/ubuntu/+source/python-defaults/2.4.3-1ubuntu1
[10:34] <doko_> yes, and the last version was 2.4.3-1ubuntu1, and 2.4.3-1ubuntu2 (built from python-stdlib-extensions) isn't in the archive
[10:34] <Keybuk> ^ clearly has python-tk and python-gdbm in it
[10:34] <Keybuk> why do you think python-stdlib-extensions is 2.4.3-1ubuntu2 ?
[10:34] <Keybuk> python-stdlib-extensions is 2-0ubuntu1
[10:34] <Keybuk> 2-0ubuntu1 < 2.4.3-1ubuntu1
[10:35] <Keybuk> so the binaries built by python-stdlib-extensions are older than what's there
[10:35] <Keybuk> so they won't show up
[10:35] <Keybuk> https://launchpad.net/distros/ubuntu/+source/python-stdlib-extensions/2-0ubuntu1
[10:35] <doko_> Keybuk: no, look a the binary versions, not the source version
[10:35] <doko_> s/a/at/
[10:35] <Keybuk> bet LP doesn't do binary versions
[10:36] <Keybuk> given that it's UI doesn't seem to expose them
[10:36] <doko_> http://librarian.launchpad.net/3271744/buildlog_ubuntu-edgy-i386.python-stdlib-extensions_2-0ubuntu1_FULLYBUILT.txt.gz
[10:36] <Keybuk> doko: note "changes file not available"
[10:36] <Keybuk> tbh, at this point you need a soyuz engineer
[10:37] <Keybuk> I expect you've found a katie/deb feature they didn't know about <g>
[10:37] <doko_> ok
[10:39] <Keybuk> for reference, the queue entry was
[10:39] <Keybuk>    64293 | -B | python-stdlib-extens | 2-0ubuntu1           | 11 hours
[10:39] <Keybuk>          | * python-gdbm/2.4.3-1ubuntu2/ia64 Component: main Section: python Priority: OPTIONAL
[10:39] <Keybuk>          | * python-tk/2.4.3-1ubuntu2/ia64 Component: main Section: python Priority: OPTIONAL
[10:40] <Keybuk> 16:03:06 DEBUG   Publishing source python-stdlib-extensions/2-0ubuntu1 to
[10:40] <Keybuk> +ubuntu/edgy
[10:42] <Keybuk> 22:03:05 DEBUG   Publishing build to ubuntu/edgy/ia64
[10:42] <Keybuk> 22:03:05 DEBUG   ... python-gdbm/2.4.3-1ubuntu2 (Arch Specific)
[10:42] <Keybuk> 22:03:05 DEBUG   ... python-tk/2.4.3-1ubuntu2 (Arch Specific)
[10:42] <Keybuk> 22:09:47 DEBUG   Added
[10:42] <Keybuk> +/srv/launchpad.net/ubuntu-archive/ubuntu/pool/main/p/python-stdlib-extensions/p+ython-gdbm_2.4.3-1ubuntu2_ia64.deb from library
[10:42] <Keybuk> 22:09:47 DEBUG   Added
[10:42] <Keybuk> +/srv/launchpad.net/ubuntu-archive/ubuntu/pool/main/p/python-stdlib-extensions/p+ython-tk_2.4.3-1ubuntu2_ia64.deb from library
[10:43] <malcc> Hmm
[10:44] <Keybuk> it's on the archive on drescher
[10:45] <Keybuk> but only the ia64 deb
[10:45] <Keybuk> looks like the others got lost
[10:45] <Keybuk> malcc: some debugging for you there
[10:45] <malcc> Keybuk: Ta
[10:46] <Keybuk> malcc: interesting that the build record doesn't have the changes file
[10:52] <doko_> malcc: submitted bug 52064
[10:52] <Ubugtu> Malone bug 52064 in launchpad "soyuz confused by version numbers different in source/binaries" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52064
[10:53] <malcc> doko_: Thanks
[10:59] <Keybuk> note that it's not necessarily that which has happened
[10:59] <Keybuk> it could be the fact there's no changes file from the buildd
[11:20] <malcc> The four architectures which didn't get their builds for python-stdlib-extensions, plus some other build results, seem to be backed up from last night
[11:20] <malcc> Could be knock-on effects from the troubles and the reboot; I don't want to mess until someone who knows more turns up, but I suspect these can be given a kick and will then all turn up fine
[11:27] <mpt__> bother
[11:28] <mpt__> malcc, make check_merge keeps hanging for me in either pagetests/soyuz/23-sourcepackage-hctstatus.txt or 25-binarypackagenames.txt
[11:28] <mpt> Are you familiar enough with the tests yet to have any idea why? :-)
[11:28] <malcc> mpt: Bummer. I don't think those do anything odd, but I'll take a look.
[11:29] <mpt> actually, it'll be 25-binarypackagenames.txt
[11:29] <mpt> the output is "    /home/mpt/hackiTests hung - no output for 600 seconds. Killing ... Not dead yet!  - slaughtering mercilessly"
[11:30] <mpt> where "/home/mpt/hacki" is the beginning of the path of 25-bpn
[11:30] <malcc> mpt: I can't see anything odd in that test, and certainly nothing odd enough to break the test engine half way through printing a path
[11:31] <lifeless> malcc: deadlocks
[11:31] <malcc> mpt: I suggest you've got a ghost in the machine in fact unrelated to these thoroughly unremarkable tests
[11:31] <lifeless> malcc: specifically, stderr is probably full
[11:31] <lifeless> malcc: no ghosts
[11:31] <mpt> It's the third time exactly that test has failed
[11:32] <mpt> The first thing the test does is ask for http://localhost/binarypackagenames, and the URL gives me a 404
[11:32] <lifeless> malcc: we have a wrapper around the tests, it reads the stderr/stdout and shows them
[11:32] <mpt> though launchpad.dev/binarypackagenames works
[11:32] <lifeless> malcc: I strongly suspect its a full pipe deadlock. Until the parent does a read on the other pipe, the child will not resume. And the parent is blocked reading from the first pipe.
[11:32] <lifeless> or something like that
[11:33] <malcc> mpt: I'm pretty sure localhost is ok in pagetests, even though it doesn't work in development
[11:33] <mpt> ok
[11:34] <malcc> lifeless: Your theory sounds reasonable, given I know very little about all that. If you're correct, what does that mean we do to fix it?
[11:35] <lifeless> check run_test.py or whatever it is. See if it drills down to a select loop on the two pipes. If it does not, then we should convert it to do that, i.e. using twisted's processprotocol rather than subprocess, or some similar tool
[11:38] <mpt> Running the soyuz story by itself works
[11:41] <malcc> mpt: I'm betting on lifeless' idea, I'm just checking the code in test_on_merge now to see if its subprocess handling is suspect
[11:42] <Atomyc> hello..
[11:42] <Atomyc> anybody here..
[12:17] <malcc> lifeless: To my limited knowledge, test_on_merge looks ok. It uses popen with stderr=STDOUT then uses a select loop.
[12:17] <malcc> On stdout
[12:26] <jamesh> spiv: I've got a branch up for review now that fixes the branch scanner bug that turned up (and should reduce the chance of similar bugs in the future)
[12:31] <lifeless> malcc: ok.
[12:33] <lifeless> that means someone needs to talk mpt though attaching gdb and getting a backtrace from both the child process and the parent process, to understad where and how it is borked.
[12:39] <mpt> goody
[12:51] <mpt> BjornT!
[12:51] <mpt> I have a problem with getLink
[12:57] <jamesh> mpt: I expanded the PythonBugTrackerCompetition page earlier this week.  Haven't looked at updating the wiki syntax spec implementation section.
[12:58] <mpt> BjornT, the problem is a bit complicated for IRC, I've replied to you on launchpad-reviews
[01:00] <mpt> jamesh, ok
[01:04] <malcc> Keybuk, doko: The problem with python-stdlib-extensions is confirmed to be unrelated to names/versions etc., it was just some Soyuz build results stuck after drescher problems yesterday. Kinnison has unstuck them and everything should be fine now.
[01:04] <Keybuk> malcc: cool
[01:04] <Keybuk> general bug/feature request -- the UI could do with showing binary version numbers :p
[01:04] <doko> malcc: thanks
[01:05] <malcc> Keybuk: Which pages are missing binary version numbers where they'd be useful to you?
[01:06] <Keybuk> malcc: well, the fact there's no publishing history pages for binaries
[01:06] <Keybuk> anywhere
[01:08] <malcc> Keybuk: Really? I assumed I just hadn't found them yet
[01:08] <Keybuk> there could be some secret unlinked page somewhere
[01:08] <Keybuk> but not one I'm aware of
[01:09] <Keybuk> currently the soyuz UI is a bit "here's some sources, here's what happened to the sources, oh and they got built, but HERE'S MORE SOURCES"
[01:10] <Kinnison> Everyone loves the source dude
[01:12] <Kinnison> Erm /distros/ubuntu/edgy/i386/python-support
[01:13] <Kinnison> witness the binary pub hist
[01:13] <malcc> Yay
[01:14] <malcc> My faith that Soyuz can infact give you anything you want if you can only penetrate the Barrier of Confusion (tm) has been restored
[01:16] <mpt> I understand how people use Malone
[01:16] <mpt> and I understand how people use Rosetta
[01:16] <mpt> I don't understand how people use Soyuz.
[01:27] <Kinnison> mpt: don't watch me then, 'cos I type URLs
[01:30] <mpt> Kinnison, I suspect most people do that for Malone too :-)
[01:30] <mpt> (I certainly do)
[01:30] <mpt> or bookmarks
[01:51] <mpt> bug 12345
[01:51] <Ubugtu> Malone bug 12345 in isdnutils "isdn does not work, fritz avm (pnp?)" [Medium,Fix released]  http://launchpad.net/bugs/12345
[01:52] <mpt> This has been a test of the Ubugtu system
[01:54] <kiko> hello hello
[01:54] <Kamion> publisher crash: http://librarian.launchpad.net/3282274/petQjyUqbU2w58HGOQLKrOCh3PF.txt
[01:54] <kiko> are people ready for the most important moment of the week!
[01:54] <Znarl> stub : Ping?
[01:55] <Kamion> IOError: [Errno 2]  No such file or directory: '/srv/launchpad.net/ubuntu-archive/ubuntu/pool/universe/h/haskell-src-exts/libghc6-harp-dev_0.2-5_amd64.deb'
[01:55] <stub> Znarl: pong
[01:55] <malcc> kiko: It's time already for the sunday morning Hollyoaks omnibus edition?
[01:55] <Znarl> stub : chinstrap is getting slow rsyncing launchpad production logs again.  Can you rotate them?
[01:55] <Kamion> which is frankly just bizarre, given that it's trying to publish that
[01:55] <kiko> malcc, not that moment -- the other one!
[01:55] <stub> Znarl: ok.
[01:55] <Znarl> Thanks.
[01:56] <SteveA> hello
[01:56] <kiko> SteveA!
[01:56] <kiko> are you going to be presiding this week after all?
[01:56] <SteveA> hi kiko
[01:56] <SteveA> i haven't prepared, but I'll be here
[01:56] <kiko> is that a yes or a no? :)
[01:56] <salgado> stub, did something go wrong with yesterday's nightly.sh run?
[01:56] <kiko> https://launchpad.canonical.com/MeetingAgenda
[01:57] <Kamion> I'm going to hope that the publisher runs successfully next time round
[01:57] <stub> salgado: I killed some of the processes because I needed to grab locks on some tables if that is what you are looking at.
[01:57] <kiko> SteveA?
[01:58] <SteveA> kiko: i'll do it
[01:58] <salgado> stub, I asked because the mirror prober reported that no mirrors were probed
[01:58] <kiko> yayzers
[01:58] <stub> salgado: That wasn't me
[01:59] <stub> I've never seen it actually probe a mirror
[02:00] <kiko> I have
[02:00] <salgado> it's been probing lots of them, since almost two weeks
[02:00] <mpt> meeeeee
[02:00] <kiko> me
[02:00] <malcc> me
[02:00] <SteveA> Hello
[02:00] <SteveA> launchpad meeting
[02:00] <SteveA> who is here?
[02:00] <mpt> MEETING TIME
[02:00] <bradb> me
[02:00] <salgado> me
[02:00] <kiko> o/~ Is it me you're looking for? o/~
[02:00] <flacoste> me
[02:00] <mpt> that's what I was trying to say
[02:00] <stub> me
[02:00] <mpt> me
[02:00] <kiko> me
[02:00] <malcc> me
[02:00] <jamesh> me
[02:00] <cprov> me
[02:01] <Kinnison> me
me
[02:01] <matsubara> me
[02:01] <SteveA> cool
[02:01] <SteveA> == Agenda ==
[02:01] <SteveA> * Roll call * Agenda * Next meeting * Activity reports * Actions from last meeting * Oops report (Matsubara) * Bug report report (mpt) * Sysadmin requests * Production and staging (Stuart)
[02:01] <SteveA> ---- * (other items)
[02:01] <SteveA> argh
[02:01] <SteveA> ---- * Keep, Bag, Change * Three sentences
[02:01] <SteveA> irssi sucks for this
[02:02] <SteveA> but irc is banned at cern
[02:02] <SteveA> so i must go vi ssh
[02:02] <jamesh> ssh port forwarding
[02:02] <kiko> is the future
[02:03] <SteveA> ok
[02:03] <SteveA> next meeting... same time next week?
[02:03] <stub> whatever
[02:03] <kiko> yes.
[02:03] <SteveA> cool.  someone please set the channel title appropriately.
[02:03] <SteveA> ta
[02:03] <SteveA>  * Activity reports
[02:03] <SteveA> i suck.  anyway, i've been at europython.
[02:04] <salgado> I'm up to date
[02:04] <kiko> I'm half-sucky
[02:04] <Kinnison> I am not up-to-date. I have sketchy notes but I've worked a lot of last week on paper rather than on the laptop.
[02:04] <stub> Up to date
[02:04] <cprov> I'm up to date
[02:04] <lifeless> @europython
[02:04] <stub> paper?
[02:04] <jamesh> I'm not up to date
[02:04] <bradb> up to date, less sprints
[02:04] <matsubara> up to date
[02:04] <kiko> I was sprinting last week and this week has been context-switch festival
[02:04] <Kinnison> stub: It's old-school technology
[02:04] <malcc> Up to date
[02:04] <mpt> one day behind (and I've been batching)
[02:04] <matsubara> I'm also guilty of batching
[02:04] <SteveA>  * Actions from last meeting
[02:05] <spiv> here
[02:05] <SteveA>  * Steve to ask Kiko to run next week's meeting
[02:05] <SteveA> ah, well, anyway
[02:05] <SteveA>  * everyone (including those not at the meeting): read https://wiki.canonical.com/SysAdminRtUsageGuide and subscribe to it
[02:05] <spiv> And I'm behind on activity reports. :(
[02:05] <SteveA> please say "read" or "not read" according to whether you have read that page yet.
[02:05] <malcc> read
[02:05] <SteveA> read
[02:05] <spiv> read
[02:05] <Kinnison> read
[02:06] <kiko> I read it and used the advice in there
[02:06] <matsubara> read and subscribed
[02:06] <bradb> read
[02:06] <mpt> read
[02:06] <lifeless> read
[02:06] <SteveA> most excellent
[02:06] <salgado> read
[02:06] <jamesh> read
[02:06] <stub> read
[02:06] <mpt> most of us are also subscribed
[02:06] <cprov> read
[02:07] <SteveA>  * Oops report (Matsubara)
[02:07] <matsubara> Today's oops report is about bugs 44860, 42755, 2497, 51097 and 30602
[02:07] <Ubugtu> Malone bug 44860 in rosetta "Crash when we try to pass a query string to a POFile that doesn't exist yet." [Medium,Confirmed]  http://launchpad.net/bugs/44860
[02:07] <Ubugtu> Malone bug 2497 in rosetta "/people/*/+translations times out for prolific translators" [Medium,Confirmed]  http://launchpad.net/bugs/2497
[02:07] <Ubugtu> Malone bug 51097 in rosetta "Selection of untranslated entries is too slow" [High,Confirmed]  http://launchpad.net/bugs/51097
[02:07] <Ubugtu> Malone bug 30602 in rosetta "ERROR IN: https://launchpad.net/distros/ubuntu/dapper/+source/vlc/+pots/vlc/tl/+translate" [Medium,Confirmed]  http://launchpad.net/bugs/30602
[02:07] <matsubara> Kiko any news about bug 42755. Is that fix going to address comments on tickets also?
[02:08] <matsubara> hmm carlos isn't here...
[02:08] <kiko> stub, would you have time to work on bug 2497? I have a simple-ish plan for it
[02:08] <Ubugtu> Malone bug 2497 in rosetta "/people/*/+translations times out for prolific translators" [Medium,Confirmed]  http://launchpad.net/bugs/2497
[02:08] <kiko> bug 42755 you say?
[02:08] <stub> kiko: Mark is pushing me to work on CanonicalPillarNames
[02:08] <kiko> yeah, that's true.
[02:08] <kiko> stub, let's do that call after the meeting
[02:09] <stub> k
[02:09] <matsubara> Top time outs are on +translate(51097 and 30602) and +translations(2497) page.
[02:09] <matsubara> The only one not assigned is 30602, want to take that kiko?
[02:09] <kiko> matsubara, that's better a carlos bug really
[02:09] <matsubara> I'll talk to him then
[02:09] <matsubara> and lastly, pqm is rejecting my commit attempts.
[02:09] <bradb> Me Too
[02:09] <matsubara> is there anyone looking on that problem?
[02:10] <spiv> matsubara: Did you see my email to the list?
[02:10] <lifeless> can you be more specific ?
[02:10] <spiv> matsubara: I suggest just keep trying, the bzr failures are intermittent due to a race condition.
[02:10] <matsubara> lifeless: random test failures. I mailed the list with the failures I got
[02:10] <spiv> matsubara: I had the same failure as you, got through the second time though.
[02:10] <matsubara> spiv: I've seen it, thanks for looking on it.
[02:11] <matsubara> I tried 5 times yesterday, I'll keep on trying then.
[02:11] <spiv> Wellk, the same as three of yours, haven't looked at all of yours though :)
[02:11] <kiko> lifeless, can you please disable that test for now?
[02:11] <spiv> kiko: It's more than one tests.
[02:11] <kiko> oh
[02:11] <spiv> one test, rather.
[02:11] <kiko> really?
[02:11] <lifeless> anyone in the lp team can commit to the p copy of bzr
[02:11] <lifeless> s/p / lp /
[02:11] <spiv> kiko: it's lots of them, any that make lots of small commits very quickly, which is at least three of them, judging from matsubara's failures.
[02:12] <lifeless> I am about to fly home, so no, I cannot do that.
[02:12] <kiko> lifeless, sure, but that's a judgement call that i'd rather you made
[02:12] <lifeless> it sounds like there is a real, valid bug in bzr though.
[02:12] <kiko> or authorize somebody to do it
[02:12] <lifeless> because the hashcache is meant to be race condition free.
[02:12] <kiko> lifeless, great. let's not let it stop launchpad development from happening though :)
[02:12] <spiv> I can call Martin tomorrow to discuss the problem if people want?
[02:12] <lifeless> for the record, I'm happy with ddaa or spiv or jamesh doing commits to bzr or bzrtools in the lp tree at any point.
[02:12] <lifeless> kiko: ^
[02:12] <kiko> lifeless, any commit? including not running bzr tests upon commit? :-)
[02:12] <spiv> And then do a commit to our bzr based on that conversatino.
[02:12] <lifeless> spiv: please do that, I was about to suggest asking Martin to treat it as urgent.
[02:13] <lifeless> kiko: if that is what it takes for a short period of time, then [grudgingly]  yes.
[02:13] <stub> I've also been seeing intermittent failures with cscvs. 
[02:13] <spiv> Ok, I'll do that.  In the in ~12 hours until then, just keep retrying :)
[02:13] <kiko> cool.
[02:13] <kiko> thanks
[02:13] <lifeless> kiko: however, I suggest talking with the sysadmins tonight
[02:13] <spiv> stub: Oh, that's one I'm not aware of.
[02:13] <lifeless> because this started happening 
[02:13] <stub> It may have been triggered by upgradinig Balleny to dapper.
[02:13] <lifeless> and nothing was changed in our copy of bzr or bzrtools when it started.
[02:13] <matsubara> stub: one of my test failures was related to that
[02:14] <lifeless> stub: I've never seen these failures on dapper on other machines.
[02:14] <lifeless> its even possible, that its a dapper bug
[02:14] <stub> lifeless: Machines that are 64 bit and as fast?
[02:14] <stub> I suspect timing issues
[02:14] <lifeless> stub: FSVO 'as', yes.
[02:14] <lifeless> stub: lets not get into a technical dsicussion right now.
[02:15] <lifeless> stub: I'm aware of the parameters.
[02:15] <matsubara> ok, SteveA, kiko I'm done with the oops report
[02:15] <kiko> thanks matsubara 
[02:15] <matsubara> thanks all
[02:15] <SteveA> thanks matsubara
[02:15] <SteveA>  * Bug report report (mpt)
[02:15] <mpt> The oldest, most important bugs this week are:
[02:15] <mpt> bug 1294, assigned to bradb
[02:15] <Ubugtu> Malone bug 1294 in malone "Filing a private bug requires the ability to Cc the maintainer" [Critical,Confirmed]  http://launchpad.net/bugs/1294
[02:15] <kiko> matsubara, to answer your question, no, it won't solve +ticket timeouts.
[02:15] <mpt> bug 6459, assigned to carlos
[02:15] <Ubugtu> Malone bug 6459 in rosetta "Timeout error on distribution release language page" [Critical,In progress]  http://launchpad.net/bugs/6459
[02:16] <mpt> bug 31308, not assigned
[02:16] <Ubugtu> Malone bug 31308 in launchpad-bazaar "Cannot set branch associated to a product series" [Critical,Confirmed]  http://launchpad.net/bugs/31308
[02:16] <matsubara> kiko: I'll file a new one then, thanks
[02:16] <mpt> bug 36060, assigned to bradb
[02:16] <Ubugtu> Malone bug 36060 in malone "Bug needs a date last updated column" [Critical,Fix committed]  http://launchpad.net/bugs/36060
[02:16] <mpt> bug 37866, assigned to kiko
[02:16] <Ubugtu> Malone bug 37866 in malone "+editstatus should not accept binary package as source package" [Critical,Fix committed]  http://launchpad.net/bugs/37866
[02:16] <mpt> and bug 37897, assigned to ddaa
[02:16] <Ubugtu> Malone bug 37897 in launchpad-bazaar "renaming project, product or series breaks vcs imports" [Critical,Confirmed]  http://launchpad.net/bugs/37897
[02:16] <mpt> carlos and bradb, how are you doing with those?
[02:16] <mpt> and who should take 31308?
[02:16] <jamesh> mpt: some of those bugs you listed are fix committed
[02:16] <mpt> oh, carlos isn't here
[02:17] <elmo> we just a lost an apps server
[02:17] <mpt> jamesh, I realize that -- they should be verified
[02:17] <mpt> and marked as fix released
[02:17] <elmo> stub: ping?
[02:17] <kiko> mpt, as per bug 37866. we need to clean up sourcepackagename now :-(
[02:17] <Ubugtu> Malone bug 37866 in malone "+editstatus should not accept binary package as source package" [Critical,Fix committed]  http://launchpad.net/bugs/37866
[02:17] <mpt> does 31308 belong to ddaa?
[02:18] <bradb> 1294 I'll fix in probably the next few days
[02:19] <flacoste> matsubara: the ticket timeout problem is mentioned on bug 37865
[02:19] <Ubugtu> Malone bug 37865 in launchpad-support-tracker "Support listing could use a list similar to the bug listing" [Medium,Unconfirmed]  http://launchpad.net/bugs/37865
[02:19] <mpt> anybody? :-)
[02:19] <jamesh> mpt: I guess it is.  I'm not sure 31308 is critical though
[02:19] <matsubara> flacoste: it's not that one. I mean the timeout when a ticket has too many comments
[02:19] <mpt> ok. kiko, do you have time for 37866, or should it go to someone else?
[02:19] <lifeless> ddaa, stevea and I have spoken about 31308
[02:20] <lifeless> it is currently critical as it completely mucks up the user experience for bzr use with lp, for native upstreams
[02:20] <kiko> mpt, I doubt anybody else will actually do what needs to be done there, which is basically researching what sourcepackagenames need to be killed and moving bugs back
[02:20] <lifeless> but we can do a short fix, and downgrade it, though it will not be the 'entire fix'.
[02:20] <mpt> lifeless, maybe you can summarize your discussion in the bug report
[02:21] <mpt> SteveA, I'm done.
[02:21] <SteveA> thanks
[02:21] <SteveA>  * Sysadmin requests
[02:21] <SteveA> 6
[02:21] <SteveA> 5
[02:21] <SteveA> 4
[02:21] <SteveA> 3
[02:21] <SteveA> 2
[02:21] <SteveA> 1
[02:21] <SteveA> cool
[02:21] <kiko> I asked them something
[02:21] <kiko> ah
[02:21] <SteveA>  * Production and staging (Stuart)
[02:21] <kiko> to open up the launchpad.net stats they are already generating
[02:21] <kiko> it's currently IP-protected
[02:21] <stub> Nothing thrilling is happening with production or staging. I have an outstanding cherry pick to push out for Carlos.
[02:21] <stub> I expect the next rollout will be on Tuesday, rolling out HEAD as of now unless people tell me otherwise.
[02:22] <SteveA> thanks stub
[02:22] <SteveA>  * booking flights for launchpad sprints
[02:23] <jamesh> stub: I've got a branch pending review to fix the branch scanner.  It'll probably need to be cherry picked
[02:23] <SteveA> I want to find out who has arranged travel for the launchpad sprints, and who has not.  please say "all arranged" or "partially arranged" or "not yet arranged"
[02:23] <SteveA> all arranged
[02:23] <spiv> all arranged
[02:23] <stub> not yet arranged
[02:23] <jamesh> all arranged
[02:23] <mpt> n/a
[02:23] <Kinnison> "will either buy train ticket or diesel on the day"
[02:24] <malcc> Nothing to arrange
[02:24] <matsubara> not yet arranged, I think
[02:24] <cprov> not yet arranged
[02:24] <matsubara> kiko: should I mail james about it?
[02:24] <bradb> nothing to arrange
[02:24] <flacoste> n/a
[02:24] <kiko> matsubara, sure
[02:25] <SteveA> ok, thanks
[02:25] <SteveA>  * Everyone to note that lifeless should be cc-ed on PQM-related RT issues (Steve)
[02:25] <SteveA> please note that lifeless should be cc-ed on any PQM-related RT issues
[02:25] <kiko> matsubara, ask taciana to sort it out
[02:25] <matsubara> kiko: I'll thanks.
[02:25] <SteveA>  * pqm and bzr test suite (kiko)
[02:26] <kiko> SteveA, already resolved.
[02:26] <SteveA> cool
[02:27] <SteveA>  * Keep, Bag, Change
[02:27] <SteveA> 5
[02:27] <SteveA> 3
[02:27] <SteveA> 1
[02:27] <kiko> keep: staging working (it's currently not)
[02:27] <malcc> Keep: The numbers 4 and 2
[02:28] <stub> BAG: Running test suites of non-interdepandant packages on Launchpad commit. It gives us little or no gain but large downsides.
[02:28] <kiko> stub, hmmm, so no cscvs or bzr tests? 
[02:28] <spiv> kiko: Well, commits to lp cannot break bzr.
[02:28] <spiv> kiko: but commits to bzr can break lp.
[02:28] <spiv> kiko: so in one case we need to run both bzr and lp tests, but not in both.
[02:28] <kiko> is that feasible?
[02:29] <SteveA> i agree with this.  it means developing a way to represent these dependencies
[02:29] <stub> Indeed. And if bzr is screwing up, there is no reason to block Launchpad commits.
[02:29] <SteveA> and then teaching pqm how to understand that for running test suites
[02:29] <SteveA> it is not trivial
[02:29] <SteveA> it requires a spec
[02:29] <stub> Or cscvs, or twisted, or any of the one-way dependancies
[02:29] <kiko> could we not just special-case launchpad
[02:29] <kiko> since it would give us the most bang for the least buck
[02:29] <kiko> so something like
[02:29] <kiko> if committing_to(launchpad):
[02:29] <kiko>    run_lp_tests()
[02:29] <kiko> else:
[02:29] <spiv> kiko: no, there's some stuff like hct that depends on lp
[02:30] <kiko>    run_all_tests()
[02:30] <kiko> so add a run_hct_tests() in there
[02:30] <SteveA> kiko: propose that on the lp list, so lifeless can contribute when he gets home
[02:30] <kiko> but anyway, strawman :)
[02:30] <stub> As far as I can see, we just need two make check rules. One run when launchpad commits are made and one when other commits are made.
[02:31] <SteveA>  * Three sentences
[02:31] <SteveA> please go ahead
[02:31] <mpt> DONE: Rosetta hacking, specifications, non-Landscape work
[02:31] <mpt> TODO: land Rosetta branch, LaunchpadLoginService, MaloneSimplifications
[02:31] <mpt> BLOCKED: Kiko, e-mail + code review; carlos/jordi, import policy update
[02:31] <spiv> stub: it's not so much about make check rules as about how we configure PQM
[02:31] <stub> DONE: bug fixes 'n' stuff
[02:31] <spiv> DONE: reviews, fixed bug 50473, finally merged fix for 33223, fixed 39814.
[02:31] <spiv> TODO: reviews, continue work on bzr smart server, sftp bugs.
[02:31] <spiv> BLOCKED: no.
[02:31] <stub> TODO: CanonicalPillarNames
[02:31] <stub> BLOCKED: No
[02:31] <Ubugtu> Malone bug 50473 in glibc "Problem with locales in update of Dapper Drake to Edgy" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/50473
[02:31] <matsubara> DONE: oops report analysis, fixed some validations bugs, traversal bugs, test conversion.
[02:31] <matsubara> TODO: bug fixing (product ownership reassignement and oops bugs) and more triage
[02:31] <matsubara> BLOCKED: no
[02:31] <malcc> DONE: Soyuz troubleshooting, publish-distro-optimization testing, merged cprov's dak-tools branch into publish-distro-optimization.
[02:31] <malcc> TODO: Finish publish-distro-optimization testing, cron.daily changes, merge and land some branches.
[02:31] <malcc> BLOCKED: No.
[02:31] <bradb> DONE: Landed attach-while-commenting. Resurrected fix for bug 41399. Started working on some of the release management stuff spec'd in London.
[02:31] <Ubugtu> Malone bug 41399 in malone "Error message not specific in bug-reporting page (+filebug)" [High,In progress]  http://launchpad.net/bugs/41399
[02:31] <kiko> DONE: sprint, webserver stats, catching up with 800+ emails, planning
[02:31] <flacoste> DONE London sprint, write support tracker specifications, investigated ticket search
[02:31] <bradb> TODO: Release management. XMLRPC.
[02:31] <flacoste> TODO complete ticket search
[02:31] <flacoste> BLOCKED waiting on mpt and kiko feedback for support tracker workflow spec
[02:31] <bradb> BLOCKED: No.
[02:31] <kiko> TODO: some performance work, reviews
[02:31] <kiko> BLOCKED: no
[02:31] <salgado> DONE: Attended Support Tracker sprint, code review, email catch up and worked on KarmaContext
[02:31] <salgado> TODO: Finish KarmaContext and land it, random bugs and code review
[02:31] <salgado> BLOCKED: No
[02:32] <jamesh> DONE: code reviews, dyson to urllib work, fix branch scanner bustage
[02:32] <jamesh> TODO: code reviews, finish off dyson stuff, look at wiki markup spec for mpt
[02:32] <jamesh> BLOCKED: no
[02:32] <cprov> DONE: archive-tools, bug fixes in queue UI
[02:32] <cprov> TODO: cron.daily fixes and start Build-Unpublished-Sources
[02:32] <cprov> BLOCKED: no
[02:32] <mpt> flacoste, I don't know what you're referring to, I haven't received any request for feedback
[02:32] <Kinnison> DONE: lots of design work around PPA. Helped resolve various build/buildqueue problems. Pre-pre-implementation call for PPA with sabdfl. Attempted again to learn {ME,}TAL{,ES}.
[02:32] <Kinnison> TODO: Reach pre-impl stage on PPA, actually get around to sorting my pending branches.
[02:32] <Kinnison> BLOCKED: none.
[02:32] <stub> spiv: I don't think there is any reason that commits to launchpad branches don't trigger 'make check' and commits to the other branches trigger 'make fullcheck'. I think we just run the same command at the moment because Robert wants it that way.
[02:33] <flacoste> mpt: ok, I thought the spec tracker sent email notification on request for feedback, I'll send you an email then
[02:33] <spiv> stub: right, because it's the simplest way to make sure all tests pass always, but we can optimise.
[02:33] <mpt> flacoste, it's a bug reported in Blueprint, feedback requests don't
[02:34] <SteveA> any blockers or other issues not dealt with?
[02:34] <mpt> yes, mine :-)
[02:34] <lifeless> see you all monday
[02:34] <mpt> kiko, if you're busy maybe you can get lifeless to reallocate the branch?
[02:34] <stub> lifeless: You not stopping in Bangkok on the way back?
[02:35] <lifeless> stub: no, it routes via hong kong
[02:35] <lifeless> stub: I would have liked to stop by
[02:35] <stub> Next time ;)
[02:35] <lifeless> stub: we have bidirectional dependencies on lp.
[02:35] <kiko> mpt, what is this about?
[02:36] <spiv> kiko: you have review in your queue that's 10 days old.
[02:36] <lifeless> stub: specifically hct and importd and IIRC a couple others
[02:36] <mpt> kiko, (1) my needs-review branch is in your queue, and (2) I e-mailed you 1.5 weeks ago about arranging a phone call, and pinged you 0.5 weeks ago as a reminder
[02:36] <stub> lifeless: Yes, but not all the externals are bidirectional. We can reduce problems if we only run the tests suites on those ones rather than everything.
[02:36] <lifeless> agreed. as steve said - a spec is needed.
[02:36] <lifeless> gotta run, bus to catch. tchau
[02:37] <spiv> lifeless: happy travels!
[02:37] <mpt> kiko, (1) is nearly two weeks old now, so maybe it should go to another reviewer
[02:37] <stub> I'll spec out the quick hack version in a spec that should keep us happy for the foreseeable future.
[02:37] <SteveA> i think that all remaining issues are between individual people, and not for the whole team
[02:37] <kiko> mpt, I was in London. did you try SteveA?
[02:37] <SteveA> so, thanks everyone
[02:37] <SteveA> MEETING ENDS
[02:37] <spiv> There's a "Rejected Reviews" section on the PendingReviews page just waiting to be used ;)
[02:38] <mpt> kiko, SteveA was the one who asked me to arrange it
[02:38] <Kamion> could I grab soyuz people for urgent publisher help nw?
[02:38] <Kamion> now
[02:38] <malcc> Kamion: sup?
[02:38] <fabbione> malcc: the world is in collision course with Mars
[02:38] <Kamion> the publisher has crashed twice in succession with the same error
[02:38] <Kamion> http://librarian.launchpad.net/3282692/petQjyUqbU2w58HGOQLKrOCh3PF.txt
[02:39] <stub> Had to wake up early?
[02:39] <Kamion> it was publishing that package in the last-but-one run, yet apparently objected to the package not being in the pool
[02:39] <Kamion> so I am now confused
[02:39] <bradb> stub: not really. i was up 3 hours ago.
[02:39] <bradb> gotta find some time in the day to learn Go
[02:39] <kiko> Kamion, that's odd. 
[02:40] <Kamion> indeed
[02:40] <bradb> heh
[02:40] <kiko> Kamion, I'm looking at the code.
[02:41] <Kinnison> Kamion: care to take this to ##soyuz1.0
[02:42] <kiko> stub, so, do you want to do that call now?
[02:43] <stub> I guess
[02:43] <kiko> stub, or in a moment?
[02:43] <kiko> I don't have skype
[02:43] <stub> Bah
[02:43] <stub> t
[02:45] <stub> kiko: I'm ready when you are
[02:45] <kiko> stub, do I call the 8862 number?
[02:45] <mpt> BjornT, thanks for your prompt reply -- should I assume that every Launchpadder is using an editor with "Remove trailing spaces when saving" or equivalent turned on?
[02:46] <stub> kiko: I doubt it. I don't have any number with 8862 in it.
[02:48] <bradb> mpt: I use Emacs's delete-trailing-whitespace fu
[02:48] <bradb> trailing whitespace is like dirt on the canvas
[02:53] <mpt> If I had that such an option turned on, and not everyone else did, I'd generate spurious diffs
[02:58] <flacoste> bradb: have you seen the 'About a month until PSF call for test tracker' email on python-announce?
[02:59] <bradb> nope, i don't read that list. but i'm aware of date posted on their call for trackers page.
[03:00] <bradb> s/of/of the/
[03:21] <SteveA> win 5
[05:15] <salgado> stub, ping?
[05:16] <stub> salgado: pong
[05:17] <salgado> stub, if I run the foaf-update-karma-cache.py script manually, shouldn't it create/update the cache entries on launchpad_dev?
[05:18] <stub> I think so, yes.
[05:22] <stub> kiko: I've bounced staging. Don't know why it locked.
[05:48] <kiko> thanks stub 
[05:49] <kiko> bradb, I'm out for lunch and then back we will chat on the topics of python.org and security bugs.
[05:49] <bradb> kiko: sounds good
[08:05] <Goxy> hi
[08:43] <jbailey> I'm just looking at doko's spec's, I'm curious why https://launchpad.net/people/doko/+specs includes canonical-support-categories.
[08:43] <jbailey> I don't see him on that spec, and I'm wondering if it's' somehow blending my specs and his on that page.
[08:44] <jbailey> Oh, he's in the subscriber set.  That's why.
[08:48] <bradb> BjornT: Is it okay to use database classes directly in vocabulary code?
[08:50] <kiko> it's okay but you go to jail afterwards :)
[09:23] <heno> anyone have any experience with importing ODF files to Rosetta? Via docbook perhaps? I'm looking to translate some example-content for Ubuntu
[09:24] <heno> I guess the docteam already import docbook files right?
[10:02] <mdke_> heno: rosetta needs gettext pot files, you have to have a toolchain for converting to that...
[10:02] <heno> ok, thanks
[10:59] <kiko> cprov, I haven't seen you had landed my fix for the timeout HTTP stuff! good on you!
[11:00] <cprov> kiko: was in my small-fixes, did I comment it properly ? I don't remember.