=== mpt [n=mpt@203-167-187-121.dsl.clear.net.nz] has joined #launchpad === Keybuk [n=scott@syndicate.netsplit.com] has joined #launchpad [12:35] nevermind, fixed === jenda [n=jenda@ubuntu/member/jenda] has left #launchpad ["Find] [12:53] (From the "meanwhile in other bugtrackers" department: RESOLVED LATER and RESOLVED REMIND have just been removed from Bugzilla CVS.) [12:55] New bug: #58776 in malone "clicking on 'file a bug against foo' link leads to 'foo does not exist in Dapper' error message" [Untriaged,Unconfirmed] http://launchpad.net/bugs/58776 [01:01] Goooooooooooooooood morning Launchpadders! === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #launchpad === somerville32 is back. [01:47] mpt: It's starting to feel like Ground Hog Day now you're doing that daily ;-) [01:49] gooooood night! ;) [01:56] ~ They say that love won't pay the rent ~ Before it's earned, our money's always spent ... ~ [02:00] New bug: #58784 in blueprint "Spec page refers to non-existent "Specifications in grey"" [Untriaged,Unconfirmed] http://launchpad.net/bugs/58784 === mholthaus_ [n=mholthau@johnny33.dersbach.ch] has joined #launchpad [03:26] mpt: have you seen this spec? https://features.launchpad.net/distros/ubuntu/+spec/internet-sharing [03:33] jamesh, no I hadn't. That looks pretty ... interesting. [03:33] mpt: I wonder if the person thought "this isn't a bug, but rather a feature request ..." [03:34] I wasn't the one who thought the spec tracker should be a separate application :-P [03:35] New bug: #58791 in malone "+subscribe page contains non-useful radiobutton" [Untriaged,Unconfirmed] http://launchpad.net/bugs/58791 [03:38] jamesh, see also https://launchpad.canonical.com/MaloneAndBlueprintIntegration === Cogito_ergo_sum [n=c27@201.210.108.110] has joined #launchpad [03:40] hi good night === Cogito_ergo_sum ha vuelto ( Ausente 51 mins 5 secs ) [03:45] ... and good luck === Fujitsu_ [n=Fujitsu@203.23.49.35] has joined #launchpad === mpt [n=mpt@203-167-187-121.dsl.clear.net.nz] has joined #launchpad [05:05] jamesh: ping [05:05] mpt: pong [05:07] jamesh: https://devpad.canonical.com/~andrew/paste/fileRYXA42.html [05:07] Any idea what's going on here? [05:08] mpt: you are using the most recent pqm-submit plugin? [05:10] revno 22 [05:10] parent branch: http://bazaar.launchpad.net/~bzr-pqm-devel/bzr-pqm/bzr-0.8/ [05:11] hmm, is that bad when trying to use it with bzr 1.0ish? [05:11] yes [05:11] try this: [05:11] cd ~/.bazaar/plugins/pqm-submit [05:11] bzr pull --overwrite http://bazaar.launchpad.net/~bzr-pqm-devel/bzr-pqm/devel [05:12] to get the updated version [05:12] (this version also has smtp auth support, btw) [05:12] great! [05:12] you can set smtp_username and smtp_password in ~/.bazaar/bazaar.conf and it'll do the right thing [05:12] aha, I have a conflict from my manual ayuth change [05:13] bzr revert then. [05:13] yeah [05:14] ok, now bzr pull --overwrite http://bazaar.launchpad.net/~bzr-pqm-devel/bzr-pqm/devel says "0 revision(s) pulled" [05:14] there are 22 revisions on both the bzr-0.8 and devel branches [05:15] but bzr info is still pointing at the wrong parent branch [05:15] so the difference in length of revision history is 0 [05:15] ah. [05:15] "bzr pull --remember http://..." should fix that [05:16] 0 revision(s) pulled... [05:17] but now it has the correct parent [05:17] configure your SMTP username/password in ~/.bazaar/bazaar.conf and retry the pqm-submit command [05:18] bzr: ERROR: No PQM submission address specified in configuration [05:18] argh. That's the shadowing problem again ;( [05:18] the what? :-) [05:20] one section of ~/.bazaar/locations.conf shadowing settings from another section [05:22] The second line of locations.conf is "pqm_email = Canonical PQM " [05:22] There are no other pqm_email lines [05:23] just various branches with push_location lines, and one branch with both a push_location and a pqm_branch [05:26] pqm-submit doesn't seem to let me specify the address explicitly === stub [n=stub@ppp-58.8.10.39.revip2.asianet.co.th] has joined #launchpad [05:29] Removing the section for this branch from locations.conf seems to work (though it's going so slowly, it hasn't gotten up to asking for my password yet) [05:30] ok, it didn't work after all. It tried to mail mpt@canonical.com instead of mailing pqm@pqm.ubuntu.com [05:31] (Host or domain name not found. Name service error for name=canonical.com type=MX: Host not found, try again) [05:39] hurrah, copying all the config stuff from the global section to that branch's section worked === mpt [n=mpt@203-167-187-121.dsl.clear.net.nz] has joined #launchpad [06:40] morning === MaSa69 [n=MaSa69@dsl-jklbrasgw1-fe1cfb00-100.dhcp.inet.fi] has joined #launchpad [07:08] stub: ping? [07:12] jamesh: pong [07:13] stub: last week I put together a script to clean up the [https://launchpad.net/malone/bugtrackers/ubuntu-bugzilla/NNNN] text that was inserted into the comments of bugs imported from bugzilla.ubuntu.com [07:13] stub: I was wondering if you could look over it and maybe run it in production this week if it looks okay [07:14] I did a test run on demo.launchpad.net which seemed to go okay [07:14] ok. Still going through my email from last week so haven't got to that one yet. [07:15] New bug: #58806 in blueprint "Specification page contains unexplained "(n days)" text" [Untriaged,Unconfirmed] http://launchpad.net/bugs/58806 [07:16] stub: the code is here: https://devpad.canonical.com/~jamesh/fixup-bug-references -- it needs to be run as a user that can update the MessageChunk table [07:17] jamesh: Please email me the details if you haven't already so I don't forget by the time I've cleaned out my pile [07:19] stub: done. the thread is "Rewriting bug numbers and dupe comments" [07:19] k [07:20] (302 in inbox to go, then the mailing lists :-( ) [07:21] stub: second thing: would it be possible to get another product-release-finder run done on staging? I believe the problem we ran into last time has been fixed. [07:21] Last I left it it was scheduled to run daily [07:22] hmm [07:23] stub: the product-release-finder code keeps a cache of URLs that it has previously processed in /var/tmp/productreleasefinder, which is probably why it didn't look like it was doing anything [07:24] stub: would it be possible to blow that cache away so we can see how it runs now? [07:24] jamesh: It died last night with an ftp error === stub checks for ftp_proxy [07:25] I've got a branch in the review queue to get rid of the cache code, but for now it would prevent the releases from being created after a DB refresh [07:25] jamesh: https://devpad.canonical.com/~andrew/paste/fileRtP8Iz.html [07:26] Yer - only turned on ftp_proxy on production [07:26] stub: that indicates that ftp_proxy wasn' [07:26] t set [07:27] stub: morning [07:28] stub: in the launchpad meeting, in the "production and staging" section, people listed things they particularly want to get into production this week [07:29] jamesh: it is rerunning now anyway [07:29] stub: with the cache blown away? [07:29] jamesh: yes [07:29] thanks === cbx33 [n=pete@ubuntu/member/cbx33] has joined #launchpad [07:31] Is it possible to send a mail to everyone in a LP group? [07:31] jamesh: I suspect we should be storing this cache in the Librarian, as we don't really want to download a few gb of data every time the server is rebooted, or /var/tmp otherwise cleaned. [07:32] stub: I'm getting rid of the cache completely [07:32] excellent [07:32] stub: the database contains all the state needed to handle repeated runs, so the cache just adds a point of failure [07:32] stub: are you planning to do a rollout this week? if so, please mail the launchpad list to say what will happen. [07:32] SteveA: I have no idea yet. I'm still going through my backlog, and probably will be for few hours [07:32] stub: okay [07:33] mpt: have you looked at the meeting summary for thursday yet? [07:33] it'd be nice to get a rollout done this week -- there's been lots of fixes since the last one [07:38] stub: welcome back === stub would rather be diving [07:38] :-) === Keybuk [n=scott@syndicate.netsplit.com] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === Fujitsu [n=Fujitsu@c58-107-62-26.eburwd7.vic.optusnet.com.au] has joined #launchpad [08:14] Lunch === cbx333 [n=pete@84-45-238-195.no-dns-yet.enta.net] has joined #launchpad [09:06] jamesh: hi, around? [09:06] SteveA: yeah [09:06] jamesh: got a few minutes for a chat with me and mpool about some bzr infrastructure work? [09:06] SteveA: sure. === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [09:32] SteveA, looked at it? I wrote it. Or are you referring to a different meeting? [09:32] mpt: if you wrote it, that's great. I want to point stub at the production/staging section, so that he can know what was discussed, and what code people want to get landed [09:33] ah, but I forgot to update MeetingAgenda [09:33] I'll do that now [09:34] thanks [09:34] and please mail stub too [09:36] ok [09:38] done [09:39] and done === stub [n=stub@ppp-58.8.10.39.revip2.asianet.co.th] has joined #launchpad === Znarl [n=karl@bb-82-108-14-161.ukonline.co.uk] has joined #launchpad === malcc [n=malcolm@host86-138-251-144.range86-138.btcentralplus.com] has joined #launchpad [09:51] stub: how's the product-release-finder run going? [09:52] Hmm.... go boom [09:52] :( === lifeless wants that running badly [09:53] https://devpad.canonical.com/~andrew/paste/file35Ccxs.html === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad [09:54] blech [09:54] encoding === stub has no idea how beutiful soup handles encoding [09:54] and on a 503 error ? wtf === lifeless isn't sure how to parse that output totally [09:55] there seem to be two errors mentions === carlos [n=carlos@203.Red-81-35-100.dynamicIP.rima-tde.net] has joined #launchpad [09:56] SteveA: can we get a user to change his wiki name if it is possibly misleading? (ubuntupr) [09:56] morning [09:58] lifeless: the 503 error is probably an earlier request. [09:58] I agree with James [09:58] hi carlos [09:59] kk [09:59] There are other 503's earlier in the output handled just fine (although we really shouldn't be logging them as tracebacks since they are expected) [09:59] the walker class should be generating log messages [09:59] I wonder why it isn't. [09:59] DEBUG level? I didn't run it with -v [10:00] it should be generating info level messages [10:00] looks like it isn't passing the log object down that far. [10:02] There is a global that can be used (although it was naughty to do it that way) [10:02] (Made unit tests a pita) [10:02] I'll look at getting the walker logging working [10:03] and I suppose we should handle BeautifulSoup parse failures better too [10:03] I thought BeautifulSoup was supposed to handle badly formatted soup [10:04] I wonder if we can get at the squid logs to get an idea of what it accessed last? [10:05] Looks like encoded strings are leaking into it rather than Unicode (or whatever encoding BS is expecting?) [10:05] given that the log doesn't include that info [10:06] oh now thats a cute idea [10:06] #canonical-sysadmin might be able to help here [10:06] c/here/there/ [10:06] create a function dynamically called the name of the thing it is about to try [10:06] then you dont need log barf to read the traceback usefully ;) [10:07] more sensibly, how about a top level catch-all try:except: print; raise [10:07] around or in handleProduct [10:07] lifeless: the traceback formatter from zope takes a different approach: if any frame has a local called __traceback_info__, it is pretty printed along wiht the frame in the traceback [10:07] jamesh: thats nice [10:08] back in 1 hr [10:08] stub: what machine was the script running on? [10:08] gangotri [10:16] mpt: Your bug queries on the mailing list (in the preventing duplicates thread) - do you want results for open bugs or all bugs? [10:17] Actually, needs to be all bugs or else the later ones regarding duplicates won't make sense (since duplicate bugs are never closed atm) === Spads [n=crack@217.205.109.249] has joined #launchpad === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [10:28] hi ddaa [10:28] do we have a meeting today? [10:28] hi SteveA [10:28] Meeting in 92 mins [10:28] thanks [10:29] SteveA: got a very detailed agenda on BazaarMeetingAgenda if you care to look [10:29] yes [10:29] i do [10:29] Burgundavia: hi [10:30] SteveA: did you see my comment? [10:30] Burgundavia: I'm sure we *can* change someone's wiki name. I think it would be better to ask them to change it themselves first. [10:31] there's also the issue of who says we *ought* to change it. the ubuntu wiki is governed by the CoC and the CC, I think [10:31] so, while I have technical power, I don't have the "right" to do anything so long as it isn't causing a technical problem. [10:32] is there someone beneath the CC who is responsible for encouraging good conduct on the wikis? [10:34] ddaa: where can I read the agenda? [10:34] stub: ever looked at xapian? I was talking with alan runyan about it at the weekend. [10:35] https://launchpad.canonical.com/BazaarMeetingAgenda [10:35] SteveA: Nope. I don't even know what it is [10:35] "Meeting plan" section is the outline for the meeting [10:35] that is all the bit I plan to copy-paste [10:35] stub: some kind of hot shit free software text searching system. [10:35] http://www.xapian.org/ [10:36] and I will use that as template for the summary, I'll try to keep doing it that way in the future, as that will force me to keep the agenda up to date [10:36] stub: alan does various work with the developers, so if this is at all interesting for us, we can talk with people. [10:36] ddaa: reading [10:37] stub: alan says the tech is great. the bindings are gross. [10:37] SteveA: apparently, it is nobody that is listed as his real name in LP [10:37] stub: welcome back [10:38] Burgundavia: what's the launchpad page for this person? [10:39] SteveA: I cannot find it, because none of the LP pages for Carlos Rivera has a wikiname of UbuntuPR [10:39] stub: is rollout planned for today? [10:39] and there are 6 hits for Carlos Rivera === ddaa curses freenode === mdke [n=matt@ubuntu/member/mdke] has joined #launchpad [10:43] Burgundavia: I see no wikiname of UbuntuPR in the database. [10:44] https://wiki.ubuntu.com/UbuntuPR [10:45] there are lots of names containing the text "ubuntu" [10:45] indeed === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [10:46] Burgundavia: https://launchpad.net/people/crrivera [10:46] aha [10:47] hmm, I will email him [10:47] thanks for the find [10:47] I wish launchpad.net/foo would do a search for foo [10:47] much like packages.d.o or .u.c does [10:47] on the staging database, his wiki name is Crrivera [10:47] so, this must be a recent change === Znarl [n=karl@bb-82-108-14-161.ukonline.co.uk] has joined #launchpad === stub [n=stub@ppp-58.8.10.39.revip2.asianet.co.th] has joined #launchpad === boim_ [n=aaron@boim.com] has joined #launchpad [10:48] the page for his name just go created [10:49] there is a search form on launchpad.net/people/ [10:49] it doesn't search wikinames right now [10:49] it could do though. file a bug if you want such a feature. === Znarl [n=karl@bb-82-108-14-161.ukonline.co.uk] has joined #launchpad === stub [n=stub@ppp-58.8.10.39.revip2.asianet.co.th] has joined #launchpad === boim [n=aaron@boim.com] has joined #launchpad [10:52] SteveA: I think I remember this now - Richard Jones was using it with Roundup and he seemed to like it. [10:52] SteveA: Not yet suitable for us though as we need to glue it into PostgreSQL [10:54] SteveA: Seems to offer the same feature set as tsearch2, with the addition of wildcard searches. No idea if they use some magic index for fast wildcard searching or if it would be with similar restrictions to PostgreSQL LIKE [10:56] stub: is rollout planned for today? [10:56] ddaa: No. And I'm not sure about tomorrow yet (still clearing intrays) [11:12] morning [11:26] stub/lifeless: I've got the problem page that tripped up product-release-finder will see if I can reproduce it [11:42] whaaaa! gimme my crack of the week! gimme! gimme! [11:43] I blame Norman Walsh [11:43] jamesh: how snob, why don't you blame Daniel Bernstein like everybody else? [11:44] ddaa: the page was http://www.docbook.org/xml/ [11:44] (although the real problem was BeautifulSoup not handling the UTF-8 on that page) [11:45] New bug: #58835 in soyuz "Debian Installer garbage collection not working?" [High,Confirmed] http://launchpad.net/bugs/58835 [11:46] hmm looks like the problem is the way PRF is using BeautifulSoup [11:47] PRF, you mean URTF? [11:47] unless you mean Dyson maybe? [11:47] product-release-finder [11:48] thanks for demonstrating that anything longer than two words ends up as an obscure acronym :) [11:49] Indeed. Dyson is much easier to remember, and its name need not change as the scope of its tasks changes over time ;) [11:52] jamesh: hi, how's going my code review? I would like to get it cherrypicked this week so we approve a bunch of entries automatically as soon as possible... [11:57] carlos: not yet done. I'll make sure it is done by tomorrow [11:57] jamesh: thank you [11:57] did you started it? [11:58] I have a small trivial change related to automatic approvals and if you didn't start I would prefer to add it there instead of using [trivial] [11:58] it doesn't affect directly to the changes already done ther [11:58] there [11:58] lifeless: -> #launcphad-meeting [11:58] carlos: just add it to the branch. I haven't done that much on the branch yet. [11:58] ok [11:59] jamesh: thanks [12:07] What does PAS stand for again? [12:08] piece a shit === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad [12:08] That makes sense in this context, but I don't think it is correct [12:09] Packages arch-specific [12:09] ta === jinty [n=jinty@132.Red-83-55-196.dynamicIP.rima-tde.net] has joined #launchpad [12:38] review meeting in 22 [12:45] review meeting in 15 [12:53] it's so nice our RCS isnt' called "arch" anymore, as "PAS" would be doubly confusing [12:55] review meeting in 5 [01:01] hmm... massive rain shower [01:01] review meeting time [01:01] whos here ? [01:01] hello. iamhere [01:02] me [01:02] me [01:02] hi guys [01:02] next meeting time - sept 11 [01:03] this time [01:03] +1 [01:03] ok [01:04] * queue size [01:04] * other items [01:04] queue has 5 items in it - oldest is salgado & 9 days [01:04] all the rest are 3 or less, which is inside our service level [01:05] BjornT: can you nag salgado, 9 days for a 77 line review is - excessive - and your time zones should cross [01:05] lifeless: yeah, i'll send an email to him, reminding him that he should check his queue daily [01:06] BjornT: hmm, was hoping more personal ;) [01:06] BjornT: I'll send such a mail after this meeting [01:06] if you see him on IRC though, please nag in person [01:06] ok [01:07] andrew put up a proposal [01:07] * what to do about merges that aren't properly reviewed? (AndrewBennetts) [01:07] Seeing as I'm on leave this week, here's my thoughts for discussion, ready for pasting into the channel: {{{ [01:07] Some recent merges concerned me a little: [01:07] r3995 was merged without review by the review team [r=cprov,malcc] [01:07] r4001 was merged with [rs=elmo] (and built on the changes in r3995). [01:07] I did an unsolicited post-merge review of 4001 (and some of 3995), and found a bunch of issues. Nothing terrible, but certainly the quality was less than I'd approve as-is. I'd rate it about merge-conditional. [01:07] I propose that someone (Robert?) checks the commit list daily, and assigns "trivial", rubber-stamped, and other anomalous merges to reviewers for post-merge review, much like the pre-merge review queue. It's easy to run "bzr diff -r 1000..1001 | less", so we wouldn't need to pre-generate diffs. [01:07] In theory, these should be rare enough and/or small enough that it shouldn't add much to the review load, but it might help keep quality from slipping. [01:07] What do people think? [01:07] }}} [01:08] Sounds like a good idea (and something we've discussed in the past) [01:08] i'm in favour of it. i'd also like to see some progress on getting diffstats and links in the mails from pqm [01:08] and i'm glad spiv has been doing such reviews [01:09] I think its a good idea [01:09] sounds good to me as well. [01:09] I'm not sure how much overhead it will take [01:09] malcc: would you comment on this? was there a particular reason that r3995 was not reviewed by the review team? [01:09] both on reviewers for the additional reviews, and for the assigner to ensure they catch everything [01:09] does the fact that people are putting these large changes through as trivial (or not reviewed by a review team member) indicate problems with our process? [01:10] SteveA: kiko asked me and Celso for our thoughts on the patch, which we provided, then he went ahead and merged with that r= === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad [01:10] hi cprov [01:10] SteveA: hi [01:10] SteveA: I wasn't sure exactly what the procedure was, so I didn't know if I should be objecting or not [01:10] New bug: #58842 in soyuz "sync-source doesn't understand pockets (eg. -proposed)" [Untriaged,Unconfirmed] http://launchpad.net/bugs/58842 [01:10] malcc: you should start with PreMergeReviews and read from there [01:10] so, the code was by kiko, with some review from malcc and cprov? [01:11] malcc: the whole process is documented :) [01:11] lifeless: Thanks [01:11] SteveA: Yes [01:11] was there a reason that this code needed to land in a hurry? [01:11] like, urgent fixes to get cherrypicked? [01:12] seems a bit weird given we didn't have a rollout scheduled last wek [01:12] week [01:12] SteveA: No. In fact the landings during the sprint have led to a situation where rocketfuel is effectively undeployable for Soyuz on drescher at the moment, until we finish the testing we've started since the sprint [01:12] SteveA: As far as I could tell, kiko was just in a hurry and being kiko [01:12] you mean, you're running non RF stuff in production? [01:12] heres what I propose - we try spics suggestion for 1 week. At the end of it, we gather reviewers feelings on those reviews, and mine on the overhead of generating the reviews to do [01:13] *spivs* [01:13] SteveA: We're running an older rocketfuel in production, with some (also rocketfuel) cherrypicks [01:13] theres some statistical principle that suggests the unreviewed merges spiv looked like are more likely to be typical than atypical [01:14] I see. so, careful soyuz updates until you finish the testing and associated code. [01:14] SteveA: soyuz gets special treatment on rollouts [01:14] I think in this case, kiko considered himself the representation from the review team on that branch [01:15] but, I think seeing as kiko also wrote the code, that that's not sufficient oversight to get consistent quality in the code [01:15] SteveA: as he wrote the patch, our current protocol excludes him from that role [01:15] but, let's ask kiko about it later [01:15] and the results that spiv found correlate to the oversight thing you are saying there [01:15] anyhow, I dont think that this one patch is exceptional [01:16] which is my point - understanding this one matters, but trialling post-merge-reviews of trivial and rs merges is worth doing [01:16] +1 to your proposal of trying spiv's proposal for 1 week [01:16] *regardless* of the genesis of the soyuz patch [01:17] jamesh: I dont know if our process has problems [01:17] jamesh: but I think anything other than mandatory reviews will get occasional abuses [01:17] Incidentally, would someone be kind enough to tell me off for allowing my name in r= when I'm not a reviewer? This way, if I'm asked to do this again, I'll be being honest when I say I got slapped for it last time :) [01:17] lifeless: +1 to trying spiv's suggestion [01:17] malcc: there are situations where a domain expert will review, and that can be noted. [01:17] malcc: I dont think you need telling off [01:18] lifeless: occasionally the queue gets overloaded leading to longer review times, which'd encourage some people to try and bypass it [01:18] the point is, there was no member of the code review team in there [01:18] malcc: you *did* a review. [01:18] malcc: but what we would have wanted there was [r=spiv, r=malcc, vc=bjorn] ... [01:18] or some such [01:18] vc? [01:18] voice call, cant remember the abbreviation [01:19] very cool? [01:19] p= [01:19] p= [01:19] sucks to be me eh? [01:19] * other business [01:20] spiv has a few very old branches in merge-conditional. I guess that's not really a review team problem though [01:21] its worth us putting some pressure on folk, but no, its definately those peoples problem, according to the process documentation [01:21] 'you are responsible for getting your branch through the review process' [01:22] we seem to be idling, so [01:22] * other business ? [01:22] nothing from me [01:22] no [01:22] no [01:22] meeting over, kthx === SteveA --> lunch [01:33] any idea someone how I can reach Kinnison ? === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [01:34] if anybody has his phone number, could you please PM me? === Teal-CRMGuest [n=Teal-CRM@213-154-232-21.adsl.bit.nl] has joined #launchpad === Teal-CRMGuest [n=Teal-CRM@213-154-232-21.adsl.bit.nl] has left #launchpad [] === mpt [n=mpt@203-167-187-121.dsl.clear.net.nz] has joined #launchpad [01:45] New bug: #58847 in launchpad "product-release-finder HTTPWalker " [Untriaged,Confirmed] http://launchpad.net/bugs/58847 === malcc -> Lunch === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:48] malcc: Should I update drescher's code during tomorrows roll out? Or leave it with you and cprov? [02:48] stub: we will need to do it later === niemeyer [n=niemeyer@201.14.22.144] has joined #launchpad [02:49] ok. I'll leave it with you too [02:49] (bit early for you cprov, isn't it?) [02:49] stub: nop, almost 10 AM here [02:49] Bit late for me then ;) [02:50] stub: I guess so ;) === carlos -> lunch [03:03] see you! === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad [03:31] New bug: #58766 in ubiquity "Ubuntu Installer Crash" [Untriaged,Unconfirmed] http://launchpad.net/bugs/58766 === lfittl [n=lfittl@85-125-149-213.dynamic.xdsl-line.inode.at] has joined #launchpad === stu1 [n=stub@ppp-58.8.10.119.revip2.asianet.co.th] has joined #launchpad === Ubugtu [n=bugbot@ubuntu/bot/ubugtu] has joined #launchpad === kiko [n=kiko@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [05:00] hi kiko [05:00] how's it going? === somerville32 [n=somervil@fctnnbsc15w-156034069051.nb.aliant.net] has joined #launchpad === Ubug2 [n=bugbot@ubuntu/bot/ubugtu] has joined #launchpad === Keybuk [n=scott@syndicate.netsplit.com] has joined #launchpad [05:19] SteveA, going super. how's it going up north? === cprov is now known as cprov-lunch [05:32] hey malcc how's it going? [05:33] kiko: Going well, I was just preparing an email to the launchpad list updating the status of the soyuz system test stuff [05:33] ah, mind-reader [05:35] ddaa: ping? === AstralJava [n=jaska@cm-062-241-239-3.lohjanpuhelin.fi] has joined #launchpad [05:37] ddaa: unping [05:37] Keybuk: you're welcome [05:38] ddaa: no worries [05:48] ddaa, Keybuk: what is product-release-finder [going to be] used for? [05:49] It will automatically create Release objects with associated tarball by looking into the tarball locations specified in series/+source [05:49] kiko: it is all part of the master plan [05:50] what's product-release-filnder ? [05:50] it is related to things like NoSourcePackage, and [05:50] Keybuk: the new name for Dyson [05:50] New bug: #58881 in launchpad-cal "Accessing /+calendar/+subscriptions without logging in crashes" [Low,Confirmed] http://launchpad.net/bugs/58881 [05:50] ... and relating vcs-imports to package imports (sourcerer) [05:50] oh right [05:51] so yes, it scans FTP sites and downloads tarballs [05:51] kiko: old stuff which was first talked about two years ago [05:51] Keybuk: we've almost got it working too ... [05:51] registers the ProductRelease records and the tarballs in the Librarian [05:51] so they can be later imported into bzr [05:53] salgado, can you explain the change in r3957 in layman's terms? [05:54] gotcha. [05:54] thanks jamesh, Keybuk, daa [05:54] ddaa. === lfittl_ [n=lfittl@85-125-149-213.dynamic.xdsl-line.inode.at] has joined #launchpad [05:57] kiko, ProberFactory had a deferred attribute and one callsite was poking with it, causing the callbacks to be called in the wrong order, in some cases. I fixed the bug, renamed deferred to _deferred and left a comment explaining why it needs to be private [05:57] salgado, what does it do in practice though? [05:59] in practice it suppresses the AlreadyCalledErrors you've seen on the output of nighly.sh. :) [05:59] so... "A bug that caused mirror probes to be issued in an inconsistent order was fixed."? [06:00] not the probes themselves, as they don't need to happen in a specific order [06:01] what then? the probe handlers? [06:01] a bug that caused the callback chain of the mirror prober to be in the wrong order [06:01] right. [06:15] New bug: #58887 in launchpad-bazaar "Rank branches by heat" [Wishlist,Confirmed] http://launchpad.net/bugs/58887 === Kuhrscher [n=jannick@88.134.176.136] has joined #launchpad [06:24] BjornT, ping? [06:24] Seeking feedback on https://launchpad.net/products/launchpad-bazaar/+bug/58889 [06:24]