[12:59] hmm [12:59] queue-builder still doesn't appear to be working automatically [01:02] 22:50:03 INFO Rebuilding Build Queue. [01:02] 22:50:03 INFO creating lockfile 22:50:03 ERROR Cannot Acquire Lock. [01:02] [01:03] who else is holding that lock? [01:04] seems to be the slave scanner [01:04] which runs every, single, minute [01:04] no wonder the queue builder doesn't get a change [01:04] uh, chance [01:05] why should the slave scanner hold that lock? [01:05] no idea === bluekuja [n=andrea@ubuntu/member/bluekuja] has joined #launchpad === rpedro [n=rpedro@87-196-10-127.net.novis.pt] has joined #launchpad === rpedro_ [n=rpedro@87-196-76-213.net.novis.pt] has joined #launchpad [02:46] $ sudo apt-get install python-tk [02:46] Reading package lists... Done [02:46] Building dependency tree [02:46] Reading state information... Done [02:46] Some packages could not be installed. This may mean that you have [02:46] requested an impossible situation or if you are using the unstable [02:46] distribution that some required packages have not yet been created [02:46] or been moved out of Incoming. [02:46] Since you only requested a single operation it is extremely likely that [02:46] the package is simply not installable and a bug report against [02:46] that package should be filed. [02:46] The following information may help to resolve the situation: [02:46] The following packages have unmet dependencies: [02:46] python-tk: Depends: python2.4-tk (>= 2.4.3) [02:46] E: Broken packages [02:46] python-tk is now built from python-stdlib-extensions [02:47] resulting in a python-tk_2.4.3-1ubuntu2 package [02:48] although the package is built, it's not shown in the archive ... [02:48] Kamion, Kinnison, Keybuk: ^^^ [03:39] doko: what you say makes no sense, I'm afraid [03:39] the last upload of python-stdlib-extensions was 2.0ubuntu1 [03:40] by yourself, about 8 hours ago [03:40] not 2.4.3-1ubuntu2 [03:41] python-tk_2.4.3-1ubuntu2 comes from the python-defaults package [03:42] if you want the binary built by python-stdlib-extensions to replace that, it needs to at least have a higher version number ;) === mpt [n=mpt@203-173-177-223.bliink.ihug.co.nz] has joined #launchpad [04:00] Gooooooooooooooooooooooooood afternoon Launchpadders! === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad === stub [n=stub@ppp-58.8.2.243.revip2.asianet.co.th] has joined #launchpad === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad [06:28] Hmm, bzrlib failure when merging into sqlobject. [06:35] spiv: so we have a common way to get to the sync() or syncUpdate() methods of sqlobjects that are security wrapped? [06:42] Are you asking "do we" or "should we"? [06:43] Anyway, I think the answers are "no" and "yes", respectively ;) [06:43] flush_database_updates() makes me nervous, it's a big hammer and we overuse it. [06:44] 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] that should have been 'do we' [06:49] do you think an extra interface as a parent would be the way to do it? [06:50] there is sqlos.interfaces.ISQLObject, but it exposes a lot more than we'd usually want to [06:50] (destroySelf and set) [06:50] I think that would be the way, yeah. It's a large change, though. [06:50] I suppose sync() and syncUpdate() are always safe. [06:50] Which is why I'm ambivalent about it, I can't quite convince myself it's worth the benefit. [06:51] (although overusing them can be a perf issue) [06:51] They should be. [06:51] Right, but lots of things are perf issues when overused :) [06:51] And they're much less of a perf issue than flush_database_updates. [06:51] of course, they should be cheaper than flush_database_updates() ./.. [06:57] got any ideas about an interface name? [06:57] I'd say "ISQLObject" if we didn't already have one. [06:58] ISQLObjectSyncable? [06:58] in practice there is nothing wrong with duplicate interface names ... [07:00] It's potentially confusing, and annoying if we want to import both into the same module for some reason. [07:00] But maybe it's ok here. [07:00] would I have a rubberstamp for adding ISQLObjectSyncable? === kwwii [n=kwwii@likes.smoking.more.than.watching.spacenight.dk] has joined #launchpad [07:01] moin [07:01] I'm ok with that, but it's probably worth getting a 3rd opinion. A pity SteveA's at europython. [07:01] one small question: does the "fix committed" status mean that the bug should now be fixed? [07:02] kwwii: It generally means it's fixed in the development version, but not yet in the released version. [07:02] 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] spiv: cool, thanks :-) I won't waste anyones time in responding that the bug is still there [07:02] 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] jamesh: excellent, good thing I asked [07:03] Which usually happen weekly. [07:03] 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] cool [07:06] ok, back to work...thanks for the quick answer :-) === kwwii [n=kwwii@likes.smoking.more.than.watching.spacenight.dk] has left #launchpad [] === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [08:20] I've figured out some of the intermittent bzr failures. [08:21] It's running too fast ;) [08:21] I've posted an analysis to the lp list. [08:22] so it is throwing away the subsecond accuracy of the stat data? [08:23] jamesh: look at the _fingerprint function in bzrlib/hashcache.py [08:24] jamesh: The short answer is "yes" [08:24] spiv: yeah. I was looking at your email. [08:24] # we discard any high precision because it's not reliable; perhaps we [08:24] # could do better on some systems? [08:25] I wonder what systems subsecond accuracy is not reliable? [08:25] I mean, it might not be present on some systems, but I'd expect it to be reliable if present [08:26] (assuming you account for the errors introduced by python converting the times to floats [08:27] Yeah, that comment is a mystery to me. [08:27] e.g. using long(fs.st_mtime * 1000000) should be as reliable [08:28] bzr annotate blames r866, by mpool. [08:29] Which is very slightly less than a year old :) [08:39] the floating point comparison is the only issue I can think of, The Python stat values are created with the following: [08:39] fval = PyFloat_FromDouble(sec + 1e-9*nsec); [08:43] I don't seem to get any subsecond accuracy even after calling os.stat_float_times(True) [08:44] wonder if ext3 records it === mdke__ is now known as mdke === rpedro__ [n=rpedro@87-196-97-180.net.novis.pt] has joined #launchpad [08:48] 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] ext3 doesn't do nanosecond accuracy [08:49] however the page cache *does* [08:49] and you're almost never going to have a file flushed out of the cache within a second [08:50] spiv: so time.sleep() would probably fix it :) [08:53] or play around with the times with os.utime() [08:55] isn't bzr supposed to discard hashcache entries from the same second? [08:55] I don't know what it's supposed to do, but I can tell you what it does ;) [08:57] 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] 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] (in bzr's own test suite) [08:58] right [08:59] 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] I wonder if the problem has been addressed since we last updated bzr in our tree? [08:59] jamesh: nope [08:59] jamesh: well, the _fingerprint function at least hasn't changed. [09:00] jamesh: I guess there could be smarts like Keybuk just described elsewhere, but _fingerprint would be the sensible place to put it. [09:00] Keybuk: that sounds like a good idea, but I haven't seen any sign of it in my skimming of the source. === jd_ [n=jd@wikipedia/Meanos] has joined #launchpad === mpt [n=mpt@203-173-177-223.bliink.ihug.co.nz] has joined #launchpad === malcc [n=malcolm@host86-135-139-100.range86-135.btcentralplus.com] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === mpt WTFs at https://launchpad.net/binarypackagenames [09:29] oh, there's already a bug report about it [09:29] reported by me, even! [09:30] Forgetful minds think alike === sivan [n=sivan@85.65.210.12.dynamic.barak-online.net] has joined #launchpad === fabbione [i=fabbione@gordian.fabbione.net] has joined #launchpad === mpt_ [n=mpt@203-173-177-223.bliink.ihug.co.nz] has joined #launchpad === one [n=chatzill@125.35.1.15] has joined #launchpad [10:10] ? [10:16] ? === doko_ [n=doko@dslb-088-073-100-190.pools.arcor-ip.net] has joined #launchpad [10:32] Keybuk: no, python-tk isn't built from python-defaults [10:33] it was [10:33] https://launchpad.net/distros/ubuntu/+source/python-defaults/2.4.3-1ubuntu1 [10:34] 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] ^ clearly has python-tk and python-gdbm in it [10:34] why do you think python-stdlib-extensions is 2.4.3-1ubuntu2 ? [10:34] python-stdlib-extensions is 2-0ubuntu1 [10:34] 2-0ubuntu1 < 2.4.3-1ubuntu1 [10:35] so the binaries built by python-stdlib-extensions are older than what's there [10:35] so they won't show up [10:35] https://launchpad.net/distros/ubuntu/+source/python-stdlib-extensions/2-0ubuntu1 [10:35] Keybuk: no, look a the binary versions, not the source version [10:35] s/a/at/ [10:35] bet LP doesn't do binary versions [10:36] given that it's UI doesn't seem to expose them [10:36] http://librarian.launchpad.net/3271744/buildlog_ubuntu-edgy-i386.python-stdlib-extensions_2-0ubuntu1_FULLYBUILT.txt.gz [10:36] doko: note "changes file not available" [10:36] tbh, at this point you need a soyuz engineer [10:37] I expect you've found a katie/deb feature they didn't know about [10:37] ok [10:39] for reference, the queue entry was [10:39] 64293 | -B | python-stdlib-extens | 2-0ubuntu1 | 11 hours [10:39] | * python-gdbm/2.4.3-1ubuntu2/ia64 Component: main Section: python Priority: OPTIONAL [10:39] | * python-tk/2.4.3-1ubuntu2/ia64 Component: main Section: python Priority: OPTIONAL [10:40] 16:03:06 DEBUG Publishing source python-stdlib-extensions/2-0ubuntu1 to [10:40] +ubuntu/edgy === fabbione [n=fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #launchpad [10:42] 22:03:05 DEBUG Publishing build to ubuntu/edgy/ia64 [10:42] 22:03:05 DEBUG ... python-gdbm/2.4.3-1ubuntu2 (Arch Specific) [10:42] 22:03:05 DEBUG ... python-tk/2.4.3-1ubuntu2 (Arch Specific) [10:42] 22:09:47 DEBUG Added [10:42] +/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] 22:09:47 DEBUG Added [10:42] +/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] Hmm [10:44] it's on the archive on drescher [10:45] but only the ia64 deb [10:45] looks like the others got lost [10:45] malcc: some debugging for you there [10:45] Keybuk: Ta [10:46] malcc: interesting that the build record doesn't have the changes file === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad [10:52] malcc: submitted bug 52064 [10:52] Malone bug 52064 in launchpad "soyuz confused by version numbers different in source/binaries" [Untriaged,Unconfirmed] http://launchpad.net/bugs/52064 [10:53] doko_: Thanks === frodon_ido [n=patrick@ip-213-49-210-27.dsl.scarlet.be] has joined #launchpad [10:59] note that it's not necessarily that which has happened [10:59] it could be the fact there's no changes file from the buildd === ploum [n=Ploum@ubuntu/member/ploum] has joined #launchpad === mpt__ [n=mpt@203-173-177-223.bliink.ihug.co.nz] has joined #launchpad [11:20] 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] 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] bother [11:28] malcc, make check_merge keeps hanging for me in either pagetests/soyuz/23-sourcepackage-hctstatus.txt or 25-binarypackagenames.txt [11:28] Are you familiar enough with the tests yet to have any idea why? :-) [11:28] mpt: Bummer. I don't think those do anything odd, but I'll take a look. [11:29] actually, it'll be 25-binarypackagenames.txt [11:29] the output is " /home/mpt/hackiTests hung - no output for 600 seconds. Killing ... Not dead yet! - slaughtering mercilessly" [11:30] where "/home/mpt/hacki" is the beginning of the path of 25-bpn [11:30] 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] malcc: deadlocks [11:31] mpt: I suggest you've got a ghost in the machine in fact unrelated to these thoroughly unremarkable tests [11:31] malcc: specifically, stderr is probably full [11:31] malcc: no ghosts [11:31] It's the third time exactly that test has failed [11:32] The first thing the test does is ask for http://localhost/binarypackagenames, and the URL gives me a 404 [11:32] malcc: we have a wrapper around the tests, it reads the stderr/stdout and shows them [11:32] though launchpad.dev/binarypackagenames works [11:32] 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] or something like that [11:33] mpt: I'm pretty sure localhost is ok in pagetests, even though it doesn't work in development [11:33] ok [11:34] 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] 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] Running the soyuz story by itself works [11:41] 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 === Atomyc [n=user@219.95.189.211] has joined #launchpad [11:42] hello.. [11:42] anybody here.. === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad [12:17] lifeless: To my limited knowledge, test_on_merge looks ok. It uses popen with stderr=STDOUT then uses a select loop. [12:17] On stdout [12:26] 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] malcc: ok. [12:33] 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] goody === sivan is now known as sivang === BjornT [n=bjorn@ctv-213-164-112-134.vinita.lt] has joined #launchpad [12:51] BjornT! [12:51] I have a problem with getLink [12:57] mpt: I expanded the PythonBugTrackerCompetition page earlier this week. Haven't looked at updating the wiki syntax spec implementation section. [12:58] BjornT, the problem is a bit complicated for IRC, I've replied to you on launchpad-reviews [01:00] jamesh, ok === BjornT_ [n=bjorn@ctv-213-164-112-134.vinita.lt] has joined #launchpad [01:04] 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] malcc: cool [01:04] general bug/feature request -- the UI could do with showing binary version numbers :p [01:04] malcc: thanks [01:05] Keybuk: Which pages are missing binary version numbers where they'd be useful to you? [01:06] malcc: well, the fact there's no publishing history pages for binaries [01:06] anywhere [01:08] Keybuk: Really? I assumed I just hadn't found them yet [01:08] there could be some secret unlinked page somewhere [01:08] but not one I'm aware of [01:09] 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] Everyone loves the source dude [01:12] Erm /distros/ubuntu/edgy/i386/python-support [01:13] witness the binary pub hist [01:13] Yay === BjornT [n=bjorn@213.226.190.253] has joined #launchpad [01:14] My faith that Soyuz can infact give you anything you want if you can only penetrate the Barrier of Confusion (tm) has been restored === mpt would dearly love to watch over the shoulder of some people using Soyuz [01:16] I understand how people use Malone [01:16] and I understand how people use Rosetta [01:16] I don't understand how people use Soyuz. === lfittl [n=lfittl@83-65-242-161.dynamic.xdsl-line.inode.at] has joined #launchpad === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:27] mpt: don't watch me then, 'cos I type URLs [01:30] Kinnison, I suspect most people do that for Malone too :-) [01:30] (I certainly do) [01:30] or bookmarks === Kinnison has quick-access keyword bookmarks for malone, aye === sivang [n=sivan@ubuntu/member/sivang] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [01:51] bug 12345 [01:51] Malone bug 12345 in isdnutils "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] http://launchpad.net/bugs/12345 [01:52] This has been a test of the Ubugtu system === stub [n=stub@ppp-58.8.2.243.revip2.asianet.co.th] has joined #launchpad [01:54] hello hello [01:54] publisher crash: http://librarian.launchpad.net/3282274/petQjyUqbU2w58HGOQLKrOCh3PF.txt [01:54] are people ready for the most important moment of the week! [01:54] stub : Ping? [01:55] 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] Znarl: pong [01:55] kiko: It's time already for the sunday morning Hollyoaks omnibus edition? [01:55] stub : chinstrap is getting slow rsyncing launchpad production logs again. Can you rotate them? [01:55] which is frankly just bizarre, given that it's trying to publish that [01:55] malcc, not that moment -- the other one! [01:55] Znarl: ok. [01:55] Thanks. [01:56] hello [01:56] SteveA! [01:56] are you going to be presiding this week after all? [01:56] hi kiko [01:56] i haven't prepared, but I'll be here [01:56] is that a yes or a no? :) [01:56] stub, did something go wrong with yesterday's nightly.sh run? === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad [01:56] https://launchpad.canonical.com/MeetingAgenda [01:57] I'm going to hope that the publisher runs successfully next time round [01:57] 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] SteveA? [01:58] kiko: i'll do it [01:58] stub, I asked because the mirror prober reported that no mirrors were probed [01:58] yayzers [01:58] salgado: That wasn't me === sivang [n=sivan@ubuntu/member/sivang] has joined #launchpad [01:59] I've never seen it actually probe a mirror === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad [02:00] I have [02:00] it's been probing lots of them, since almost two weeks [02:00] meeeeee [02:00] me [02:00] me [02:00] Hello [02:00] launchpad meeting [02:00] who is here? [02:00] MEETING TIME [02:00] me [02:00] me [02:00] o/~ Is it me you're looking for? o/~ [02:00] me [02:00] that's what I was trying to say [02:00] me [02:00] me [02:00] me [02:00] me [02:00] me [02:00] me [02:01] me [02:01] me [02:01] me [02:01] cool [02:01] == Agenda == [02:01] * 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] ---- * (other items) [02:01] argh [02:01] ---- * Keep, Bag, Change * Three sentences [02:01] irssi sucks for this [02:02] but irc is banned at cern === mpt thinks that's an improvement [02:02] so i must go vi ssh [02:02] ssh port forwarding [02:02] is the future [02:03] ok [02:03] next meeting... same time next week? [02:03] whatever [02:03] yes. [02:03] cool. someone please set the channel title appropriately. === ..[topic/#launchpad:mpt] : https://launchpad.net/ | developer meeting: Thu 13 July, 1200UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Channel logs: http://tinyurl.com/72w39 [02:03] ta [02:03] * Activity reports [02:03] i suck. anyway, i've been at europython. [02:04] I'm up to date === flacoste is up to date [02:04] I'm half-sucky [02:04] 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] Up to date [02:04] I'm up to date [02:04] @europython [02:04] paper? [02:04] I'm not up to date [02:04] up to date, less sprints [02:04] up to date [02:04] I was sprinting last week and this week has been context-switch festival [02:04] stub: It's old-school technology [02:04] Up to date [02:04] one day behind (and I've been batching) [02:04] I'm also guilty of batching [02:04] * Actions from last meeting [02:05] here [02:05] * Steve to ask Kiko to run next week's meeting [02:05] ah, well, anyway [02:05] * everyone (including those not at the meeting): read https://wiki.canonical.com/SysAdminRtUsageGuide and subscribe to it [02:05] And I'm behind on activity reports. :( [02:05] please say "read" or "not read" according to whether you have read that page yet. [02:05] read [02:05] read [02:05] read [02:05] read [02:06] I read it and used the advice in there === flacoste read and subscribed [02:06] read and subscribed [02:06] read [02:06] read [02:06] read [02:06] most excellent [02:06] read [02:06] read [02:06] read [02:06] most of us are also subscribed [02:06] read [02:07] * Oops report (Matsubara) [02:07] Today's oops report is about bugs 44860, 42755, 2497, 51097 and 30602 [02:07] 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] Malone bug 2497 in rosetta "/people/*/+translations times out for prolific translators" [Medium,Confirmed] http://launchpad.net/bugs/2497 [02:07] Malone bug 51097 in rosetta "Selection of untranslated entries is too slow" [High,Confirmed] http://launchpad.net/bugs/51097 [02:07] 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] Kiko any news about bug 42755. Is that fix going to address comments on tickets also? [02:08] hmm carlos isn't here... [02:08] stub, would you have time to work on bug 2497? I have a simple-ish plan for it [02:08] Malone bug 2497 in rosetta "/people/*/+translations times out for prolific translators" [Medium,Confirmed] http://launchpad.net/bugs/2497 [02:08] bug 42755 you say? [02:08] kiko: Mark is pushing me to work on CanonicalPillarNames === lincao [n=lincoln@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:08] yeah, that's true. [02:08] stub, let's do that call after the meeting [02:09] k [02:09] Top time outs are on +translate(51097 and 30602) and +translations(2497) page. [02:09] The only one not assigned is 30602, want to take that kiko? [02:09] matsubara, that's better a carlos bug really [02:09] I'll talk to him then [02:09] and lastly, pqm is rejecting my commit attempts. [02:09] Me Too [02:09] is there anyone looking on that problem? [02:10] matsubara: Did you see my email to the list? [02:10] can you be more specific ? [02:10] matsubara: I suggest just keep trying, the bzr failures are intermittent due to a race condition. [02:10] lifeless: random test failures. I mailed the list with the failures I got [02:10] matsubara: I had the same failure as you, got through the second time though. [02:10] spiv: I've seen it, thanks for looking on it. [02:11] I tried 5 times yesterday, I'll keep on trying then. [02:11] Wellk, the same as three of yours, haven't looked at all of yours though :) [02:11] lifeless, can you please disable that test for now? [02:11] kiko: It's more than one tests. [02:11] oh [02:11] one test, rather. [02:11] really? [02:11] anyone in the lp team can commit to the p copy of bzr [02:11] s/p / lp / [02:11] 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] I am about to fly home, so no, I cannot do that. [02:12] lifeless, sure, but that's a judgement call that i'd rather you made [02:12] it sounds like there is a real, valid bug in bzr though. [02:12] or authorize somebody to do it [02:12] because the hashcache is meant to be race condition free. [02:12] lifeless, great. let's not let it stop launchpad development from happening though :) === stub [n=stub@ppp-58.8.2.243.revip2.asianet.co.th] has left #launchpad [] [02:12] I can call Martin tomorrow to discuss the problem if people want? [02:12] 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] kiko: ^ === stub [n=stub@ppp-58.8.2.243.revip2.asianet.co.th] has joined #launchpad [02:12] lifeless, any commit? including not running bzr tests upon commit? :-) [02:12] And then do a commit to our bzr based on that conversatino. [02:12] spiv: please do that, I was about to suggest asking Martin to treat it as urgent. [02:13] kiko: if that is what it takes for a short period of time, then [grudgingly] yes. [02:13] I've also been seeing intermittent failures with cscvs. [02:13] Ok, I'll do that. In the in ~12 hours until then, just keep retrying :) [02:13] cool. [02:13] thanks [02:13] kiko: however, I suggest talking with the sysadmins tonight [02:13] stub: Oh, that's one I'm not aware of. [02:13] because this started happening [02:13] It may have been triggered by upgradinig Balleny to dapper. [02:13] and nothing was changed in our copy of bzr or bzrtools when it started. [02:13] stub: one of my test failures was related to that [02:14] stub: I've never seen these failures on dapper on other machines. [02:14] its even possible, that its a dapper bug [02:14]