[12:10] <bradb> mpt_: Basically: are you okay with me merging this change?
[12:11] <mpt_> bradb, sure, if the page is already there
[12:12] <bradb> yep, it's already there, thanks
[12:12] <mpt_> provided you've removed the <u> tag
[12:12] <bradb> mpt_: http://69.70.209.33:8086/distros/ubuntu/warty/+bug/6/+backport
[12:13] <kiko-zzz> thank god the <u> is gone
[12:13] <kiko-zzz> and so am I, gnight
[12:13] <mpt_> night kiko
[12:13] <bradb> This UI is still crummy, but I guess it's about 1% better than it was before
[12:41] <dilys> Merge to devel/launchpad/: [trivial]  Kill broken, untested unused and unreferenced project +malone-index page; Brad has a screenshot to recreate this the right way when the time comes (r3170: kiko)
[12:57] <spiv> doko: I don't know of any reason not to update.
[12:59] <doko> spiv: ok, could you tell me the same for updating Web2 to the current SVN? :)
[01:01] <spiv> doko: Unfortunately, I don't know as much about web2.
[01:01] <doko> spiv: used by lp at all?
[01:02] <spiv> No, not yet.
[01:02] <spiv> But Zope 3.2 can use it.
[01:03] <spiv> And once that proves solid enough, we'll probably switch to it.
[01:03] <doko> yes, that's the reason I ask. the released version doesn't work with Zope 3.2
[01:03] <spiv> So for lp, the important question is whether it works with Zope 3.2.
[01:03] <spiv> Which I don't know.
[01:04] <doko> ok, well, then I'll update to svn, at least Zope 3.2 seems to work with it
[01:04] <spiv> Sounds good.
[01:11] <dilys> Merge to devel/launchpad/: [trivial]  Kill broken, untested unused and unreferenced project +malone-index page; Brad has a screenshot to recreate this the right way when the time comes (r3171)
[01:39] <dilys> Merge to devel/launchpad/: [trivial]  Make the DistributionSourcePackage views use the standard +latest-bugs portlet instead of its own hackish version; removes DistributionSourcePackaveView.latest_bugtasks (r3172: kiko)
[02:22] <cprov> stub: hi dude, when will you start the rollout procedure ?
[02:23] <stub> cprov: If you are up for it, sure.
[02:23] <stub> It will take 30 mins to tag and test the branch
[02:23] <jblack> stub: I have a question for you when you're free
[02:24] <cprov> stub: no, the opposite, I'm blocked by a problem in queue builder. just wonna know how much time I have yet
[02:25] <stub> cprov: Take as much time as you need and give me a yell when you are ready. I generally do the rollouts in my afternoon - about 6 hours away.
[02:25] <stub> I'll tag the branch and run the tests now so things are ready.
[02:25] <stub> jblack: Whats up?
[02:26] <jblack> I need to make dependancies packages for bzr -- both for developers, and for rollout. Do you have any dependancies that are different than a lp dev would use?
[02:26] <cprov> stub: good, I'll take that 6 hours, thanks. I love working overnight :(
[02:27] <stub> jblack: graphviz and postgresqsl_autodoc are the only extras I use, and that is just on my local box.
[02:27] <jblack> Ok. So no extra dependancies. Thats good. That makes things even simpler.
[02:28] <stub> cprov: We can put off the rollout until tomorrow, or do a second one then if you want.
[02:29] <cprov> stub: let's see how the things are going, I need to merge RF in in base soyuz production anyway (8 conflicts) but i really want to delivery these new features 
[02:29] <cprov> stub: don't worry, we will do it today
[02:29] <cprov> stub: btw, can you tweak the perms for creating new dbs as postgres in mawson ?
[02:30] <stub> cprov: Do you mean you need access to the actual postgres user?
[02:31] <cprov> stub: yes, as I said in the email, copy dbs, etc
[02:31] <stub> ok. Should have the same permissions as your cprov account, but I'll let you connect as postgres from the cprov and launchpad unix accounts.
[02:32] <cprov> stub: nice, so I can create dbs owned by postgres 
[02:38] <stub> cprov: done
[02:39] <stub> jblack: Ooh.... we need a local SMTP server on dev and production, and an ident server on production
[02:40] <stub> And whatever package 'telnet' lives in for quick'n'nasty testing
[02:41] <stub> ii  oidentd                     2.0.7-3                      replacement ident d
[02:41] <jblack> Ok, so telnet, mail-server, ident-server
[02:42] <stub> We use Pound but only on one or two boxes, so I guess that doesn't go in there.
[02:42] <stub> Ooh... screen on the production boxes too
[02:43] <jblack> I was clear that we're talking dependancies, right?
[02:43] <stub> ok. nuke screen and telnet
[02:43] <jblack> do you want them as dependancies, or recommends? 
[02:43] <stub> recommends
[02:44] <stub> ident-server isn't technically needed for launchpad, but the server won't be able to connect to emperor without it
[02:44] <jblack> Ok, so depends:  mail-server, ident-server  recommends: screen & telnet
[02:44] <stub> crcon
[02:44] <stub> cron
[02:45] <jblack> Heh.
[02:45] <jblack> Ok, so depends:  mail-server, ident-server, cron  recommends: screen & telnet
[02:45] <stub> gcc :)
[02:45] <stub> (and friends)
[02:45] <jblack> Its starting to sound to me like they're not identical
[02:45] <lifeless> stub: gcc == build-essential
[02:45] <jblack> Ok, so depends:  mail-server, ident-server, cron, build-essential  recommends: screen & telnet
[02:48] <stub> I think that is it, unless you feel like adding vim and less
[02:51] <jblack> Ok. Thanks
[03:10] <mpt_> whoa, cprov's awake
[03:10] <mpt_> Got time to answer a question, Se?or Providelo?
[03:10] <cprov> mpt_: my life sucks ;)
[03:10] <cprov> mpt_: just fixing pending soyuz feature 
[03:10] <cprov> s
[03:10] <cprov> mpt_: how are you ?
[03:11] <mpt_> Tired
[03:11] <mpt_> I got up at the horrible hour of 9am
[03:11] <cprov> mpt_: ask whatever you want sir
[03:11] <cprov> mpt_: wake up at 9 has been my dream for a long time ;)
[03:11] <mpt_> cprov, where would I find a page using distroreleasesourcepackagerelease-index.pt?
[03:12] <mpt_> I'm afraid to find one, because it's all portlets, no content
[03:12] <cprov> distros/ubuntu/dapper/+sources/pmount/0.9/
[03:12] <cprov> mpt_: ehe the distro guys know that 
[03:13] <cprov> empty/blank main div, funny 
[03:13] <cprov> mpt_: should I say sad ?! 
[03:14] <mpt_> yes, very] 
[03:15] <cprov> bug 31622
[03:15] <Ubugtu> malone bug 31622 in soyuz "Individual build pages should link back to source package" [Normal,Confirmed]  http://launchpad.net/bugs/31622
[03:15] <cprov> mpt_: we are about to use it 
[03:15] <jamesh> London shouldn't be too cold at this time of year, right?
[03:15] <mpt_> Wow, is it just me, or is it really hard to get to a source package page
[03:16] <mpt_> hmm
[03:17] <jamesh> mpt_: don't you just enter the name on the distro page?
[03:17] <mpt_> That searches binary packages, not source packages
[03:17] <mpt_> so it gets me about 1/8 of the way there
[03:18] <jamesh> the search box is marked "source packages in $DISTRO"
[03:18] <mpt_> oh!
[03:18] <mpt_> I started at the distro release page
[03:20] <mpt_> So far I've gone Dapper -> binary package search results -> distrorelease binary package -> distroarchrelease binary package -> distro source package -> distrorelease source package
[03:21] <mpt_> ... -> distrorelease source package release! hurrah!
[03:21] <mpt_> but wow, that should not be so hard to find
[03:23] <mpt_> cprov, "we are about to use it" for what?
[03:23] <mpt_> What is going to appear there?
[03:23] <cprov> mpt_: link from those wonderful +builds/+build/1234 pages
[03:24] <cprov> mpt_: honestly, no idea atm
[03:25] <jamesh> mpt_: if you started at https://launchpad.net/distros/ubuntu/dapper/, you could have clicked "Source Packages" in the site map in the top left
[03:25] <cprov> mpt_: in fact there is nothing more than some summary, the binaries for this release, dates, owner, maintainer, etc
[03:26] <mpt_> jamesh, oh, but that's the sitemap, nobody uses that ;-)
[03:27] <jamesh> mpt_: dude.  You speced it :)
[03:27] <mpt_> I was just following orders
[03:30] <cprov> stub: is librarian down ?
[03:31] <cprov> stub:  http://librarian.dogfood.ubuntu.com/1552516/chroot-dapper-i386.tar.bz2 
[03:31] <stub> cprov: I havn't started it - I thought you and Kinnison took over running the dogfood system?
[03:32] <mpt_> cprov, ok, I think I'll move the Builds portlet into the main area
[03:32] <cprov> stub: sorry, I'm running df librarian it's upstream
[03:32] <cprov> mpt_: sounds nice to me 
[03:33] <cprov> stub: yes, it works upstream
[03:33] <cprov> stub: nevermind
[03:33] <stub> cprov: I think you need a http_proxy set
[03:33] <stub> export http_proxy=http://squid.internal:3128/
[03:34] <cprov> stub: see the error https://chinstrap.ubuntu.com/~dsilvers/paste/fileLbUynP.html
[03:35] <stub> cprov: the dogfood config does not have the 'use upstream librarian' options set. Search for 'upstream' in configs/staging/launchpad.conf
[03:38] <cprov> stub: indeed, lost after sync ...uhm kick me if you have time
[04:26] <stub> cprov: Give me a UTC time to schedule automatic updates of the dogfood database to production - it currently takes about 3 hours to do the restoration.
[04:27] <cprov> stub: normally 0 UTC is fine (22 PM here)
[04:28] <cprov> stub: and sync to launchpad_production would be ok, since I'll keep using launchpad_dogfood
[04:29] <stub> I don't want to call the database launchpad_production - it needs to be very obvious what database you are connected too (particularly launchpad_prod), and duplicate names confuses things and could cause accidents.
[04:30] <lifeless> I was thinking the same thing
[04:30] <stub> So you want to keep launchpad_dogfood untouched, and a regularly updated replica of production using some other name on mawson
[04:32] <stub> food and bill paying
[04:43] <LaserJock> if there is a way to remove a package from "Fix Requested In" in a bug report?
[04:46] <jamesh> LaserJock: you can reassign a bug task to another package, or mark a particular bug task as rejected
[04:48] <LaserJock> jamesh: will rejecting that bug task reject the bug as a whole?
[04:48] <jamesh> LaserJock: the status only applies to the bug task.  If there is only a single bug task, then that would be equivalent to rejecting the entire bug
[04:48] <jamesh> LaserJock: what bug are you talking about, exactly/
[04:48] <jamesh> ?
[04:49] <LaserJock> 5612 and 29191 both refer to bugsx but it has nothing to do with the bug
[04:51] <jamesh> how did they end up with those tasks?
[04:54] <LaserJock> I have no idea
[04:55] <jamesh> LaserJock: I'd suggest retargetting those tasks at update-notifier
[04:55] <jamesh> LaserJock: click on "bugsx (Ubuntu Dapper)", and change the package name from "bugsx" to "update-notifier"
[04:57] <jamesh> LaserJock: looks like someone with the username "catinsnow" created those two tasks on 2006-02-01
[04:59] <LaserJock> hmm, ok. I'll do that. I have no idea why they did that
[05:05] <jblack> Whoah!: http://blog.digital-scurf.org/2006/02/20#drastic-change
[05:08] <LaserJock> hmm, what's with this need for linux guys to have lots of hair all over? Just lack of time?
[05:08] <ajmitch> jblack: who's that scary person? 
[05:08] <jblack> ajmitch: kinnison
[05:09] <ajmitch> impossible
[05:09] <ajmitch> I recognise the one on the left, though
[05:16] <jamesh> LaserJock: the ones in NZ did it for a good cause
[05:16] <jamesh> lost their hair, that is
[05:20] <LaserJock> jamesh: that's cool.
[05:22] <LaserJock> it just seems like many of the main Linux devs seem to have lots of "wild" hair. Maybe it's just me. :-)
[05:29] <stub> Its a way of saying 'I don't have to wear a suit to work' without actually saying it
[05:31] <LaserJock> yeah, I suppose. I just wear jeans. 
[06:12] <cprov> stub: sorry dude, was distrated fixing bogus chroot, I'm happy with a less confusing name, keep the launchpad_dogfood untouched and replicate production db daily in a very obvious name (whatever you think is sane) 
[06:13] <stub> cprov: ok
[06:14] <dilys> Merge to devel/launchpad/: [trivial]  Disable test_adapter as per bug #32231 (r3173: Stuart Bishop)
[06:15] <cprov> stub: btw, should I merge RF head to ready for rollout ?
[06:17] <stub> cprov: merge -r 3159
[06:17] <cprov> stub: okay
[06:19] <wassah> is there a launchpad admin available?
[06:37] <lifeless> FSVO available
[06:45] <wassah> i was wondering if it is possible to remove a registered project?
[06:51] <lifeless> generally speaking no, because things will reference it almost immediately
[06:51] <lifeless> what project do you want removed ?
[06:51] <wassah> ktdms german translation
[06:51] <wassah> my decision to register it was not well thought out
[06:52] <lifeless> for this probably we need stub to have a look see
[06:52] <lifeless> wassah: whats the url in lp to it ?
[06:52] <wassah> https://launchpad.net/products/german-translation
[06:53] <wassah> oops
[06:53] <wassah> or does that work?
[06:54] <lifeless> stub: ^^ can you see about removing this for wassah? ^^
[06:54] <lifeless> wassah: yes it does
[06:54] <wassah> ok
[06:55] <wassah> to be honest, i am totally new to launchpad and its working and registered this on behalf of other people without them knowing
[06:56] <wassah> that's the reason
[06:56] <wassah> thanks for the help, in advance
[06:57] <wassah> next time i'll be sure to put more thought into it before making such a spontaneous decision
[06:57] <lifeless> ;)
[06:58] <wassah> :)
[07:47] <SteveA> morning
[08:09] <cprov> ohh god .. production DB rename takes 40 min at mawson, this time 40 mins looks like 40 hours
[08:13] <SteveA> what does "production DB rename" mean?
[08:20] <cprov> SteveA: ehe, copying the production replica to launchpad_dogfood, in practice
[08:34] <SteveA> jamesh: ping
[08:39] <cprov> stub: ping
[08:47] <cprov> anyone familiar with this error ?
[08:49] <cprov> https://dogfood.ubuntu.com/distros/ubuntu
[08:51] <SteveA> Forbidden?
[08:51] <SteveA> looks like the certificate set-up is incorrect
[08:51] <SteveA> file an RT
[08:58] <cprov> SteveA: no no dude, certificate works for me, have a templates/distribution-index.pt error as KeyError:40, something has changed in TicketStatus 
[09:00] <BjornT> cprov: run database/schema/pending/reduce-support-tracker-statuses.sql
[09:01] <cprov> BjornT: very nice, thank you :)
[09:06] <SteveA> so, why can't I see https://dogfood.ubuntu.com/distros/ubuntu ?
[09:06] <SteveA> jamesh: ping?
[09:08] <BjornT> SteveA: maybe you need the client certificate, and you don't have it installed?
[09:09] <SteveA> that's odd.  i *used* to have them...
[09:13] <SteveA> this is odd...
[09:13] <SteveA> when i run the command "host somedomain" i get no response
[09:13] <SteveA> when i run it with an additional argument as either one of the servers from /etc/resolv.conf, i get an answer
[09:19] <carlos> morning
[09:19] <SteveA> hi
[09:22] <cprov> carlos: morning, you gave me old packages and I'm still having problems with dogfood builders, so could not test your things properly 
[09:25] <SteveA> stub: rolling out today?
[09:27] <carlos> cprov: hi
[09:27] <carlos> cprov: old packages?
[09:27] <carlos> cprov: I did a source build and upload all files to mawson
[09:27] <cprov> carlos: yep, version already present in dapper
[09:28] <carlos> oh, of course, I got it from dapper O:-)
[09:28] <carlos> so I need to change the version
[09:28] <carlos> ok
[09:28] <cprov> carlos: yup, we have about one hour
[09:28] <carlos> cprov: you will have the new version in 10 minutes
[09:29] <cprov> carlos: good
[09:37] <carlos> cprov: it's done
[09:37] <cprov> carlos: thanks duderino
[09:38] <carlos> cprov: is there anything else I can do to help you?
[09:41] <cprov> carlos: no, thanks,  i've already done 
[09:41] <carlos> ok
[09:41] <carlos> cprov: please, ping me when the import is done so I can check the import queue
[09:57] <jordi> hey dudes
[09:57] <jordi> carlos, cprov: what's the dapper status today?
[09:57] <carlos> jordi: hi
[09:57] <carlos> jordi: testing it
[09:58] <jordi> carlos: cool. Will it go live in today's rollout?
[09:58] <cprov> jordi: yes, that's the plan 
[09:59] <carlos> cprov: did you get a reviewer for your branch?
[09:59] <cprov> carlos: salgado 
[09:59] <carlos> cool
[10:00] <jordi> carlos: ok. I can write up an announcement if you like
[10:00] <cprov> carlos: not really, we didn't have time to start :(
[10:00] <carlos> jordi: not yet, please
[10:00] <jordi> carlos: I mean, for the moment it's live. Of coruse I don't intend to send it before...
[10:00] <carlos> jordi: this will allow new imports to be done automatically but there are some other parts that need manual import
[10:01] <carlos> (the builds done before this code update)
[10:01] <carlos> cprov: well, at least it's a start that you have someone that's going to review your branch
[10:01] <carlos> so you can merge it into rocketfuel soon
[10:02] <cprov> carlos: yes, it's the optimistic point of view 
[10:02] <carlos> ;-)
[10:04] <jordi> carlos: oh I see
[10:07] <SteveA> carlos, BjornT: we now have an imap account where all mail from staging goes
[10:08] <carlos> SteveA. stub: So can we enable all our cronscripts on staging?
[10:08] <BjornT> SteveA: cool. how do i access the account?
[10:09] <SteveA> kiko and i have the account details.
[10:09] <SteveA> we need to think about some rules for using the imap account
[10:09] <SteveA> because it would be confusing if people are deleting things etc.
[10:11] <BjornT> ok
[10:11] <SteveA> is there something you want to test on there right now?
[10:12] <BjornT> SteveA: no, not at the moment.
[10:27] <mpt__> cprov, what's the difference between "Edit Details" and "Administer Builder"?
[10:27] <mpt__> Can some people access "Edit Details" but not "Administer Builder"?
[10:28] <cprov> mpt__: Admin can set 'trusted'
[10:28] <mpt__> ok
[10:30] <cprov> mpt__: uhm currently only admin can tweak builderok and failnotes, in near future we will enable the owner to do this actin two
[10:34] <mpt__> cprov, so that's part of bug 32247 too
[10:34] <Ubugtu> malone bug 32247 in launchpad-buildd "Build machine details, mode, and trustedness should be edited on the same page" [Normal,Unconfirmed]  http://launchpad.net/bugs/32247
[10:35] <cprov> mpt__: sure, I'll also add this comment.
[10:35] <cprov> sorry, s\two\too , I'm broken 
[10:36] <mpt__> If you mean update the bug to include trustedness, I already did that :-)
[10:37] <cprov> mpt__: yup
[10:38] <stub> carlos: nope. We still can't enable zopeless scripts that send email until sendmail.py is hacked to make zopeless email get redirected too when the relevant options are set.
[10:39] <carlos> stub: is anyone working on it or at least, do we have  a plan to fix that?
[10:40] <cprov> stub:  could you stop aide in mawson ?
[10:40] <mpt> These Launchpad forms are depressing
[10:40] <stub> carlos: I don't think anyone is working on it. There isn't much involved - just someone needs to add an option to launchpad.conf for zopeless email redirection and add in the code that checks for it and changes the To: headers appropriately.
[10:41] <stub> cprov: nope - beyond my power. 
[10:41] <carlos> SteveA: could we get someone from the infrastructure team to work on it?
[10:42] <cprov> stub: does it usually take so long ? 40 min and queuebuild 1h20, they are fighting for I/O
[10:42] <SteveA> carlos: i'm not here... got hard disk problems
[10:42] <carlos> SteveA: ok
[10:42] <carlos> SteveA: good luck...
[10:43] <stub> cprov: it is some sort of intrusion detection thing - I think it scans the entire filesystem
[10:44] <cprov> stub: yes, I've read about it ... odd
[10:44] <stub> cprov: Znarl or elmo might be able to kill it - I don't know if that would screw them or not.
[10:45] <cprov> ehe -> Znarl <AUTO-REPLY> :  is away: (Having dinner) [BX-MsgLog On] 
[10:46] <stub> cprov: It is getting late to do the rollout, as there is a LUG meeting I want to get to. Will it cause you any grief if we do the rollout tomorrow?
[10:46] <cprov> stub: do it, I'll stop scripts in drescher 
[10:47] <stub> now? ok.
[10:48] <stub> Launchpad will be going down in 15 mins. Estimated downtime is 10 minutes. Wikis will be in read only mode during this period.
[10:50] <ddaa> Thinking that...
[10:50] <ddaa> There should be a site-wide banner when Launhpad is "under maintenance", with the expect time where service will resume.
[10:51] <stub> There is an rt issue open about getting a better 'down for maintenance' page installed. The one we have is rather broken (which you can see in 15 mins time)
[10:51] <ddaa> bah, there's one, it looks like :)
[10:51] <SteveA> right.  the down for maintenance page could simply have a link to a wiki page
[10:52] <SteveA> that stub can add an estimate of downtime and any other messages to
[10:56] <stub> That stub could also be using the browser notifications api to get pretty markup
[11:02] <stub> We shouldn't say 'in a minute' when we mean 'in one minute', as the former has multiple meanings
[11:05] <mpt> stub, yes, :approximateduration is mostly being used in ways different from what I imagined
[11:05] <mpt> so it needs to use digits more often
[11:09] <stub> launchpad is back
[11:09] <stub> cprov: renable your toys or whatever you need to do
[11:09] <cprov> stub: ok
[11:16] <daf> stub: have we done anything to tackle "RequestExpired: SELECT name FROM SourcePackageName WHERE id = $INT"?
[11:17] <daf> stub: or is it just one of those contention problems?
[11:17] <stub> daf: The only cases I'm aware of that happening are the pages that issue stooopid numbers of requests, and the first stage in fixing them is to add batching to them.
[11:17] <daf> oh, right, it's +allpackages
[11:18] <stub> Yup. Someone who knows the batching API could fix that in 5 minutes, plus test fallout and bzr time (so a day :-) )
[11:18] <ddaa> duh... I have this cscvs patch... I could not merge before because of multi-layered breakage (broken by buildbot, that was broken by pqm, and so on)
[11:18] <ddaa> And do not remember who reviewed it...
[11:19] <ddaa> bah, I guess it was rs=kiko or something like that
[11:21] <daf> stub: heh :)
[11:22] <stub> I'm off to a LUG - phone or SMS will get me.
[11:25] <Kamion> queue is totally fucked following the launchpad update
[11:25] <Kamion> lp_archive@drescher:/tmp/cjwatson$ queue info \*
[11:25] <Kamion> [...] 
[11:25] <Kamion>   File "/srv/launchpad.net/codelines/soyuz-production_20060221/scripts/ftpmaster-tools/../../lib/canonical/launchpad/interfaces/__init__.py", line 35, in ?
[11:25] <Kamion>     from canonical.launchpad.interfaces.build import *
[11:25] <Kamion> ImportError: No module named build
[11:25] <Kamion> are there any tests at all for queue?
[11:29] <daf> that's something that would break all of Launchpad, not just the queue
[11:30] <cprov> Kamion: there is, i'm moving trees atm
[11:30] <Kamion> ok
[11:31] <mpt> Hurrah
[11:31] <mpt> Now to fix a gazillion pagetests
[11:31] <daf> go mpt!
[11:32] <mpt> and figure out why the heck we have bug-removecve.pt and cve-removebug.pt
[11:32] <daf> nice
[11:33] <ddaa> hehehe, because two people disagreed?
[11:35] <mpt> They have exactly the same text
[11:35] <mpt> They differ only in choice of portlets
[11:38] <mpt> Only 17 failures, rocking
[11:39] <mpt> they can wait until tomorrow
[11:48] <ddaa> modifying import to run baz2bzr estimate: 3 hours: figuring out what the hell the code means. 1 hour:  modifying it. 2 hours: manual testing. 1 day: recoving.
[11:48] <ddaa> * recovering
[11:49] <ddaa> sounds plausible... *writes that in the plan*
[11:49] <SteveA> jamesh: ping
[11:49] <dilys> Merge to devel/launchpad/: [r=spiv]  first part fo BugWatches. Disable reporting bugs on products/distribution not using Malone. Make it possible to add a bug watch when requesting a fix. (r3174: Bjorn Tillenius)
[11:51] <mpt> SteveA, please try to review SimplifyingMalone soon
[12:01] <SteveA> mpt: done
[12:26] <lifeless> SteveA: could you do me a small favour ?
[12:27] <SteveA> lifeless: what's up?
[12:27] <lifeless> just need to allocate out the reviews to reviewers
[12:28] <lifeless> I haven't gotten to it today, and am very tired
[12:29] <SteveA> lifeless: you want me to do the allocation?
[12:29] <lifeless> SteveA: please
[12:29] <SteveA> ok
[12:29] <lifeless> thanks
[12:29] <Seveas> ugh, subscribing someone else to a bug still times out :/ 
[12:30] <Seveas> is there another way to acheive the same result?
[12:30] <SteveA> BjornT: do you know whether subscribing someone to a bug re-renders the page as well as redirecting?
[12:31] <Seveas> oh and minor 'buglet': the e-mail address on the oops page is system-error@launchpad.ubuntu.vom, shouldn't that be @launchpad.net?
[12:33] <BjornT> SteveA: i think it re-renders the page, but i'm not quite sure.
[12:34] <SteveA> BjornT: if you have time to do it, it would be a quick and simple improvement.  There is already redirection code like this used for the +translate page.
[12:36] <BjornT> SteveA: yeah, should be quick to do. i think i'll have time to do it today.
[12:36] <SteveA> great
[12:36] <daf> bug #31641
[12:36] <Ubugtu> malone bug 31641 in malone "+editstatus page should not render page on post" [Normal,Unconfirmed]  http://launchpad.net/bugs/31641
[12:37] <BjornT> thanks daf, i'll fix that page as well
[12:37] <daf> doing that at the same time might be a good idea
[12:37] <daf> thanks
[12:38] <SteveA> Seveas: sorry, no other way to achieve the same result.  We'll have that operation improved very soon though
[12:44] <daf> bah
[12:44] <daf> looks like my router drops packets over 1460 bytes long
[12:45] <daf> that's why Launchpad wasn't working for me
[12:48] <lifeless> daf: adsl ?
[12:48] <daf> I'm on ADSL
[12:49] <daf> the router has a crappy IP implementation that doesn't know how to fragment stuff
[12:49] <lifeless> daf: probably a PMTUd blackhole at the ISP
[12:49] <lifeless> daf: nah, its an extremely common problem with ADSL and its caused by the ISP
[12:49] <daf> what's a PMTUd blackhole?
[12:50] <lifeless> path maximum transmission unit detection blackhole
[12:50] <lifeless> SteveA: I'm presuming there was an implied 'yes' there. If not, I'll do it tomorrow.
[12:50] <lifeless> daf: google is your friend on this
[12:50] <lifeless> night all
[12:50] <daf> night lifeless 
[12:50] <daf> anyhow, setting the MTU by hand works around it
[12:51] <lifeless> daf: yes, thats consistent
[12:51] <lifeless> daf: easy way to test is if you can telnet to the server (with stelnet) and then when you do a 'get' it locks up straight away
[12:52] <lifeless> that means that the servers large packet is not reaching you
[12:52] <daf> funny thing is, doing a GET with openssl s_client worked
[12:52] <daf> so I thought it was Epiphany/Firefox being crap
[12:52] <lifeless> and the cause for that in your setup is the servers pmtud attempt not succeeding - the large packet never gets to your router.
[12:52] <SteveA> lifeless: done it already
[12:52] <lifeless> SteveA: legend. thanks
[12:53] <lifeless> ok, I'm really gone
[12:53] <lifeless> zzz
 Seveas: sorry, no other way to achieve the same result.  We'll have that operation improved very soon though <-- au contraire mon ami: the mail interface works ;)
[12:58] <SteveA> Seveas: nice one!
[01:05] <matsubara> good morning!
[01:06] <Kamion> has soyuz been restarted following this morning's update?
[01:06] <Kamion> the contents of the accepted queue are suspiciously old
[01:07] <daf> hi matsubara 
[01:07] <matsubara> hey daf, how are you doing?
[01:07] <daf> fine thanks
[01:07] <daf> how are you?
[01:08] <matsubara> fine too. :)
[01:08] <daf> good to hear it
[01:08] <daf> stub: any news on bug 31479?
[01:08] <Ubugtu> malone bug 31479 in launchpad "Retry exceptions should include information about the original query" [Normal,Confirmed]  http://launchpad.net/bugs/31479
[01:36] <jbailey> Hmm, https://launchpad.net/distros/ubuntu is OOPSing.
[01:37] <jbailey> So is https://launchpad.net/products/launchpad
[01:37] <jbailey> This might now fall under the category of "prevents me from reporting a bug"
[01:38] <daf> jbailey: https://launchpad.net/products/launchpad/+filebug :)
[01:38] <daf> that's really bad, though
[01:38] <jbailey> daf: Thanks.  I've never bothered to learn the URIs for those.
[01:38] <daf> it's top of my browser's "frequently used URLs" list :)
[01:38] <daf> it's the "latest tickets" portlet at fault
[01:39] <daf> I'm surprised tests didn't catch this
[01:39] <SteveA> stub: ping
[01:39] <SteveA> daf: it could be a database patch is missing or something like that
[01:39] <SteveA> it indicates that a dbschema is not up to date with the state of tables
[01:39] <daf> I see
[01:39] <SteveA> jbailey: thanks for reporting this here.
[01:41] <jbailey> Now filed as bug 32290
[01:41] <Ubugtu> malone bug 32290 in launchpad "product and distro pages seem broken" [Critical,Unconfirmed]  http://launchpad.net/bugs/32290
[01:41] <jbailey> Ubugtu: Thanks.
[01:43] <jbailey> daf: Yeah, I keep thinking I ought to bookmark the dozen or so URLs that I wind up using often.  Or setting up ephy smart bookmarks for products and whatnot.
[01:45] <salgado> lifeless, around?
[01:46] <daf> salgado: he went to bed
[01:46] <SteveA> jbailey: fixed now
[01:47] <SteveA> daf, jbailey: stub talked me through what to do.  he had missed applying a database patch along with today's rollout.
[01:47] <jbailey> SteveA: confirmed.
[01:47] <jbailey> Thanks for pouncing on it.
[01:47] <daf> thanks Steve
[01:48] <SteveA> daf, jbailey: do you recall an OOPS you got from the page when it was failing?
[01:48] <SteveA> oh, 32290
[01:48] <SteveA> i'll fix it
[01:48] <jbailey> SteveA: It's in the bug report.  I posted three of them.
[01:49] <daf> OOPS-52B290
[01:49] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/52B290
[01:49] <daf> OOPS-52A327
[01:49] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/52A327
[01:49] <jbailey> daf: Is that just for being too lazy to type in a URL?
[01:49] <jbailey> daf: smart bookmarks really are your friend.. =)
[01:49] <daf> ha
[01:50] <daf> no, those are the OOPSes I saw just now
[01:51] <SteveA> jbailey: if you get such an error again, that has such an effect, particularly just after a roll-out,
[01:51] <SteveA> if you don't get a response on irc, use the phone to someone like me, stu, kiko, or lifeless (depending on timezones)
[01:52] <jbailey> 'k.  I'm not sure who I would've contacted first.
[01:52] <SteveA> daf: same goes for you.  there are some times when we need faster action than filing a bug
[01:52] <daf> got it
[01:52] <jbailey> SteveA: Is it not worth filing a bug anyway so that you have the oops messages and such?
[01:53] <jbailey> SteveA: I'm thinking so that the phone call can be "critical fuckage - bug 32290, please help"
[01:53] <Ubugtu> malone bug 32290 in launchpad "product and distro pages seem broken" [Critical,Fix released]  http://launchpad.net/bugs/32290
[01:53] <SteveA> jbailey: for critical shit-hits-the-fan issues, you can call me or kiko.  If it is before 0500 UTC, try stu or lifeless
[01:53] <SteveA> jbailey: right, it is good to file the bug too
[01:54] <SteveA> maybe we need a "critical launchpad fuckage" page on the canonical wiki...
[01:54] <SteveA> needless to say, i'm talking about only *seriously* *critical* fuckage ;-)
[01:55] <jbailey> Right. =)
[01:55] <jbailey> Although, I'd probably consider inability to get to a link that's on the front page to qualify.
[01:55] <SteveA> you mean, if the front page works, but some link from it does not?
[01:56] <jbailey> Right, which this was.
[01:56] <SteveA> that in itself isn't critical
[01:56] <SteveA> it depends whether that link traversal is part of a workflow that is
[01:56] <SteveA> for example, filling a bug on ubuntu
[01:56] <SteveA> there is a "meetings" link on the front page.
[01:56] <SteveA> if that link doesn't work, so what...
[01:57] <SteveA> same for "calendar", right now
[01:59] <jbailey> Hmm
[01:59] <jbailey> I think I would've assumed that they'd be critical because they're first-class modules presentation-wise.
[01:59] <jbailey> They've been deemed important enough to show on the front page.
[02:00] <SteveA> our front page isn't very representative of what is important
[02:00] <BjornT> SteveA: is https://chinstrap.ubuntu.com/~dsilvers/paste/fileOjfz7U.html an acceptable solution? +addsubscriber doesn't use LaunchpadView, so it's not possible to re-use the exact same solution that was used for +translate
[02:00] <SteveA> i don't mind the occassional false-positive on the "shit has hit the fan" scale though
[02:00] <SteveA> in other words, i'd rather receive the call than not do so
[02:01] <SteveA> BjornT: could it easily be made to use LaunchpadView?
[02:01] <daf> BjornT: would it be difficult to convert to ...
[02:01] <jbailey> Unrelated soyuz question:  How do I find out what state a hoary-updates upload I did is in?
[02:01] <daf> SteveA read my mind
[02:02] <Kamion> jbailey: often you can ask me about that sort of thing; what's the package?
[02:02] <jbailey> Kamion: at
[02:02] <jbailey> Kamion: I thought that it might be tracked on the web UI
[02:02] <Kamion> jbailey: it's in hoary's unapproved queue waiting for approval by mdz or maybe me
[02:03] <SteveA> BjornT: it looks okay.  one thing...
[02:03] <Kamion> I don't think the queues are visible yet
[02:03] <jbailey> Kamion: Ah, okay.
[02:03] <jbailey> Kamion: I'll add it to my list of things to poke mdz about today, then.
[02:03] <jbailey> Kamion: Not urgent enough to break usual workflow on it.
[02:04] <Kamion> (we only barely *have* a workflow for -updates approval :-/)
[02:04] <Kamion> er, I didn't mean by that that the Soyuz tools are inadequate for approving -updates uploads, just that the approvers have been slacking on actually doing it
[02:04] <salgado> spiv, around?
[02:04] <SteveA> i'd check for request.response.status in (302, 303)
[02:05] <SteveA> BjornT: ^^^^ rather than the presence of the Location header
[02:05] <jbailey> Kamion: Right. =)  I guess what I'm wishing for is something where I can see what happened and forward to a customer a link where they can see the state themselves instead of polling me (I'm not sure that's actually the Right Thing, but in this case it came to mind)
[02:06] <jbailey> Kamion: For smalling updates where I'm backporting fixes, I'm going to try and be better about making sure the change gets uploaded to -updates.
[02:06] <jbailey> As well as timezone updates several times a year.
[02:08] <BjornT> SteveA, daf: well, it's possible to make it use LaunchpadView if LaunchpadView comes before SQLObjectAddview in the inheritance list. is that an ok solution, or is it better to override __call__ and explicitly call LaunchpadView.__call()?
[02:09] <SteveA> if it is an SQLObjectAddView then don't make it a LaunchpadView
[02:09] <SteveA> i'll look at combining those later
[02:09] <daf> LaunchpadAddView?
[02:09] <BjornT> SteveA: ok. i'll check the status instead of the presence of the header.
[02:09] <SteveA> after we have Zope3.2
[02:10] <SteveA> maybe the no-render-on-redirect change can go into SQLObjectAddView ?
[02:11] <BjornT> SteveA: yeah, i don't think it should cause any problems. i'll add it there and see if any tests break.
[02:11] <SteveA> could probably do the same for the EditView too
[02:12] <SteveA> it's a neat trick to look at the response like this.  it saves adding an API for redirecting.  well done bjorn.
[02:12] <SteveA> if it doesn't seriously break tests, we should see if stub can put this into production soon
[02:12] <SteveA> as it will save a lot of queries
[02:13] <SteveA> and make write-transactions use fewer queries
[02:13] <SteveA> which will cause less locking
[02:13] <daf> it's a simple change
[02:14] <SteveA> ddaa: got some estimates for me to look at?
[02:14] <ddaa> I msged you a link
[02:18] <daf> how do I run just one page test?
[02:18] <daf> python test.py -f foo.txt doesn't seem to work
[02:19] <salgado> daf, without the .txt IIRC
[02:19] <matsubara> daf: python test.py -f lib xx-test-name-without-txt
[02:19] <SteveA> daf: i think spiv said in the meeting
[02:19] <SteveA> and added it to the FaQ
[02:19] <daf> there's a https://wiki.launchpad.canonical.com/LaunchpadPageTests page
[02:21] <daf> https://chinstrap.ubuntu.com/~dsilvers/paste/fileRzPwiq.html
[02:21] <daf> that fails in an odd way
[02:22] <daf> it's looking for a file /home/daf/src/canonical/launchpad/allpackages-batch/lib/canonical/launchpad/allpackages-batch/lib/canonical/launchpad/pagetests/branches/xx-team-branches.txt
[02:22] <daf> there is a /home/daf/src/canonical/launchpad//home/daf/src/canonical/launchpad/allpackages-batch/lib/canonical/launchpad/allpackages-batch/lib/canonical/launchpad/pagetests/branches/xx-team-branches.txt
[02:22] <daf> er
[02:22] <spiv> daf: the xx-* page tests typically belong to standalone/
[02:23] <daf> indeed, so what's one doing in pagetests/branch?
[02:23] <spiv> That's what I'm wondering :)
[02:23] <daf> hum
[02:23] <daf> it probably works when all the tests are run together
[02:24] <daf> spiv: anyhow, can you add the "how to run a single page test" thing to LaunchpadPageTests?
[02:24] <spiv> Hmm, that seems buggy to me... files in a story depend on running in order, but the ordering of xx- vs. 01- isn't obvious.
[02:24] <daf> I'll add that page to the "developer documentation" list on the front page
[02:24] <spiv> daf: I updated LaunchpadHackingFAQ
[02:24] <spiv> daf: Which is where that information already lived.
[02:25] <daf> ok
[02:25] <salgado> spiv, do you have a second to talk about that MirrorManagement review?
[02:25] <spiv> daf: That page seems to be more about how to generate them, and some older (i.e. probably obsolete) information about how to hook them into the test suite...
[02:25] <daf> I see
[02:25] <daf> I'm trying to deprecate LaunchpadHackingFAQ in favour of smaller more specific pages
[02:26] <spiv> salgado: Depends on how short a second is ;)
[02:26] <spiv> salgado: sure
[02:26] <daf> spiv: if I remove xx-team-branches.txt, I get IOError: [Errno 2]  No such file or directory: '/home/daf/src/canonical/launchpad/allpackages-batch/lib/canonical/launchpad/allpackages-batch/lib/canonical/launchpad/pagetests/branches/01-branch-overview.txt'
[02:26] <daf> :)
[02:27] <spiv> daf: Well, if you want to rearrange the information in the wiki, I won't complain :)
[02:27] <salgado> spiv, let's say a not-so-short second. :)
[02:27] <salgado> spiv, I'll privmsg you
[02:27] <spiv> daf: I don't think I have time to do it myself right now, though.
[02:27] <daf> no worries
[02:28] <daf> can you reproduce this error?
[02:28] <spiv> daf: That's a bizarre looking error
[02:28] <daf> (command was "python test.py -f --test xx-distribution-all-packages")
[02:29] <daf> there's an extra 'launchpad/allpackages-batch' in the path
[02:30] <spiv> daf: I can't reproduce it.
[02:30] <daf> there's an extra 'launchpad/allpackages-batch/lib/canonical/launchpad' in the path, in fact
[02:30] <daf> odd
[02:30] <spiv> daf: and it runs fine for me with, e.g. python test.py -vvf test_pages
[02:34] <daf> SteveA: https://chinstrap.ubuntu.com/~dsilvers/paste/fileecFjwh.html
[02:34] <daf> SteveA: patch to batch the +allpackages page
[02:34] <daf> SteveA: can you review?
[02:39] <SteveA> daf: the test doesn't appear to show any sign that it is a batched page
[02:40] <daf> I should include some of the batch navigation HTML in the page test?
[02:41] <SteveA> is there only a single batch in the sample data?
[02:41] <daf> yes
[02:41] <SteveA> then i guess it is fine as it is.  
[02:42] <daf> I could include the "1 to 5 of 5" part
[02:43] <SteveA> ok
[02:44] <Kamion> can somebody look at https://launchpad.net/products/launchpad-upload-and-queue/+bug/32297 somewhat urgently? I don't know if cprov is still conscious
[02:44] <Ubugtu> malone bug 32297 in launchpad-upload-and-queue "'queue accept' is broken" [Normal,Unconfirmed]  
[02:44] <dooglus> so you guys know about a problem with attachments in malone?
[02:44] <dooglus> s/so/do/
[02:44] <daf> Kamion: looking
[02:45] <BjornT> dooglus: what kind of problem?
[02:45] <Kamion> thank you
[02:46] <dooglus> BjornT: look at the attachment I just added to https://launchpad.net/distros/ubuntu/+source/util-linux/+bug/29187
[02:46] <Ubugtu> malone bug 29187 in util-linux "/etc/init.d/umountroot doesn't umount root, resulting in possible data loss" [Major,Unconfirmed]  
[02:46] <dooglus> BjornT: called "patch to fix the problem"
[02:46] <daf> Kamion: I can't find the source code to thse tools
[02:46] <dooglus> BjornT: there's a double-quote in the link to it, and the link doesn't work
[02:48] <Kamion> daf: how can I help you?
[02:48] <Kamion> .bzr/parent in the relevant tree says /home/warthogs/archives/rocketfuel/launchpad/devel
[02:48] <daf> hmm
[02:49] <daf> I have a fresh copy of rocketfuel here
[02:49] <Kinnison> and it won't be in there
[02:50] <Kinnison> because this is the soyuz production tree
[02:50] <daf> and our production code isn't committed to the mainline :P
[02:50] <BjornT> dooglus: that's a new bug, didn't know about that one. could you please file a bug about it? (https://launchpad.net/products/malone/+filebug)
[02:51] <dooglus> BjornT: I just accidentally attached that patch to a completely unrelated bug.  Can I delete attachments?
[02:51] <dooglus> BjornT: and I'll report the new bug, yes.
[02:51] <daf> SteveA: are you happy with the patch?
[02:51] <BjornT> dooglus: thanks. no, you can't delete attachments yet.
[02:51] <Kinnison> daf: not yet no, it's a huge branch and is in desperate need of more review
[02:52] <daf> Kinnison: at any rate, can you help Kamion?
[02:53] <daf> (it seems a bit silly to have code reviews if we put stuff into production that hasn't been reviewed)
[02:53] <dooglus> BjornT: can you?  the last attachment in bug 31130 was a mistake
[02:53] <Ubugtu> malone bug 31130 in xboard "xboard crashes importing .pgn file with large annotations" [Normal,Unconfirmed]  http://launchpad.net/bugs/31130
[02:54] <Kinnison> daf: If there had been any way to get all the code reviewed before it had to hit production it would have been
[02:54] <Kinnison> daf: this bug has appeared since I stopped tracking the codeline
[02:54] <daf> I know, I'm just bitching
[02:54] <Kinnison> daf: Once cprov has recovered a little I'm sure he'll cope
[02:56] <BjornT> dooglus: no sorry, i can't do it either. only someone with direct db access can do it. it's probably better to leave it as it is
[02:56] <kiko> morning hackers of the world
[02:57] <kiko> daf, what bug are you bitching about?
[02:57] <daf> I couldn't help Kamion diagnose a bug because soyuz production code is not in RF
[02:58] <kiko> daf, well, where do I start. "there's this great feature of bzr called branches"? <wink>
[03:00] <daf> I don't know which branch is running on drescher
[03:00] <kiko> that we can help you with; there's a soyuz production branch cprov owns
[03:02] <dooglus> BjornT: I raised bug 32301 about that attachment problem.  It looks like I found out how I managed to break it, too.
[03:02] <Ubugtu> malone bug 32301 in malone "uploaded attachment isn't downloadable" [Normal,Unconfirmed]  http://launchpad.net/bugs/32301
[03:03] <Kamion> kiko: seems to be /home/warthogs/archives/cprov/launchpad/uploader-tests
[03:03] <Kamion> daf: er, meant that for you
[03:03] <daf> aha
[03:04] <cprov> here here 
[03:04] <daf> ah, cprov, you're still alive :)
[03:04] <cprov> trying
[03:04] <Kinnison> cprov: I've just added a comment to the bug kamion filed saying how I think it should be fixed
[03:04] <Kinnison> cprov: see what you think
[03:05] <Kinnison> https://launchpad.net/products/launchpad-upload-and-queue/+bug/32297
[03:05] <Ubugtu> malone bug 32297 in launchpad-upload-and-queue "'queue accept' is broken" [Normal,Unconfirmed]  
[03:05] <BjornT> dooglus: cool, thanks for the detailed bug report.
[03:06] <cprov> Kinnison: feasible, just fixing 
[03:11] <Kinnison> cprov: thanks, you'll let kamion know as soon as it hits drescher yes?
[03:11] <cprov> Kinnison: yup
[03:19] <kiko> stub, any cherry-picks?
[03:20] <carlos> see you tonight
[03:20] <carlos> cprov: do you need anything from me before I leave?
[03:21] <kiko> carlos, is your stuff in shape?
[03:21] <kiko> did SteveA look at your patch for 1681?
[03:21] <cprov> not really, will install pkgstriptrans in, let's say rothera and it will be producing translations  
[03:21] <carlos> kiko: SteveA is having problems with his Hard drive so he said is not available, not sure if he's now available
[03:21] <kiko> oh ffs
[03:22] <cprov> carlos: we can investigate the results together, tomorrow
[03:22] <SteveA> carlos: it's all fixed now
[03:22] <carlos> kiko: the packages for testing soyuz integration with Rosetta are ready
[03:22] <kiko> carlos, GIVE STEVE YOUR PATCH
[03:22] <carlos> cprov: ok
[03:22] <kiko> all-caps for added justice :)
[03:22] <carlos> kiko: I sent an email yesterday with the URL to the patch...
[03:22] <carlos> SteveA: do you have it?
[03:22] <kiko> carlos, it is YOUR burden to get it reviewed
[03:22] <SteveA> carlos: give it to me again
[03:23] <kiko> don't rely on him sifting through an inbox the size of mount klimanjaro
[03:23] <carlos> kiko: and PoMsgsetPage is near the end. I need to implement a couple of attributes and I will have it working with the limit of 5 entries per suggestions, so I think tonight I should have it done (don't think the tests will be done at that time...)
[03:23] <kiko> this is all good news
[03:23] <daf> SteveA: are you happy with my patch?
[03:24] <kiko> and also 
[03:24] <kiko> has production been updated?
[03:24] <carlos> SteveA: https://chinstrap.ubuntu.com/~dsilvers/paste/filepTZaIj.html
[03:24] <carlos> kiko: yes, it was
[03:24] <kiko> wonderful
[03:24] <daf> carlos: so PoMsgSetPage, #1681, and dapper imports are still all in the works?
[03:24] <carlos> #1681 is being reviewed
[03:25] <carlos> POMsgsetPage is near finished
[03:25] <carlos> dapper imports will be my focus tomorrow
[03:25] <daf> kiko was reviewing #1681, right?
[03:25] <carlos> well, and finish PoMsgSetPage testing
[03:25] <kiko> daf, I looked at it, but SteveA will be a better pick
[03:25] <carlos> daf: he did it, yes, but asked Steve to review it too
[03:26] <daf> ok
[03:26] <kiko> the code is tricky, perhaps SteveA has an idea on how to simplify it
[03:26] <daf> good idea
[03:26] <daf> Steve is good at that kind of thing
[03:26] <kiko> indeed. jamesh is too
[03:27] <carlos> anything else from you?
[03:27] <kiko> not from me
[03:27] <carlos> SteveA: ?
[03:30] <SteveA> carlos: wait!
[03:30] <carlos> SteveA: yes?
[03:30] <SteveA> carlos: what is the patch supposed to be for?
[03:30] <carlos> bug #1681
[03:30] <Ubugtu> malone bug 1681 in rosetta "Viewing a translation page fails in unix2newlines" [Major,In progress]  http://launchpad.net/bugs/1681
[03:30] <SteveA> okay, thanks
[03:30] <daf> SteveA: are you happy with my patch?
[03:30] <carlos> you are welcome
[03:30] <carlos> cheer
[03:31] <carlos> cheers
[03:31] <SteveA> daf: batching? yes
[03:31] <daf> SteveA: thanks
[03:33] <dooglus> BjornT: it turns out that that wasn't a Malone bug at all - it's a Firefox bug.
[03:34] <BjornT> dooglus: really, how so? i think malone should be able to handle it, though.
[03:34] <kiko> mpt, what do you think of a padlock for private bugs?
[03:35] <dilys> Merge to devel/launchpad/sourcecode/cscvs/: svn-1.2 compatibily, svn replaced file support [rs=kiko]  (r118: Colin Watson, David Allouche)
[03:35] <cprov> stub: ping, new production DB copy in dogfood looks like missing something queuebuilder queries took 207 min and didn't finished yet. Could you have a quick look when you get back ?
[03:37] <dooglus> BjornT: if you press control-y in any currently empty 'file' input type on a web form, then type the real path name, firefox doesn't upload the file contents.
[03:37] <dooglus> BjornT: so malone never gets to see the contents of my patch - firefox doesn't send it.
[03:37] <dooglus> BjornT: I've updated the bug report if you want to see details.  I made a real mess of the attachments again unfortunately.
[03:38] <daf> I agree with Bjorn, though: Malone should have handled it better
[03:39] <dooglus> daf: how can Malone possibly know that I didn't upload a file called "fix.patch containing a line about "content-type"?
[03:39] <dooglus> daf: that's what firefox told it I uploaded, and it believed firefox
[03:40] <dooglus> daf: malone could refused to accept files with an odd number of double quotes in their name, perhaps, but why limit it like that?
[03:41] <daf> I see -- it's not that the request was malformed
[03:42] <dooglus> I don't know the standard well enough to say.
[03:43] <daf> you could use something like ethereal to capture the request and paste it somewhere
[03:43] <dooglus> daf: I've uploaded it to malone
[03:43] <dooglus> daf: http://librarian.launchpad.net/1579888/output1.txt
[03:44] <BjornT> dooglus: i'll take a look at it later. to me it seems that firefox was sending an empty file. malone normally doesn't accept empty files, but in this case it thinks that the headers are part of the file. so i would still say it's a bug in malone (and maybe firefox as well)
[03:45] <dooglus> BjornT: I think that the " on a line of its own is marking the end of the headers to malone.
[03:46] <BjornT> dooglus: yeah it seems like, but i doubt that any standard says that " marks the end of the headers.
[03:49] <dooglus> BjornT: yes, ok.  so they're both broken - firefox shouldn't send ":" in the headers, and malone shouldn't accept it.
[03:50] <dooglus> BjornT: '"' I mean, not ":"
[04:02] <dilys> Merge to devel/launchpad/: [r=kiko,mpt]  demystify backport fixes vs. milestones by clarifying the 'Target Fix to Releases' link and page (r3175: Brad Bollenbach)
[04:02] <kiko> good work bradb 
[04:02] <bradb> thanks :)
[04:03] <bradb> jamesh: Any estimate for when you might have time to review the branches I put in your queue?
[04:04] <cprov> SteveA: do you indicate someone to review that quick fix in GPG system, bug 29937 ? before it gets old ;)
[04:04] <Ubugtu> malone bug 29937 in launchpad "Lies about which email address is being used during GPG verification" [Normal,In progress]  http://launchpad.net/bugs/29937
[04:06] <daf> salgado: did you file a bug for that people/+index problem we discussed?
[04:08] <salgado> daf, which one?
[04:09] <daf> I can't remember the details
[04:09] <daf> you were going to assign it to me
[04:09] <daf> local variable results being accessed before initialization comes to mind
[04:10] <salgado> daf, no, that's fixed already
[04:11] <daf> hmm, ok
[04:14] <kiko> daf, I am not sure I agree with your duping of bug 32018.
[04:14] <Ubugtu> malone bug 32018 in malone "No way to file bug against ubuntu.com?" [Normal,Unconfirmed]  http://launchpad.net/bugs/32018
[04:14] <daf> I don't remember seeing this bug before
[04:14] <daf> indeed, it was mpt who duped it
[04:15] <kiko> oh
[04:15] <kiko> can you verify, anyway? :-)
[04:15] <daf> hmm
[04:16] <daf> slightly different use cases
[04:16] <daf> 1. report bug in Ubuntu when you don't know which package it is
[04:16] <daf> 2. report a bug on the Ubuntu website
[04:16] <kiko> right.
[04:16] <kiko> I think they are not dupes.
[04:17] <daf> I don't know what the proper process for (2) would be
[04:17] <daf> either we'd have a website product
[04:17] <daf> or something totally different
[04:17] <daf> like a wiki page or an email address
[04:18] <daf> so I think (2) should be a matter of asking the website guys what they prefer, commenting on the bug, and rejecting it
[04:18] <daf> then again /distros/ubuntu/+{bugs,filebug} could do with information about what to do with bugs like this one
[04:19] <daf> custom bug page preamble text? :/ 
[04:21] <daf> kiko: what do you think?
[04:21] <daf> matsubara: oi
[04:21] <kiko> daf, not sure yet, I'll need to go back to the bug as I have context-switched but I want to do this pass on yesterday's bugs
[04:22] <daf> sure
[04:22] <kiko> BjornT, mpt: any news on FormLayout?
[04:24] <matsubara> daf: hey
[04:24] <daf> matsubara: let's have a QA meeting after you've had lunch
[04:24] <daf> matsubara: can you ping me?
[04:24] <matsubara> daf: sure
[04:24] <daf> cool
[04:28] <BjornT> kiko: last thing i heard, it doesn't work well with the current launchpad layout, so mpt has to do some changes first. i could start implementing it anyway, but currently i'm busy with other stuff, bug watches and support tracker.
[04:29] <kiko> BjornT, yeah, okay, just wanted an update.
[04:30] <kiko> BjornT, can you answer keybuk's question in #canonical? <Keybuk> is there any ...
[04:33] <kiko> BjornT, and if I may bother you further, check out why http://www.chiark.greenend.org.uk/~ijackson/d/t.txt was bounced?
[04:36] <BjornT> checking..
[04:36] <kiko> it appears iwj made a mistake but..
[04:38] <SteveA> daf: i copied you into a code review.  there's some stuff about text-processing functions that i'd like you to look at documenting
[04:38] <kiko> ddaa, do you have an oops number for bug 32117?
[04:38] <Ubugtu> malone bug 32117 in launchpad "ProductSeries.branch OOPS" [Normal,Confirmed]  http://launchpad.net/bugs/32117
[04:39] <daf> SteveA: noted
[04:39] <Keybuk> kiko: (in debian-devel mail)
[04:39] <Keybuk> This isn't a rant, but a serious wishlist request: if Canonical
[04:39] <Keybuk> wants more cooperation from Debian developers, please do not make
[04:39] <Keybuk> use go out of our ways, which means do not make use sign up with
[04:39] <Keybuk> launchpad (I realise many are already), and let us use an email
[04:39] <Keybuk> submissions service.
[04:39] <Keybuk> -- 
[04:40] <kiko> hey, emails submissions already work
[04:40] <kiko> email submissions too
[04:40] <Keybuk> only if you register though?
[04:41] <Keybuk> and does email submission of support tickets work?
[04:41] <kiko> yes, only if you register, right now.
[04:41] <BjornT> no, it doesn't work for support tickets
[04:42] <kiko> BjornT, didn't we just release that?
[04:42] <ddaa> kiko: not right now, it needs manual pocking in the database. There was a few oops on gnome-app-install because of that last week.
[04:42] <kiko> ddaa, mmm, I wonder if that's a dupe
[04:42] <kiko> daf, you duper!
[04:43] <ddaa> kiko: maybe it is, but it serves a purpose, since I need that fixed for the importd-bzr transition.
[04:43] <kiko> ok.
[04:43] <ddaa> and it might be a bit puzzling otherwise because there's no way to reproduce it short of doing manual sql ATM.
[04:43] <daf> kiko: hey, I'm supposed to keep the bug count down; what else am I going to do?
[04:44] <kiko> :-)
[04:44] <BjornT> kiko: you can send comments on existing support tickets, but you can't submit new ones. it was decided that it wasn't worth it until we found a way of making it easier.
[04:44] <daf> what are we talking about again?
[04:44] <kiko> BjornT, ah, okay.
[04:45] <kiko> Keybuk, so replying to support requests does, but not creating new ones
[04:45] <kiko> (BjornT, I find that rather odd)
[04:45] <ddaa> kiko: bah you drew me out of my nap... do we have a policy about afternoon naps yet?
[04:45] <Keybuk> that's ... kooky
[04:45] <Keybuk> ;)
[04:45] <daf> BjornT: do we have a bug open on https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-20/A218 and friends?
[04:46] <kiko> daf, that's a matsubara bug
[04:46] <kiko> ask him
[04:46] <BjornT> kiko: well, i did spec support for submitting tickets, but mark thought that we shouldn't do it.
[04:46] <daf> ah, found it
[04:46] <daf> bug #4845
[04:46] <Ubugtu> malone bug 4845 in malone "assigning of package bug targets needs input validation" [Normal,In progress]  http://launchpad.net/bugs/4845
[04:46] <kiko> BjornT, maybe you should sanity check these crazy ideas with us :)
[04:46] <kiko> ddaa, yes. you are allowed to have them, as long as you send me free dvds
[04:47] <daf> salgado: EmailAddressAlreadyTaken OOPS -- any bug for that?
[04:47] <ddaa> wow, that's harsh, you have no idea how expensive this stuff is in france!
[04:47] <kiko> salgado, yes, I believe
[04:48] <kiko> daf, err, yes, I believe -- isn't that bug 31755?
[04:48] <Ubugtu> malone bug 31755 in launchpad "Possible race condition when creating a new account could lead to an OOPS" [Normal,Unconfirmed]  http://launchpad.net/bugs/31755
[04:48] <daf> kiko: hmm, don't think so
[04:49] <daf> kiko: that one's a ProgrammingError, not an EmailAddressAlreadyTaken
[04:49] <daf> I bet salgado can tell us for sure
[04:49] <kiko> daf, I mean, I think that's the band-aid salgado added to tell us what's happening :)
[04:49] <daf> ah, right :)
[04:49] <Keybuk> kiko: I've had a little idea ... could I borrow your brain for a few minutes and see how crazy I am
[04:50] <daf> kiko: is he still on that monster review?
[04:50] <kiko> salgado, he's having lunch I think
[04:50] <BjornT> kiko: well, i kind of agree with him, people filing support requests would find the email command syntax hard. if we're going to do it, in think we should do something in the line with https://wiki.launchpad.canonical.com/CustomSubmitAddresses
[04:50] <Keybuk> BjornT: <package>@support.canonical.com
[04:51] <kiko> Keybuk, and non-Ubuntu? :-)
[04:51] <kiko> Keybuk, sure, try me
[04:51] <Keybuk> kiko: support@<other domain>
[04:51] <kiko> we wish :)
[04:51] <kiko> other domain is a big can of worms
[04:51] <Keybuk> kiko: one of the side effects of Gina is that it stores the source and binary packages in the Librarian, right?
[04:51] <kiko> Keybuk, both Gina and I believe existing Soyuz, rright.
[04:51] <Keybuk> so if we ran Gina against Debian every day, we'd have our own collection of source packages easily available
[04:52] <kiko> we would, yes.
[04:52] <kiko> we can start running Gina against debian
[04:52] <daf> not as big a can of worms as for web stuff
[04:52] <Keybuk> and as Ubuntu is run from Soyuz, we also have the source packages available in the Librarian too
[04:52] <kiko> I'd be happy to do that
[04:52] <Keybuk> right?
[04:52] <kiko> yes
[04:52] <Keybuk> could we do that then :)
[04:52] <Keybuk> because then I could use Launchpad itself as a source of sources for mom/nda
[04:52] <kiko> Keybuk, can you champion the idea on thursday?
[04:52] <kiko> I need to see what stub thinks
[04:52] <Keybuk> sure, I can be on the LP agenda if you like
[04:53] <kiko> yeah, add it as an agenda item
[04:53] <kiko> Kinnison and cprov need to tell me there will be no problem with Gina-imported packages on another distribution too
[04:53] <Keybuk> we'd need to do something to ensure Debian source packages were held on the Librarian until they were no longer the "Ubuntu base"
[04:53] <Keybuk> ok, can you agendify me then
[04:53] <kiko> hmmm
[04:53] <kiko> that is not so easy
[04:53] <kiko> that part
[04:53] <cprov> kiko: depends how confident you are about her ;)
[04:53] <kiko> the librarian GC kills kittens
[04:54] <Keybuk> how does the librarian GC decide whether a source is wanted or not?
[04:54] <kiko> there needs to be an alias linking to it
[04:54] <kiko> I guess it won't be if gina runs
[04:54] <cprov> soyuz won't mess with her data and possibly tolerates her weirdness well
[04:54] <kiko> because the *packagereleasefile table holds on to it
[04:54] <kiko> so Keybuk, it should be okay
[04:54] <kiko> the only qualm I have with the suggestion, actually
[04:55] <kiko> is that if we decide to make Ubuntu derive from Debian at some point in the future
[04:55] <kiko> well
[04:55] <Keybuk> ok, so it's just a matter of tweaking the publisher to not "remove" sources until it's safe
[04:55] <kiko> it may make things more complex
[04:55] <kiko> Keybuk, would you also want a published archive?
[04:55] <kiko> I wasn't considering that
[04:55] <Keybuk> don't really care about a published archive, tbh
[04:55] <kiko> then cool
[04:55] <kiko> makes things a lot easier
[04:56] <Keybuk> read-only access to a couple of tables from casey and http to the librarian would be the way I'd implement it
[04:56] <kiko> sounds easy
[05:01] <kiko> bradb, what of bug 30690?
[05:01] <Ubugtu> malone bug 30690 in malone "'Advanced...' button on bugs listing doesn't do anything" [Normal,Confirmed]  http://launchpad.net/bugs/30690
[05:02] <kiko> I didn't fix it because I thought I would conflict with you; is your browser/bugtask.py refactoring taking care of it?
[05:02] <bradb> kiko: I'm putting the advanced form back into my bug listing reports branch right now.
[05:03] <kiko> aha, okay.
[05:03] <kiko> can you make sure a) it gets done this week b) bug 30690 is fixed with it?
[05:03] <Ubugtu> malone bug 30690 in malone "'Advanced...' button on bugs listing doesn't do anything" [Normal,Confirmed]  http://launchpad.net/bugs/30690
[05:05] <bradb> Hm, the only way to ensure that it gets fixed this week (i.e. before Thursday) would be the $0.02 fix to the existing advanced search form, since I can't predict how long the code review process will take for the bug listings branch.
[05:05] <bradb> kiko: Should I do the [trivial]  fix then, for now?
[05:09] <kiko> bradb, why not?
[05:10] <kiko> bradb, the production branch is likely to be cut on friday or mon though..
[05:10] <bradb> The current form carries with it about as much hubris as a dried up banana peel, but I guess it's best to fix it, for now
[05:13] <kiko> when we kill the RHS portlets..
[05:13] <kiko> matsubara-lunch, salgado: OOPS-43A676 is long-fixed, right?
[05:13] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/43A676
[05:14] <salgado> kiko, yes
[05:14] <kiko> thanks.
[05:17] <kiko> daf, ping?
[05:17] <kiko> https://launchpad.net/products/launchpad/+bugs-advanced?field.searchtext=&orderby=-priority%2C-severity&advanced=1&field.assignee=&field.unassigned.used=&field.include_dupes.used=&field.status%3Alist=Fix+Committed&field.status-empty-marker=1&field.severity-empty-marker=1&field.attachmenttype-empty-marker=1&field.milestone-empty-marker=1&search=Search&field.milestone_assignment=&field.milestone_assignment-empty-marker=1
[05:17] <daf> yo
[05:17] <kiko> daf, can you go through that list, verify what is released, and mark it as fix released?
[05:18] <daf> ah, fix_committed
[05:18] <daf> aye
[05:18] <kiko> thanks
[05:18] <kiko> 28477 is not released, FTR
[05:19] <daf> right
[05:20] <daf> kiko: you're having PQM issues?
[05:22] <matsubara> hey daf, I'm back. QA meeting?
[05:22] <kiko> daf, I was, but no longer. why the question? the empty merges? it was stub's test bug he opened today
[05:27] <daf> kiko: because of #28477 -- so it's landed but not in production?
[05:28] <daf> matsubara: sure -- #cm?
[05:28] <kiko> daf, correct.
[05:28] <kiko> daf, suggestion for bug triage is, on the post-rollout day, try to go through fix committeds and verify that issue is fixed in production
[05:28] <kiko> so we have a post-release QA confirmation
[05:28] <matsubara> daf: ok
[05:29] <daf> kiko: yeah, sometimes I go through arch-commits mail to work out which fixes have rolled out
[05:29] <kiko> daf, best approach is really to use that query though
[05:29] <kiko> only rarely do people forget to mark fix committed
[05:29] <daf> at least, it will be once we've got all the really old stuff out of the way
[05:41] <SteveA> salgado: hello!
[05:42] <salgado> hi SteveA
[05:44] <SteveA> BjornT: ping
[05:44] <SteveA> salgado: c-m please
[05:45] <SteveA> salgado: actually, after the review meeting
[05:45] <salgado> SteveA, sure
[06:04] <Mez> grr @ changing how soyuz mails out ...
[06:04] <Mez> now I cant determine whether it's mine or it's for dapper-changes
[06:05] <Kamion> which mail exactly?
[06:06] <Kamion> there was a glitch this morning where some mails were sent to the uploader by accident instead of the announcement list
[06:22] <elmo> I'm losing my mind here - someone remind me how I convert an int to a string?
[06:22] <SteveA>  '%s' % 23
[06:22] <ddaa> str(23)
[06:22] <SteveA> str(23)
[06:22] <elmo> aha, str
[06:23] <SteveA> unicode(23)
[06:23] <elmo> I was trying string, and or string.string and getting all confused.  thank you
[06:23] <ddaa> chr(23) # <- that's a trick!
[06:23] <ddaa> elmo: too much C++
[06:29] <ddaa> I just realized how evil is the fact that one of the modules in cscvs is named "CVS"
[06:29] <matsubara> https://staging.ubuntu.com/products/launchpad is crashing on staging, is this a known fact?
[06:29] <ddaa> there's a bunch of tools around which ignore directories called CVS because they assume it's cvs control data...
[06:29] <matsubara> raising a KeyError
[06:30] <matsubara> daf: ^^
[06:56] <elmo> oh for christ's sakes
[06:56] <mruiz> hello! How I can delete an attachment after report a bug in LP? 
[06:59] <ddaa> mruiz: I do not think you can ATM. If it's important to delete the attachement, we can do it manually.
[06:59] <ddaa> elmo: something's making you unhappy?
[07:01] <mruiz> ddaa: the attachment is http://librarian.launchpad.net/1580347/ubuntu-server-error
[07:02] <ddaa> mruiz: I cannot delete it myself, bradb would know.
[07:03] <ddaa> mruiz: but I cannot see what's wrong with this attachement. Why not just let it be?
[07:03] <bradb> mruiz: If you can let it be, that would be good. If it's really urgent, we could probably find an admin to remove it today or tomorrow. It's a known issue.
[07:05] <Kamion> mruiz: just leave it alone, as the person who got that bug I don't care
[07:05] <Kamion> ddaa: (the content-type is wrong; there's another attachment on the same bug with the correct content-type)
[07:06] <mruiz> thanks Kamion
[07:07] <mruiz> Kamion: I few minutes I will attach the syslog that you need!
[07:07] <Kamion> thanks
[07:07] <RichART1> i wanna totally delete ubuntu; how does I do dat?>
[07:07] <RichART1> .ol
[07:07] <RichART1> lol
[07:08] <ddaa> bah, that was pointlessly hostile
[07:08] <mruiz> Kamion: do you need only syslog or hardware summary and messages also?
[07:09] <Kamion> mruiz: just syslog
[07:09] <mruiz> Kamion: ok
[07:10] <jblack> ddaa's heart grew not one, but three sizes that day
[07:14] <mruiz> Kamion: ok with syslog! it is online
[07:14] <Kamion> I'm subscribed to the bug, so you don't need to tell me, thanks :)
[07:14] <RichART1> does anyone kno how i might uninstall ubuntu?
[07:14] <mruiz> Kamion: ;-)
[07:15] <RichART1> its fekking up my lappy
[07:15] <Kamion> RichART1: the only way you can uninstall an operating system is by installing some other operating system over the top of it. I'd suggest looking for help with whatever other thing you want to install.
[07:15] <RichART1> thx Kamion
[07:16] <Kamion> but we would like bug reports about whatever is breaking, if you can
[07:16] <RichART1> i'll do just that bro
[07:17] <RichART1> well, i burn the .iso TWICE=once, 2 a scratched up cd-rw; & 2ndly to a new cd-r; NEITHER would install the other pkgs
[07:17] <RichART1> i mean, the base installed ok, but the rest of the pkgs......no
[07:18] <RichART1> and whilst booting (w/out the cd~from GRUB) the *name recognition or sth like dat FAILED
[07:19] <RichART1> that's pretty all the reports i have
[07:19] <dilys> Merge to devel/launchpad/: [trivial]  Use quoting=csv.QUOTE_ALL in the shipit export csv writer. (r3176: Guilherme Salgado)
[07:19] <bradb> RichART1: FWIW, you're more likely to find answers to your Ubuntu questions in #ubuntu.
[07:19] <RichART1> yah
[07:26] <elmo> man, it's been like two weeks and I've already forgotten all the LP incantations
[07:26] <elmo> I really didn't want to bzr merge from rf did I?  what should I have done?  pull?
[07:27] <bradb> elmo: I keep a local copy of launchpad:
[07:27] <bradb> rsync -avPHz --delete chinstrap:/home/warthogs/archives/rocketfuel-built/launchpad/ launchpad-upstream
[07:28] <bradb> And bzr merge that into my working tree.
[07:28] <elmo> bradb: that's what I'm trying to do
[07:28] <elmo> but I seem to have ended up with a tree that's diverged
[07:28] <elmo> and it's a bunch of changes I didn't make
[07:28] <elmo> so I'm very confused
[07:29] <bradb> elmo: What makes you think it diverged?
[07:30] <elmo>  ./lib/buildbot/test/test_config.py                                            |    5
[07:30] <elmo>  ./lib/buildbot/test/test_maildir.py                                           |    1
[07:30] <elmo>  ./lib/buildbot/test/test_process.py                                           |    3
[07:30] <elmo> etc.
[07:30] <elmo> (when I diff -x .bzr the two trees)
[07:31] <bradb> elmo: What about when you do something like:
[07:31] <bradb> bradb@oxygen:~/canonical/malone-smallfixes $ bzr diff -r ancestor:../launchpad-upstream/
[07:31] <elmo> oh!
[07:31] <elmo> this is the crack where stuff in sourcecode is not being merged
[07:32] <elmo> because it's a separate module or somesuch
[07:32] <bradb> yeah, a separate subtree
[07:32] <bradb> you have to manually rsync those dirs over into the right places in your working dir
[07:32] <elmo> or just recursively bzr merge presumably?
[07:33] <bradb> elmo: You needn't merge those subtrees, because you're (presumably) not making any changes in them. Unless you are.
[07:33] <elmo> well except the tests won't run without some of them  :)
[07:33] <bradb> (And merging takes longer.)
[07:33] <elmo> oh, I see what you mean
[07:34] <ddaa> elmo: that diffstat looks like the fixage required for twisted2...
[07:36] <ddaa> here, I have a few scripts like "nested-status", "nested-pull", and "nested-missing" that I use to update my lauchpad tree.
[07:46] <elmo> ok, so I did bradb's rsync trick, but now bzr st is whining at me about sourcecode/pyme being unknown, should I just bzr add it, or ignore it?
[07:46] <ddaa> you can ignore it, but you can also just remove it
[07:46] <ddaa> ignore as in "ignore the whining"
[07:47] <ddaa> it's replaced by pygpgme now
[07:47] <ddaa> something about hopeless third party code, I think :)
[07:49] <daf> matsubara: we had the same problem on production this morning
[07:49] <daf> matsubara: it was related to a missing DB patch
[07:50] <matsubara> daf: ok, thanks.
[08:05] <elmo> what port am I meant to use with 'make run'?  8085?
[08:06] <gneuman> 8086
[08:07] <kiko> elmo, it says so at the end of the initial output of make run
[08:07] <elmo> kiko: it lists 4 ports dude
[08:07] <kiko> right
[08:07] <kiko> 8086 is the "normal" port
[08:08] <kiko> 8089 is the post-mortem debugger
[08:08] <kiko> there are others, the name are more or less suggestive
[08:08] <elmo> ok, so it is just breaking horrible for me
[08:09] <elmo> ProgrammingError: ERROR:  column "official_malone" does not exist
[08:09] <elmo> I'm getting that on an unmodified tree
[08:10] <salgado> elmo, you need to update your database schema: make schema
[08:10] <elmo> blah
[08:10] <kiko> right.
[08:10] <elmo> why on earth don't we force that through Make dependencies
[08:10] <kiko> salgado, how bad was the shipit bustage?
[08:11] <salgado> no bustage at all
[08:11] <kiko> salgado, no? SteveA was all agitated about the wreckage in csvs!
[08:11] <kiko> elmo, I guess we could check the patch level and issue an update if you are out of date. how does that sound?
[08:11] <salgado> elmo, because rebuilding the database every time you want to run launchpad is not feasible
[08:11] <kiko> salgado, we could check, though.
[08:12] <elmo> salgado: not everytime you run it, everytime there's a new patch for the SQL
[08:12] <elmo> anyway, it doesn't matter it may not even be feasible, I'm just frustrated by how long this trivial change is taking
[08:12] <kiko> elmo, keep your trees up to date, I guess
[08:12] <elmo> kiko: that doesn't help
[08:13] <kiko> I know, but it's the truth.
[08:13] <elmo> no, it's not
[08:13] <kiko> well, from my experience, when I keep my trees up to date, it is relatively easy to do trivial fixes
[08:13] <salgado> kiko, apparently the csv files break with the default import options of dapper's OOo
[08:13] <kiko> when I let them lag I get all flustered at the slow bzr merge, busted dependencies, etc
[08:14] <kiko> salgado, I see. and QUOTE_ALL is da bomb?
[08:14] <salgado> kiko, although it's not a big deal, my last merge should fix that, 
[08:15] <elmo> kiko: please review http://people.ubuntu.com/~james/x/diff-001.txt (which verges on trivial)
[08:15] <bradb> dear god is it ever annoying that the test runner is b0rked
[08:15] <kiko> bradb, borked?
[08:15] <kiko> elmo, looks okay. remind me why we want to remove that?
[08:15] <bradb> kiko: It appears to fail to run individual tests since that story crap landed.
[08:15] <kiko> no
[08:15] <elmo> kiko: because it's an internal implementation detail which 99.999999999% of users don't care about
[08:15] <kiko> it runs them fine, bradb 
[08:16] <bradb> kiko: no, it doesn't
[08:16] <bradb> e.g.
[08:16] <bradb> bradb@oxygen:~/canonical/malone-smallfixes $ python test.py -f --test=xx-distribution-bug-statistics-searches.txt
[08:16] <elmo> displaying it on every page that has the distrorelease portlet is crack
[08:16] <kiko> bradb, don't include .txt
[08:16] <bradb> that runs 0 test, and should run one
[08:16] <kiko> it works fine for me doing
[08:16] <kiko> python test.py -f xx-distribution-bug-statistics-searches
[08:16] <kiko> err actually
[08:16] <kiko> python test.py -f . xx-distribution-bug-statistics-searches
[08:16] <matsubara> bradb: you could also use this syntax: python test.py -f lib xx-test-name-without-txt
[08:16] <kiko> that works fine.
[08:16] <kiko> thanks matsubara 
[08:16] <bradb> yeah, it's still borked though
[08:16] <bradb> the .txt used to work fine
[08:16] <kiko> stop complaining
[08:16] <kiko> it's less typing
[08:17] <bradb> more typing to delete .txt, actually
[08:17] <kiko> my god we can find reason to complain about the nitrogen concentration in the air
[08:17] <matsubara> bradb: spiv documented it on LaunchpadHackingFAQ
[08:18] <bradb> matsubara: It'd have been even better if it just weren't broken. :)
[08:19] <kiko> I think that instead of being broken, the syntax changed.
[08:21] <kiko> daf, did you manage to look at the committed bugs list?
[08:22] <matsubara> bradb, kiko: one interesting is that the syntax for doctests still apply. If I do: $ python test.py -f --test=some-doc-test.txt, it works.
[08:22] <kiko> it only breaks for pagetests, then?
[08:22] <matsubara> kiko: yep
[08:24] <bradb> indeed
[08:24] <daf> kiko: working on it now
[08:25] <kiko> thanks daf
[08:26] <kiko> matsubara, file a bug, I guess. I'll have spiv fix it
[08:28] <matsubara> kiko: Do you think it's a bug? They just have different syntax. It's all explained on the LaunchpadHackingFAQ
[08:28] <kiko> matsubara, well... I'm not sure. why should pagetests have a different syntax from doctests?
[08:29] <kiko> I mean, bradb is right to find the UI inconsistent
[08:29] <bradb> Also, if command $foo worked before, and doesn't anymore, I don't expect that I should go to the LaunchpadHackingFAQ to find out why this broke.
[08:30] <kiko> I wonder what your malone users say when you change the text "Target fix to releases" to "Backport...", bradb 
[08:30] <kiko> be reasonable
[08:31] <bradb> kiko: I think a better comparison would be if we changed the email syntax, and updated the doc. I think many would get very annoyed before thinking to check the email doc.
[08:31] <kiko> daf, are there any false fixes? i.e. stuff that is fix committed that wasn't really?
[08:31] <kiko> bradb, I think it's okay for you to report a bug. it is totally unacceptable for you to get "very annoyed".
[08:32] <daf> kiko: not that I've seen
[08:32] <daf> kiko: I'm being a bit trigger happy
[08:32] <kiko> daf, please test, I'd like to check for regressions. 
[08:32] <daf> kiko: and assuming that if I'm wrong the bug will get reopened
[08:32] <kiko> that's not the QA I asked you to do...
[08:32] <bradb> kiko: I wrote to the list about it, actually.
[08:33] <daf> kiko: well, I read the comments and tend to trust what people say
[08:34] <kiko> daf, let me be clearer, then
[08:34] <kiko> I am sure the people who wrote the comments are trustworthy
[08:34] <kiko> but that's not what post-commit QA is supposed to do
[08:34] <daf> you're saying the code might have regressed since the fix was committed
[08:34] <kiko> what I would like is a verification, in production (where possible) that the bug is fixed
[08:34] <kiko> I'm saying the person might think they fixed the bug, but might be mistaken
[08:34] <kiko> I've done it on occasion
[08:35] <kiko> you visit the link and boom, you fixed another case
[08:35] <kiko> or fixed something else
[08:35] <daf> ok, but in the case of "Anoying postgresql-8.0 WARNING", it's difficult for me to test that
[08:35] <kiko> well, right. I said "where possible". but some you can verify in your local tree.
[08:35] <kiko> (via a make run and sampledata)
[08:35] <kiko> for instance
[08:36] <daf> right
[08:36] <kiko> bug 903 is obviously released
[08:36] <kiko> bug 1512 might be, and might not be
[08:36] <Ubugtu> malone bug 1512 in launchpad "Admins creating products should be allowed to set owner and is_reviewed" [Normal,Fix released]  http://launchpad.net/bugs/1512
[08:36] <kiko> (I fixed it so I know it is)
[08:36] <kiko> (maybe)
[08:36] <kiko> :)
[08:37] <daf> if you fixed #903, please assign it to yourself
[08:37] <kiko> I didn't
[08:37] <kiko> but I fixed 1512
[08:37] <daf> ah, ok
[08:37] <kiko> 903 was lifeless + spiv
[08:38] <daf> right, for #1512, I'm not in the buttsource team, so I can't check if those fields are there
[08:38] <kiko> in your local tree you can
[08:38] <kiko> this is "work" in the sense it will require you to do the QA
[08:38] <daf> hmm, true
[08:38] <kiko> you may want to farm part or all of it out to Matsubara
[08:40] <dilys> Merge to devel/launchpad/: Fix https://launchpad.net/products/malone/+bug/4845 (assigning of package bug targets needs input validation) r=bjornt (r3177: Diogo Matsubara)
[08:40] <kiko> matsubara!
[08:40] <kiko> rock on!
[08:40] <matsubara> finally!!!!!
[08:40] <Keybuk> where's launchpad gone ?
[08:40] <daf> kiko: ok, so I'll mark the obviously fixed ones and revisit the more work-intensive ones later
[08:40] <kiko> Keybuk, alive for me
[08:41] <kiko> daf, thanks -- or farm it out to matsubara who is hired to do this work :)
[08:41] <Keybuk> taking ages and oopsing for mr
[08:41] <Keybuk> me
[08:41] <kiko> Keybuk, give me an oops
[08:44] <mruiz> hi someone know how are asigned karma points?
[08:46] <kiko> mruiz, good question. they are assigned automatically as you do various actions over launchpad -- report bugs, close bugs, translate, etc.
[08:47] <ddaa> give free dvds to kiko
[08:47] <mruiz> kiko: for example today I reported a bug and it was confirmed... where are my karma points? :)
[08:48] <irvin> kiko: do karma diminish over time?
[08:48] <kiko> mruiz, I think the karma updater is disabled right now, which may explain that. it is meant to be reenabled this week or the other. I'd need to confirm, though -- perhaps SteveA knows?
[08:48] <kiko> irvin, they do, though the algorithm to deduct karma was modified about a month ago.
[08:48] <Keybuk> kiko: OOPS-52C467
[08:48] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/52C467
[08:51] <irvin> kiko: could you please give me an example how karma deduction works?
[09:03] <kiko> ddaa, ping?
[09:03] <kiko> Keybuk, that's a known problem, and stub is supposed, growl!
[09:03] <kiko> irvin, not really -- I am not aware of how it works. salgado may know
[09:05] <irvin> kthx
[09:07] <ddaa> kiko: pong
[09:07] <kiko> ddaa, I have a question about https://launchpad.net/products/junkcode/+series/main
[09:07] <kiko> ddaa, I found the fact that it is syncing very interesting
[09:07] <kiko> however, I'm not sure how I can download that using baz
[09:07] <ddaa> yes you can
[09:07] <kiko> should it be more obvious?
[09:07] <mruiz> kiko: what will happen with the karma points that I win when the LP system is 
[09:07] <mruiz> kiko: what will happen with the karma points that I won when its system was offline?
[09:08] <ddaa> kiko: no it should not be more obvious, since baz is deprecated and baz branches are not represented in launchpad
[09:08] <kiko> mruiz, the points themselves are accumulated -- they are just not added up. don't worry, when the updater runs you will get them again.
[09:08] <mruiz> :)
[09:08] <ddaa> kiko: but I should certainly become obvious when there's a bzr branch published.
[09:08] <kiko> ddaa, aha. when bzr works then we'll just have links to the branch in launchpad. and it will be easy for me to find the URL for it. okay.
[09:09] <ddaa> kiko: well, that depends on how the bug you talked me about gets fixed
[09:09] <kiko> which one was that?
[09:09] <ddaa> ProductSeries.branch OOPS
[09:09] <kiko> ah, right.
[09:09] <ddaa> fixing it involves creating a branch view to use on the productseries page
[09:10] <kiko> I see.
[09:10] <ddaa> kiko: I'm out of work now
[09:10] <kiko> I didn't understand that comment.
[09:13] <ddaa> kiko: I mean my SO just came back so my attention is requested in meatspace :)
[09:13] <kiko> sure, enjoy
[09:13] <bradb> meatspace!?
[09:14] <bradb> oh, jargon
[09:16] <dilys> Merge to devel/launchpad/: [r=kiko]  Remove nominated independent architecture, which is meaningless, useless and confusing to users, from distrorelease portlet. (r3178: James Troup)
[09:16] <kiko> cool
[09:16] <kiko> go elmo 
[09:47] <dilys> Merge to devel/launchpad/: [trivial]  Fix bug 30690 ('Advanced...' button on bugs listing doesn't do anything) (r3179: Brad Bollenbach)
[09:48] <kiko> bradb!
[09:48] <kiko> rock on!
[09:48] <bradb> :)
[09:49] <kiko> that is music to my ears because I made that bug very apparent :)
[09:50] <bradb> by removing the URL, you mean?
[09:50] <bradb> er, link
[09:51] <bradb> that link was evil
[09:52] <kiko> yeah
[09:52] <kiko> it was evil
[09:52] <kiko> but we fucked them over :)
[09:52] <bradb> heh
[10:01] <kiko> bradb, <mdz> how can I see the bug contacts for a package?
[10:02] <bradb> kiko, mdz: bug 28823
[10:02] <Ubugtu> malone bug 28823 in malone "It's hard to figure out who the product/package/distribution bug contacts are" [Normal,Unconfirmed]  http://launchpad.net/bugs/28823
[10:03] <kiko> bradb, there's a portlet, you know?
[10:03] <bradb> yeah, I wrote it :)
[10:03] <kiko> heh
[10:03] <kiko> okay
[10:04] <kiko> what we're missing here however is a way for an admin to intervene and set these contacts up 
[10:04] <kiko> for instance
[10:04] <kiko> https://launchpad.net/distros/ubuntu/+source/xorg/+subscribe
[10:04] <kiko> daniels is out
[10:04] <kiko> and someone else is in
[10:04] <kiko> but mdz can't do the daniels is out part
[10:05] <bradb> right. also, +subscribe is the only page on which you can see the contacts, IIRC
[10:05] <kiko> bradb, is there a bug filed for that? is that the right approach?
[10:06] <bradb> kiko: bug 29022
[10:06] <Ubugtu> malone bug 29022 in malone "Should be able to subscribe others as package bug contacts" [Normal,Confirmed]  http://launchpad.net/bugs/29022
[10:07] <bradb> It's reasonable to allow a priviledged user (like a Malone Expert or admin) to subscribe/unsubscribe PBC's, I think.
[10:08] <kiko> indeed.
[10:08] <kiko> thanks bradb 
[10:08] <bradb> no prob
[10:25] <mpt_> Seveas, I changed the e-mail address on the error page to @launchpad.net a couple of days ago, but it missed this week's rollout
[10:31] <mpt_> BjornT, awake?
[10:32] <kiko> can someone comment on my proposal in https://launchpad.net/products/launchpad/+bug/2045
[10:33] <BjornT> mpt_: yeah, i'm awake
[10:35] <kiko> daf, ping?
[10:36] <mpt_> BjornT, hmmm, actually I need to rewrite the thing I'd like you to write the implementation section for ... I'll mail you once I'm done
[10:36] <mpt_> sorry, *I* wasn't entirely awake
[10:37] <kiko> matsubara, please update the description of bug 6313
[10:37] <Ubugtu> malone bug 6313 in launchpad "System error when changing password" [Normal,Confirmed]  http://launchpad.net/bugs/6313
[10:38] <mpt_> kiko, it's kilimanjaro :-)
[10:38] <kiko> mpt_, :-)
[10:38] <kiko> maybe that was a typo!
[10:38] <mpt_> not twice it wasn't
[10:39] <kiko> boring
[10:40] <mpt_> or as the cool kids call it, Aorangi
[10:43] <kiko> 2800 bugs to go
[10:43] <kiko> 700 down since monday
[10:45] <BjornT> kiko: re bug 2045, i would say only do exact matches, and remove that annoying select box, which i only ever seen disabled :)
[10:45] <kiko> :-)
[10:46] <BjornT> kiko: there might be another solution, though, just a minute, i'll have a quick look...
[10:47] <kiko> that sounds like fun!
[10:53] <mpt_> only ever seen disabled?
[10:55] <kiko> I didn't grasp that either
[10:57] <BjornT> mpt_, kiko: well, if the value you entered matches more than one item, the widget shows a small select box, where you can choose the right value. i've only seen that select box when some other field failed to validate.
[10:57] <mpt_> well, that would be a bug
[11:00] <mpt_> Heh, I was wondering what happens to that <select> if there are hundreds of possible choices, and the answer is that I don't see it, I get a timeout instead
[11:00] <BjornT> exactly, it's easy to limit the number of items though.
[11:01] <mpt_> yeah, the <select> should come before the text field, and its last item should be "Other:"
[11:02] <kiko> BjornT, we've discussed that..
[11:03] <mpt_> and limit it to 12 or so
[11:04] <kiko> do it
[11:17] <BjornT> kiko: i've added a comment to the bug, have a look at it. it's late though, so i might have missed something.
[11:17] <kiko> okay, thanks