=== mpt_ [n=mpt@202.53.187.9] has joined #launchpad === GoRoDeK [n=gorodek@p5083ECF1.dip.t-dialin.net] has joined #launchpad === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #launchpad === Macho_Boy [n=yourz@ACB782AF.ipt.aol.com] has joined #launchpad === Macho_Boy [n=yourz@ACB782AF.ipt.aol.com] has left #launchpad [] === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #launchpad === AlinuxOS [n=Ubuntu@d83-176-124-91.cust.tele2.it] has joined #launchpad [02:35] alive? [02:35] :D === thierry__ [n=thierry@modemcable038.90-81-70.mc.videotron.ca] has joined #launchpad === ubuntulog [i=ubuntulo@195.22.207.161] has joined #launchpad === Topic for #launchpad: launchpad.net | developer meeting: Thur 19 Jan, 1200UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Channel logs are here: http://tinyurl.com/72w39 === Topic (#launchpad): set by SteveA at Thu Jan 12 13:08:50 2006 === merriam_ [n=merriam@84.12.191.233] has joined #launchpad === GoRoDeK [n=gorodek@p5083ECF1.dip.t-dialin.net] has joined #launchpad === lamont [n=lamont@mix.mmjgroup.com] has joined #launchpad === #launchpad [freenode-info] help freenode weed out clonebots, please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup === dilys [i=daf@muse.19inch.net] has joined #launchpad === mpt [n=mpt@219-89-150-86.jetstart.xtra.co.nz] has joined #launchpad === lamont [n=lamont@mix.mmjgroup.com] has joined #launchpad === poningru_ [n=poningru@n128-227-67-167.xlate.ufl.edu] has joined #launchpad === stub [n=stub@ppp-58.10.64.209.revip2.asianet.co.th] has joined #launchpad === poningru [n=poningru@n128-227-34-186.xlate.ufl.edu] has joined #launchpad === ajmitch_ [i=ajmitch@port169-250.ubs.maxnet.net.nz] has joined #launchpad === poningru [n=poningru@n128-227-13-219.xlate.ufl.edu] has joined #launchpad === Mez [n=Mez@ubuntu/member/mez] has joined #launchpad [06:15] Merge to devel/launchpad/: [trivial] Update Librarian front page (r3023: Stuart Bishop) === stub [n=stub@ppp-58.10.74.194.revip2.asianet.co.th] has joined #launchpad === jblack [n=jblack@static-209-158-45-74.scr.east.verizon.net] has joined #launchpad === poningru [n=poningru@n128-227-13-219.xlate.ufl.edu] has joined #launchpad [07:43] Hypothetical question... [07:43] If somebody attached a bzr branch to the wrong product.. how does one move it? [07:47] jblack: There's an "Administer" link [07:47] Ahh. I see it now. Thanks === Burgundavia [n=corey@S0106000000cc07fc.gv.shawcable.net] has joined #launchpad [07:56] Oh cool. I have two launchpad accounts [07:58] You should be able to merge them. [08:01] I'm not quite sure how I ended up with a "name79" anyways. === mpt_ [n=mpt@222-154-154-245.jetstream.xtra.co.nz] has joined #launchpad === southfoxargentin [n=fox@200-122-35-208.dsl.prima.net.ar] has joined #launchpad === southfoxargentin [n=fox@200-122-35-208.dsl.prima.net.ar] has left #launchpad [] === carlos [n=carlos@30.Red-83-49-57.dynamicIP.rima-tde.net] has joined #launchpad [08:24] morning === mpt__ [n=mpt@219-89-155-94.jetstart.xtra.co.nz] has joined #launchpad === jinty [n=jinty@135.Red-80-37-34.staticIP.rima-tde.net] has joined #launchpad === SteveA [n=steve@195.182.78.95] has joined #launchpad [09:44] hi === jblack waves [09:51] Urgh === SteveA waves and urghs back [09:51] Granted, I'm not a rockstar, but me waving shouldn't cause waves of nausea... [09:52] kinnison: Do you have a blog? [09:53] stub: voice call sometime today? [09:54] SteveA: Sure [09:54] jblack: yes [09:54] jblack: blog.digital-scurf.org [09:55] do you have rss? [09:57] jblack: atom [09:57] jblack: why? [09:57] I'd like to add it to planet.revisioncontrol.net [09:58] I need a feed if I'm to do so. Random guessing didn't work [09:58] aah [09:58] Use http://blog.digital-scurf.org/?flav=atom&planet=revisioncontrol.net please [09:59] even though its ironically not a planet? [09:59] an artificial planet? [09:59] "That's no moon!" [10:00] jblack: I use the "planet" thing to offer filtering [10:00] jblack: In the future, my blog will refuse to serve content without a planet argument which matches the source IP I designate for that planet === jblack chuckles === Lasse [n=Lasse@cpe.atm4-0-1301006.0x50a0824e.vgnxx6.customer.tele.dk] has joined #launchpad === Lasse [n=Lasse@cpe.atm4-0-1301006.0x50a0824e.vgnxx6.customer.tele.dk] has joined #launchpad === cprov [n=cprov@217.205.109.249] has joined #launchpad [10:15] any reviewer available for a small review? (preventing bugs from locking up the email interface) === Lasse is now known as lbm === kiko [n=kiko@217.205.109.249] has joined #launchpad [10:22] morning === kiko yawns [10:22] SteveA! [10:22] stub! === mdz [n=mdz@217.205.109.249] has joined #launchpad [10:22] kiko! [10:22] how goes it guys? [10:23] terrible [10:23] my mail is fucked [10:23] complainer [10:23] jordi, ping [10:23] postfix? [10:23] stub, tell me about gina on production [10:23] also, stub [10:24] I think we'll be running the initial soyuz run off celso's branch while we work on the review for merging [10:24] so I guess we should just rollout from last week -- or perhaps you want to roll out later this week and pick up your change that fixes celebrities? [10:26] kiko: Gina is running daily on drescher, importing *-security, *-updates, *-backports as well as dapper [10:26] stub, why do we get no log output? [10:26] Because it isn't producing any? [10:27] I find that a bit remarkable [10:27] We are not running -v, so we will only see warnings and errors [10:27] but warnings are very common [10:27] I can run it with -v for a day or three to see what happens [10:27] that would be k-rad === Kinnison points out that he needs gina's run to be golden by the time we decide to open [10:28] Which ideally will be in ca. 36 hours (not set in stone) [10:30] kiko: hey [10:30] stub, gina hasn't imported any packages since 2006-01-15 [10:31] and the last "publishing" was in 2005-12-22 [10:31] they have different hours in canada? [10:31] hey SteveA [10:31] SteveA, he meant circa [10:31] kiko: Erm, that's not good === kiko yawns [10:32] that's what launchpad_prod says anyway [10:33] blurgh [10:33] stub, is that what you expected to see? [10:34] cron output isn't happening from drescher :-/ [10:34] erm, gina's running on drescher? [10:34] stub, ah, that's more like it. [10:35] All stuck in mailq === stub emails rt [10:37] stub, hi, is the launchpad_carlos db ready to use? [10:37] stub, why did we decide to run gina on drescher? === kiko can't remember [10:45] kiko: Because we need to run it somewhere, and that is the box earmarked for this sort of thing (gina, publisher etc.) [10:45] stub, cool. [10:45] so any clue why she isn't running? [10:45] have you been rolling out to drescher too? [10:46] stub: the instance you're running gina from -- where is that? === stub is looking into it [10:47] ok [10:49] carlos: almost ready - data is there, just need to setup the permissions. just sorting gina first. [10:49] Kinnison: /srv/launchpad.net/gina [10:49] stub, ok [10:49] stub: Right === Kinnison will be sure not to touch that instance [10:49] stub: and which path is she reading the archive from? === stub waits for the code update to complete [10:50] carlos: pong [10:50] kiko: I haven't been updating the codebase on rollouts - I'd assumed she was running happily === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad [10:51] stub, I would imagine she'd need to stay updated with schema changes etc, though I guess there hasn't been one recently [10:51] hi [10:51] anyway [10:51] is launchpad broken atm? [10:51] I think it makes sense to roll out to drescher consistently with the rest of the webapp [10:51] seb128: seems to load for me. What page isn't working for you? [10:51] I get timeout pages while trying to do changes [10:51] jordi, could you answer to Simon Michael about the rosetta vs. upstream translations? [10:51] OOPS-24A202 [10:51] seb128, not entirely broken, but tell me an oops id [10:51] jordi, I think you asked about that already to me [10:51] ah [10:52] if you need the oops [10:52] but I don't see an answer to that email [10:52] that's while trying to edit settings for #29515 [10:55] stub: I repeat -- Which archive path are you reading from for gina? (or are you waiting for a code update in order to tell me that?) === stub looks locally [10:55] root /srv/archive.ubuntu.com/www/ubuntu [10:56] (this is configs/gina/launchpad.conf) [10:57] carlos: I will [10:57] jordi, thanks [10:57] stub: right === Kinnison will be sure not to touch those two paths when cleaning up drescher ready for deploying [10:58] Which user do you run gina as? [10:59] kiko: it works now ... === stub kicks off the sync a third time [11:02] Thailand's international connection is really sucky today :-/ === merriam_ is now known as merriam [11:14] stub: you use lp_import for gina runs? [11:15] I assumed so [11:15] (there wasn't a gina account on the box) [11:15] Thanks [11:15] That's perfect === stub hopes Kinnison wasn't being sarcastic [11:16] Nope [11:16] It's exactly the right user for you to use === Kinnison is just rationalising things and lp_import is the one set aside for htis [11:17] s/htis/this/ [11:17] Yay... fresh code === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [11:34] stub, what's going on? [11:35] Just finished reconfiguring gina's launchpad.conf, which had grown hair (damn required elements) and fired off Gina [11:35] I'm logging since we won't see cron output until elmo or Znarl get a chance to look at that box [11:36] okay cool [11:36] Oops. Connection refused exceptions when attempting to upload to the Librarian [11:36] stub, it's fixed already -- I asked elmo. [11:36] stub, heh :) === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [11:36] and he has delivered the goods he says === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [11:42] good morning! [11:45] stub: would you have time to take a quick look at my process-email fix? (and then roll it out later) [11:46] BjornT: Sure. I'd like to delay rollout until tomorrow though a the network is being flaky today === koke [n=koke@ubuntu/member/koke] has joined #launchpad [11:47] stub: ok, that's cool. i'll mail you the diff. [11:50] SteveA? === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad [11:54] where's jamesh? [11:54] hey matsubara [11:54] kiko lives in a personal void [11:54] sorry, personnel void [11:56] kiko: hey, how's london? [11:57] it sucks [11:57] it's freezing [11:57] there are no naked girls [11:57] and the shower doesn't work properly [11:57] (probably explains why there are no naked girls) [11:58] Come to Bangkok. Its 30 degrees and there are naked girls. [11:58] in fact [11:58] the only good thing about london is the bandwidth to the datacenter [11:59] It's more the lack of latency [11:59] We have very good international bandwidth so I'm supprised it's an issue. [12:00] Merge to devel/launchpad/: [trivial] Production gina config updates (r3024: Stuart Bishop) [12:00] Znarl, other countries don't, though. [12:01] Znarl: brazil's internet connection is two bits of wet twine, strung between the thighs of a columbian drug lord [12:01] shut up already === niemeyer [n=niemeyer@200.138.131.46] has joined #launchpad [12:01] dude, it's only funny 'cos it's true [12:02] stub, what revision are you intending to cut the production rollout on, do you know? [12:03] kiko: 3018 for sure - possibly later as there is at least one thing that should be cherry picked (3021 - the celebrity optimization) [12:03] And BjornT's email fix when it lands [12:03] stub, when you know will you tell me so I can finish off the report? [12:04] 3018 plus those two cherry picks should do it. I've got nothing else flagged. [12:04] I have done till 3018. [12:04] cool. [12:04] are you confident the celebrities fix will work 100%? [12:04] carlos: what box do you need to connect to that database from again? [12:05] kiko: Its running on staging, so worst case is the optimization doesn't. [12:05] stub, you know, it would be cool to be able to generate a oops on demand [12:05] We could leave it a week easily enough, but I expect you are right and that it will help a lot of the OOPS timeouts we currently see [12:06] because then we'd be able to tell if the optimization works [12:06] stub, is there a page that is particularly bad on staging that I'd manage to get an oops on while insisting? [12:06] There is a test that does that I think - jamesh's db_timeout tests use it === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:07] url?oopsplease=1 [12:07] I'm not aware of pages that can reliably generate timeouts at the moment - one of the bug reports could do it [12:07] If you just want an oops, go to https://launchpad.net/idontexist [12:07] man staging is SLOW [12:10] carlos: that db should be available to you now from mawson [12:12] so staging is busted. stub? === kiko is confused [12:12] it is? === stub has a look [12:13] I mean, my ping is 45ms to it. [12:13] no reply for the last 5 minutes [12:14] kiko: Fixed. Looks like it had failed to shutdown properly before. [12:14] thanks man [12:15] hmph [12:17] I ROCK [12:17] OOPS-24S1 [12:17] it is so easy to cause a timeout [12:17] just try to find a person named "a" in +editstatus === niemeyer [n=niemeyer@200.181.171.70] has joined #launchpad [12:24] BjornT: You are just deleting the email when you can't create an email.Message instance. The message should have been stuffed into the Librarian before this happens so that we can examine the dud email. [12:27] stub, by the way, the query that timed out for me in staging, it's on the same query as I posted to email :) [12:28] stub, I see /no/ query for celebrities in my timeout, which is pretty remarkable [12:29] are they cached once per instance or something? [12:29] no that can't be [12:29] If it is a public page, it might not need to use any of them [12:29] it's +editstatus [12:30] SteveA, stub, spiv: what's happening to jamesh' fix that nukes out __len__? === thisfred [n=thisfred@a80-127-80-154.adsl.xs4all.nl] has joined #launchpad [12:31] There should be one request per request per celebrity accessed. I would expect most pages to at least need to access the launchpad developers celebrity, as this is queried at the start of each request if you are authenticated. [12:31] sorry can you repeat that stub, I lost that line === kiko hates xchat's crack [12:31] There should be one request per request per celebrity accessed. I would expect most pages to at least need to access the launchpad developers celebrity, as this is queried at the start of each request if you are authenticated. [12:31] and admins? [12:31] one db request per http request [12:31] sounds perfect, but it doesn't show up in this oops report: [12:32] https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-01-24/S1 [12:32] the next big win in terms of number of queries would be caching the inTeam query. [12:32] stub: true. although, instead of going through the trouble of uploading it to the librarian, i think it's enough to simply print the raw message in the log. would that be ok? (i don't think that error will happen often, so far it's never happened afaik) [12:32] I think that would probably be okay -- what do you think stub? [12:32] kiko: You can't see them because they are now by id [12:33] oh that's the first two queries now? [12:33] stub, thanks, it works! [12:33] stub, so I should ping you every time I want an update? [12:33] BjornT: If it is a large message, it will be lost. And then you have to worry about encoding etc. I think it would be better to simply move the 'stuff this in the librarian' section up a few lines. [12:34] stub: when i land some Crowds security updates, we'll need just celebrity ids a lot of the time [12:34] stub, isn't it possible to get an update weekly? (that's what I need to run a cron job) [12:34] 15158 is the launchpad developers team [12:34] carlos: Yes - I will automate it, but I havn't done it yet. So ping me next week in case I haven't [12:34] stub, ok, thanks [12:36] stub: ok, i'll do that then. [12:36] BjornT: Rest of it looks fine. r=stub if you don't think it will need a rereview [12:37] thanks [12:40] again: SteveA, stub, spiv: what's happening to jamesh' fix that nukes out __len__? === Ubugtu [n=bugbot@ubuntu/member/seveas] has joined #launchpad [12:42] kiko: I havn't seen it, and I havn't seen it land [12:43] I saw it in -reviews but it died out [12:43] summary says all three branches are in merge-conditional === stub goes for food [12:53] daf, and yet.. [12:53] indeed [12:54] hmm, perhaps the bug list should use months for weeks old > ~12 [12:54] or even 8 [12:58] stub: ping? [12:59] Kinnison: pong [12:59] stub: We need to discuss access from drescher [12:59] Ok. Can it wait an hour? I was just heading out with wifey for food [01:01] stub: Erm, Yes, I guess so, although if you can add at minimum 'ro' access for lp_archive on drescher then I'd appreciate it [01:02] stub, ping me when you're back [01:02] Kinnison: Done [01:02] kiko: ok [01:02] thanks. [01:03] stub: thanks dude, have a good lunch === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [01:27] it seems that every launchpad developer and his dog agree that the sidebar are a problem... can somebody remind me why we still have them? [01:28] Is that just "because it would be a lot of work to fix all the pages"? [01:28] or something else? [01:37] hey BjornT, would you like to review that patch to fix bug 5394? (it's on the review queue already) [01:37] Malone bug 5394: "Clicking on "Advanced search" should preserve simple search criteria" Fix req. for: malone (upstream), Severity: Normal, Assigned to: Guilherme Salgado, Status: In Progress http://launchpad.net/bugs/5394 === raptoid [n=raptoid@unaffiliated/raptoid] has joined #launchpad === GoRoDeK [n=gorodek@p5083E3D3.dip.t-dialin.net] has joined #launchpad === raptoid is now known as darkStar === darkStar is now known as raptoid === beyond [n=beyond@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === mantiena [n=vytis@bonamens.lt] has joined #launchpad [01:48] Hi all [01:53] cprov/Kinnison, I have the feeling that the guess{Sources,Binaries} methods should read the Release files in the mirror to do their work. am I right? [01:54] cprov/Kinnison, if so, is there any existing code to parse that file's content or do I need to write it myself? [01:54] SteveA, labas [01:56] salgado: Isn't it a standard "tags" file? [01:56] salgado: There's code for parsing it already [01:57] I'm not sure what a standard "tags" file is. :-( [01:58] salgado: apt_pkg can handle it, and there's some wrapper code in archivepublisher.tagfiles [01:58] ahhh, nice [01:59] thanks niemeyer. :) [01:59] You're welcome ;) [02:00] kiko, Hi are you alive ? ;) [02:12] BjornT: hello [02:12] ddaa: One reason is that a lot of the information is actually needed. If it is removed from the side bar, it needs to go somewhere else. The other is that mpt has to work with a number of mandatory design points. [02:12] BjornT: are mails sent to the email interface bouncing right now? [02:13] SteveA: They are being queued [02:13] stub: is "three columns layout" part of the mandatory design points? [02:13] stub: might be better to bounce them === Znarl [n=karl@bb-82-108-14-161.ukonline.co.uk] has joined #launchpad [02:13] SteveA, are you busy now ? [02:13] because processing a command after quite a while may have unexpected consequences [02:14] if other things have been done in the mean time through the web interface [02:14] ddaa: you can talk with me about UI things in launchpad. [02:15] SteveA: That needs to go through rt then - I can't change that. We could also just copy over an updated process-email.py and turn it back on. [02:15] SteveA: nothing very specific ATM. Just weird feeling. Everybody seems to say "sidebars are a problem" but it feels like it's not possible to get rid of them for some unspoken reason. [02:15] stub: copying over process-email.py would be good. [02:15] then maybe I'm violating some taboo by asking that here... [02:16] ddaa: there's ongoing work to make many pages two column rather than three column. [02:16] salgado: sure, i can review your branch. i'll see if i have time to do it today, otherwise i'll do it tomorrow morning [02:17] mantiena: yes, quite busy right now. [02:17] BjornT, that's great, thank you! [02:18] SteveA: is there a generic reason why "just one column" is not possible? [02:19] But where would all the portlets go? [02:19] ddaa: i'm interested in discussing this, but i need to go out for a while now [02:20] stub: when they contain useful information, they can go at the top of the body. When they do not, they can just go away. [02:21] sometimes malone fails to honour the newlines I put between the lines I write in a comment, and other times it doesn't. how does it decide? === doko__ [n=doko@dslb-084-059-096-046.pools.arcor-ip.net] has joined #launchpad [02:21] I'm picking one page at random. /people/ddaa. "Latest David Allouche Support Requests"... That has nothing to do here... [02:22] see https://launchpad.net/distros/ubuntu/+source/checkinstall/+bug/29536 for example. It joins lines together which should be separate. [02:22] Malone bug 29536: "installwatch.so has moved; somebody should tell checkinstall" Fix req. for: checkinstall (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed [02:22] yes, that one. [02:23] The person details portlet, fine... Is that really useful on _all_ the person pages? I do not think so. Better to just put that in the person index. [02:23] Then we have the sitemap and the menu. [02:24] They are actually the same feature, suffering from a split brain syndrome. [02:24] mpt made a lot of good work here, that makes the issue only more apparent [02:27] There's also the fact some people (e.g. jblack) had trouble associating the menu with the "context". [02:27] So, I think it would be beneficial to collapse the sitemap, details, and menu in one thing, at the top of the page. [02:28] here... one column in the person pages! [02:28] okay, a bit handwavy, that makes the point. === Kinnison glances at his list of things to do [02:33] stub: So, can we talk databases? === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has joined #launchpad [02:36] Kinnison: I've got kiko off channel, but sure [02:37] Well, first-up I need to start prodding a bunch of tables to prepare stuff for deployment [02:37] stub: I need UPDATE on distribution and distrorelease, INSERT on componentselection and sectionselection, and INSERT on distrocomponentuploader [02:38] stub: (that's all I've worked out so far) [02:39] Kinnison: Ok. I'll create you an account with full read access and extra permissions on whatever tables you need (starting with the ones you just mentioned) === stgraber [i=steph@xeon.stargate-server.com] has joined #launchpad [02:42] stub: thanks [02:43] SteveA, when you will be not so busy then please look why I still can't add Baltix milestone or release (look at https://launchpad.net/distros/baltix/+addmilestone ). kiko told me, that this will be fixed during the week, but now is 1,5 week after [02:44] mantiena, the fix hasn't been rolled out yet. hold on for stub. [02:45] update was put off today due to a flaky network connection here. I'll be doing the update in about 16 hours time [02:47] great. [02:48] is that timeout well known? [02:48] https://launchpad.net/distros/ubuntu/+allpackages [02:48] (I hope by doing so, everybody will check and it will show up in the error report this week) === jsgotangco [n=jsg@210.4.59.157] has joined #launchpad [02:54] Kinnison: sourcepackage-buildlog.pt says something interesting [02:54] does it now? [02:54] The build log is produced when we try to compile the source package into binary packages which can be installed on your distribution. There may not be a build log if this is a read-only distribution (one we just monitor but don't actually produce in the Launchpad, like Ubuntu and its derivatives). [02:54] Still true? [02:55] Just hunting for explicit ubuntu references, stumbled on that (legitimate) bit by chance, and made me wonder... [02:57] Umm, that's confusing as fuck [02:58] strange, I thought fuck what instead quite straightforward [02:58] and backwards [02:58] forward === ddaa realises he actually _was_ confused [03:03] That needs better text [03:03] I don't have time to do it [03:03] file a bug against soyuz please [03:03] i/e i/o, I got a bug to go [03:07] bug 29548 [03:07] Malone bug 29548: "buildlog informative portlet is confusing as fuck" Fix req. for: soyuz (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/29548 [03:07] thanks [03:08] Ubugtu, language! [03:08] Ubugtu has no morals [03:09] stub, so, after 16 hours I will have a posibility yo add new milestone/new release in Baltix distribution ? [03:09] Part of the problem is that Launchpad knows darn well whether there's a build log or not, so it shouldn't be saying "there may not be a build log" [03:09] anyway... [03:10] it's hidden in a portlet [03:10] you actually have to look for it to find it [03:11] But right, that should be displayed in the page body IFF there is no build log. [03:11] mantiena: I don't know if anyone has landed a fix for that particular bug or not. [03:11] and I do not think there is no point explaining what a build log is if there's one... [03:12] please do not omit to remove of those negations in the previous sentence === Keybuk [n=scott@descent.netsplit.com] has joined #launchpad [03:14] stub, I did. [03:15] mantiena: yes [03:17] ok, I'm then waiting ;) [03:18] kiko: sent final reply to your branch/series/bzr cleanup [03:19] thanks ddaa [03:19] my pleasure [03:20] the concept of ProductSeries is fucked up IMO [03:20] many things are [03:20] but it may be useful in the HCT scenario, last I considered it? [03:21] I think it actually means something quite important to HCT [03:21] as I mentioned in my mail, I think each series should in the end be associated to branch generated by Dyson. [03:21] but niemeyer is the authority on that sort of stuff [03:22] well, except series without releases, which currently exist to be able to do RCS imports, which I consider a bug. === poningru [n=poningru@n128-227-139-80.xlate.ufl.edu] has joined #launchpad === matsubara is now known as matsubara-lunch [03:49] stub: re bugwatches [03:49] what is the problem, too many watches to gnome bugzilla in malone? [03:50] Merge to devel/launchpad/: [r=stub] improve error handling in process-mail.py, so that it can continue to run even if an email causes an unexpected exception. (r3025: Bjorn Tillenius) [03:50] too many bug watches for a system that checks them one at a time [03:51] Is the issue that this causes a rush of requests on the gnome bugzilla? [03:51] if that's the case, that should be fixable just by throttling... say one bug per second... [03:52] or maybe one every 5 seconds [03:52] that would avoid the DOS issue. [03:52] or am I missing something important? [03:53] BjornT, stub: Do we need r3025 cherrypicked? [03:53] ddaa: I'm not sure of the load issues on the bugzilla end. Just that it was suggested by Gnome people that we should turn it off until we implemented checking in batches [03:54] bradb: I've already cherry picked the code I was sent to review, which won't be as good but good enough until the real rollout tomorrow [03:55] stub: Ah, so the email interface is up currently? [03:55] Hopefully :-) [03:55] ok, thanks [03:57] stub: it seems like it isn't running due to a stale lock file [03:57] BjornT: I've removed the lock file [04:00] stub: ah, some other changes in mail/incoming.py hasn't been rolled out yet. forgot about those. [04:03] stub: r3018 is needed as well. will it be rolled out tomorrow? i'll see if i can give you a patch against the current production version of incoming.py. [04:04] 3018 will go out tomorrow === salt [n=Poring@202.77.117.241] has joined #launchpad [04:04] BjornT: So, it's currently down, but will be back up tomorrow? [04:05] bradb, stub, ddaa: fixing Bugzilla watch updating is something I hope BjornT is taking care of :-) [04:06] kiko: how much would you take to sell me a soul to work on fixing importd problems? [04:06] BjornT, I can help you explain how I think checkwatches should work, if you like. [04:07] ddaa, mmmm. I'd need to know more about what's bothering you right now. [04:07] but it should be possible, definitely [04:07] a number of things, we can have a chat about that if you wish [04:08] yeah, but this week it appears that I'll hardly be able to, because of the soyuz rollout. [04:08] I can try though [04:08] kiko: yes, it's on my list to fix. i havn't thought much yet about how checkwatches should work, so feel free to give suggestions if you have time. [04:08] kiko: it's nothing that cannot wait _yet_ another month... [04:11] BjornT, I do have time -- do you want to take a look at it and come back and ping me? [04:11] ddaa, I don't have too many wildcards free right now, hmmm [04:12] it's a bunch of issues that have been staying below the "need to fix now!" threshold for a long time but are seriously impairing the quality of RCS import service. [04:13] talk about that later [04:14] bradb: actually, it looks like the email interface is up running now. stub, did you do anything else then removing the lock file? i saw one error message about an import error, but it seems to work now. [04:15] BjornT: How often doesn't process-mail get run? [04:15] kiko: sure, i'll take a look at it now. it's probably best to fix checkwatches.py before i fix any else about bug watches [04:16] sure. [04:16] bradb: every 3 minute [04:16] thanks === matsubara-lunch is now known as matsubara [04:53] Merge to devel/launchpad/: r=kiko Community fixes to various scripts: link-external-sourcecode, launchpad-database-setup, Makefile (r3026: Christian Reis) [04:55] sivang, I think utilities/launchpad-database-setup improves things === Mez [n=Mez@ubuntu/member/mez] has joined #launchpad === jinty [n=jinty@115.Red-80-24-9.staticIP.rima-tde.net] has joined #launchpad [05:17] Merge to devel/launchpad/: r=kiko Additional community fix to launchpad-database-setup (r3027: Christian Reis) [05:20] heh [05:20] BjornT, how's it going? [05:21] kiko: sorry, i got side tracked by other things. let me have a quick look now [05:22] \o/ [05:25] kiko: ok, it was a quite small script. so, what were your thoughts about how it should work? [05:25] heh [05:25] BjornT, you need to look at canonical/malone/externalsystem.py [05:26] that's the engine for the script === gneuman [n=gneuman@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [05:28] kiko: yeah, i'm looking at it. it's still not that big :) [05:28] heh [05:28] ok [05:29] BjornT, so, the easiest fix I can see is: [05:30] - Adding an ExternalSystem.get_bug_status_multiple() [05:30] - Grouping the bug watches by bugtracker in scripts/checkwatches.py and invoking that method [05:30] what do you think? === beyond is now known as beyond-rango [05:32] kiko: yes. although i'd like it to be ExternalSystem.update_bug_watches() instead, since we want to update more than just status in the future. [05:32] YAGNI [05:33] daf, no, I suspect he's right [05:33] we will want to grab some extra information at least -- pri/sev might be good ideas [05:38] salgado, how do you make launchpad access a different port on anthem? just set an env variable? === jinty [n=jinty@115.Red-80-24-9.staticIP.rima-tde.net] has joined #launchpad [05:39]