[12:05] <carlos> no didn't file it ...
[12:08] <kiko> do it
[12:09] <carlos> kiko: https://launchpad.net/products/rosetta/+bug/37078
[12:09] <Ubugtu> Malone bug 37078 in rosetta "+admin page for IPOTemplate is not working for Rosetta experts" [Normal,Unconfirmed]  
[12:09] <kiko> rock on
[12:09] <carlos> is time to sleep...
[12:09] <carlos> kiko: anything else urgent?
[12:09] <kiko> nope
[12:09] <kiko> night
[12:10] <carlos> ok
[12:10] <carlos> good night
[05:29] <mpt> Goooooooooooooooood afternoon Launchpadders!
[05:30] <ajmitch__> hello mpt 
[06:06] <mpt> jamesh, ping
[06:06] <jamesh> mpt: pong
[06:06] <mpt> jamesh, I've tried fixing this problem myself, but I'm stuck
[06:07] <mpt> A branch that's a month old runs fine, but running any of the tests produces "ImportError: No module named _gpgme"
[06:07] <mpt> sourcecode/pygpgme exists and points at the right place
[06:07] <jamesh> okay
[06:07] <jamesh> does sourcecode/pygpgpme/gpgme/_gpgme.so exist?
[06:08] <mpt> bzr pull in lib/gpgme says "0 revision(s) pulled"
[06:08] <jamesh> lib/gpgme is a symlink to sourcecode/pygpgme/gpgme
[06:09] <mpt> No, gpgme/ does not contain _gpgme.so
[06:09] <mpt> 16:08:41@gpgme> ls
[06:09] <mpt> editutil.py  __init__.py  __init__.pyc  tests
[06:09] <jamesh> mpt: okay.  If you change to sourcecode/pygpgme and run "make", does it do anything?
[06:09] <mpt> yes, it does quite a lot
[06:10] <jamesh> running "make" in the toplevel launchpad directory should have caused pygpgme to build
[06:10] <mpt> I wonder make build didn't do any of that
[06:10] <mpt> wonder -> wonder why
[06:11] <mpt> ok, that works
[06:11] <mpt> thanks jamesh 
[06:11] <jamesh> mpt: does "pygpgme" appear in sourcecode/Makefile?
[06:12] <mpt> test_dirs:=buildbot  bzr cscvs  gnarly  pybaz  pygettextpo  pygpgme pytz  sqlobject  zope
[06:13] <jamesh> weird.
[06:13] <jamesh> it should have built then
[06:39] <spiv> jamesh: https://chinstrap.ubuntu.com/~dsilvers/paste/fileziaYlr.html
[06:40] <spiv> jamesh: Oh, and it also says: testSetOwnerTrust (canonical.launchpad.utilities.ftests.test_gpghandler.TestImportKeyRing) ... *** glibc detected *** double free or corruption (!prev): 0x0a1c04b0 ***
[06:40] <jamesh> hmm
[06:40] <spiv> jamesh: I've just got this 3 times in a row on a full make check, I haven't tried narrowing it down yet.
[06:40] <jamesh> I just turned that test on again last week
[06:42] <spiv> I have revno 46 of pygpgme.
[06:43] <spiv> Also, I'm using breezy still.
[06:44] <jamesh> is it repeatable?
[06:44] <jamesh> I suppose it would be :)
[06:45] <jamesh> spiv: would you be able to recompile gpgme with debug symbols?
[06:45] <spiv> jamesh: the deb package?  With appropriate instructions, I could :)
[06:46] <spiv> I play with deb source packages rarely enough that I never quite remember the incantations.
[06:47] <jamesh> "DEB_BUILD_OPTIONS=nostrp apt-get -b source gpgme1.0", I think
[06:48] <jamesh> nostrip, even
[06:48] <spiv> :)
[06:48] <spiv> I guess I'll have to re-add the src lines to my apt.sources
[06:52] <jamesh> also, if you have the python gdb macros installed, it would be useful to see pystack output too
[06:52] <spiv> I do.  I'll do that for you.
[06:53] <spiv> Hah.
[06:53] <spiv> https://chinstrap.ubuntu.com/~dsilvers/paste/filekKGYDZ.html
[06:53] <spiv> Not so helpful.
[06:53] <spiv> It's pretty clear from the C stack that it's in the garbage collection anyway.
[06:53] <jamesh> yeah
[06:56] <jamesh> I don't have any GC ob_trace/ob_clear routines for any of the objects, but I don't think they'd get involved in cycles
[06:59] <spiv> The callstack suggests that a frame was clearing a local of a security-proxied generator, which in turn had a frame holding your keyiter, which sounds sane.
[07:03] <jamesh> the iterator holds a reference to the context it is iterating over, which accounts for frames #9 and #10
[07:03] <jamesh> I guess it is a leaf in the cyclic GC graph
[07:22] <spiv> jamesh: https://chinstrap.ubuntu.com/~dsilvers/paste/file7PMrL0.html
[07:23] <jamesh> spiv: thanks
[07:27] <jamesh> bong
[07:27] <jamesh> spiv: I blame gpgme
[07:28] <jamesh> glibc is quite correct, and it is a double free
[07:29] <jamesh> spiv: the free(opd->tmp_uid); call in release_op_data() in keylist.c looks like a bug
[07:30] <spiv> jamesh: Want me to delete it, recompile, and try again?
[07:30] <jamesh> yeah
[07:30] <jamesh> make sure you delete the line before it (the if condition)
[07:31] <spiv> jamesh: Of course :)
[07:31] <spiv> My C isn't utterly rusty :)
[07:32] <jamesh> fucking gnats
[07:35] <stub> jamesh: file them in Malone of course o;)
[07:35] <stub> Or did you want someone to pay attention?
[07:37] <jamesh> stub: I suppose I could create a gpgme product and set it to officially use Malone for bug tracking
[07:38] <jamesh> that'd do it
[07:39] <jamesh> people complain about Malone, but they usually haven't used gnats
[07:41] <G0SUB> who uses gnats?
[07:41] <jamesh> G0SUB: gnupg
[07:42] <G0SUB> I see
[07:42] <jamesh> Automake did, last time I bothered filing a bug too
[07:43] <jamesh> spiv: I don't need to file a bug: it seems the problem has been corrected in gpgme 1.1.0
[07:43] <jamesh>   /* opd->tmp_uid is actually part of opd->tmp_key, so we do not need
[07:43] <jamesh>      to release it here.  */
[07:43] <jamesh> so upgrading to Dapper also fixes the problem.
[08:09] <stub> Do we have anyone maintaining launchpad-dependancies? The gpgme minimum revision should be updated, but the last few requests I've put in on that package via Malone don't seem to have gone to anyone.
[08:10] <jamesh> there are no initial bug contacts
[08:42] <lifeless> moin moin
[08:42] <lifeless> stub: what version should it be ?
[08:43] <stub> eh?
[08:43] <jamesh> lifeless: see launchpad list email
[08:44] <stub> oh
[08:44] <lifeless> jamesh: thats gonna take about 30 minutes.
[08:44] <stub> wot e said
[08:44] <lifeless> want to give me the short version ?
[08:46] <jamesh> lifeless: the gpg related segfault in the test suite is caused by a bug in the gpgme library
[08:46] <jamesh> lifeless: the problem has been fixed in the 1.1.0 release found in dapper though.
[08:46] <lifeless> jamesh - sure. what version does our dependency need to list
[08:47] <jamesh> I also posted the relevant patch to fix the bug in 1.0.x in case we want to stay with the old release on any boxes
[08:47] <lifeless> 1.1.0-1 is ok 
[08:47] <lifeless> ?
[08:47] <jamesh> upstream 1.1.0 is okay
[08:47] <jamesh> so any 1.1.0 package should be fine
[08:48] <lifeless> stub: is 8.0 still the right dep ?
[08:48] <lifeless> for pgsql
[08:48] <stub> Nope. 8.1.
[08:48] <stub> There are bugs filed on the package in Malone
[08:49] <lifeless> ok
[08:50] <lifeless> so, exuberant-ctags - I think thats ok to include
[08:50] <lifeless> agreed ?
[08:50] <stub> I haven't the foggiest ;)
[08:52] <stub> Bug 34279
[08:52] <Ubugtu> Malone bug 34279 in launchpad-dependencies "Upgrade to PostgreSQL 8.1" [Normal,Unconfirmed]  http://launchpad.net/bugs/34279
[08:52] <Znarl> stub : gangotri - 
[08:52] <Znarl> Launchpad Apps Server [1/2] 
[08:53] <stub> lifeless: Did you want to have a look at that? I need to head out for a few hours.
[08:53] <lifeless> stub: sure. did you do a rollout ?
[08:53] <stub> lifeless: Not yet today. Last rollout was Friday.
[08:53] <stub> Znarl: Ta.
[08:53] <lifeless> ok, leave it with moi
[08:56] <ajmitch__> something currently broken? pages taking awhile to timeout with a proxy error
[08:58] <lifeless> ajmitch__: looking into it
[09:01] <lifeless> stub: jamesh: I've mailed mdz a patch to the package.
[09:04] <lifeless> carlos: can I kill rosetta-poimport withuot harm ?
[09:08] <carlos> morning
[09:08] <carlos> lifeless: yes, it will resume its work next time it's executed
[09:11] <lifeless> thanks
[09:11] <lifeless> Znarl: should be good now
[09:13] <ajmitch> lifeless: thanks for kicking it :)
[09:13] <Znarl> lifeless : Thanks
[09:19] <ajmitch> hm, still seems to have some issues
[09:48] <lifeless> mpt DUDE. Its still borked.PLEASE PLEASE PLEASE run the test suite on your machine
[09:54] <mpt_> pqm, oh pqm, why do you hate thee
[09:55] <lifeless> mpt_: its you hating on it
[09:55] <lifeless> 17:48 < lifeless> mpt DUDE. Its still borked.PLEASE PLEASE PLEASE run the test suite on your machine
[09:57] <mpt_> lifeless, I just did, and the only failures are in importd
[09:57] <lifeless> did you run make check or make check_merge ?
[09:57] <mpt_> make check_merge
[09:57] <lifeless> ok. so this is now in the weird camp. have you pushed all your changes up ?
[09:57] <mpt_> yes, and last time I used --overwrite to be sure
[09:59] <mpt_> one pagetest was failing this morning, but I fixed that
[10:00] <lifeless> well you are getting MASSIVE failures running on pqm
[10:00] <lifeless> whats the branch, I"ll look at it on pending reviews
[10:00] <mpt_> mpt/launchpad/2006-02-headings
[10:00] <mpt_> I can see that the failures are massive from those five lines of <pre>
[10:00] <mpt_> It looks like every test's failing or something crazy
[10:01] <lifeless> thats about the size of it
[10:02] <mpt_> During make check_merge I also got errors in a couple of doctests like distribution.txt, but the test works fine when run by itself
[10:02] <lifeless> that means they will fail on pqm
[10:02] <mpt_> "Exception zope.app.rdb.interfaces.DatabaseException"
[10:03] <lifeless> if you have: 
[10:03] <mpt_> "Transation.__del__ of <sqlobject.dbconnection.Transaction object at 0xb2205a0c>> ignored"
[10:03] <lifeless>  * lp deps
[10:03] <lifeless>  * sourcecode/ up to date
[10:03] <lifeless> and do a make check_merge - any error will mean that a pqm submission will fail.
[10:05] <lifeless> how much did you miss ?
[10:05] <mpt> "... a pqm submission will fail."
[10:05] <lifeless> ok, you got it all
[10:06] <mpt> 0 revision(s) pulled.
[10:07] <lifeless> for f in $(find . -maxdepth 1 -type d); do cd $f && bzr pull && cd ..' done
[10:08] <mpt> oo, nifty
[10:08] <mpt> that ' is wrong, perhaps
[10:08] <lifeless> yes, its noise
[10:08] <lifeless> sorry
[10:09] <mpt> ; ?
[10:09] <mpt> yes, that works
[10:10] <mpt> or rather, it gives me 17 "No such file or directory" errors
[10:11] <lifeless> heh
[10:11] <lifeless> change the &&'s to ;'s
[10:11] <lifeless> it might be hitting an error early on.. oh
[10:11] <lifeless> add -mindepth 1 
[10:11] <lifeless> to the find
[10:12] <mpt> I should do this in my local rocketfuel copy, then cp -a it to this branch, perhaps
[10:12] <lifeless> you can just rm -rf sourceccode and copy the one from rocketfuel if you have not been editing in there
[10:12] <lifeless> that might be simpler
[10:15] <mpt> rsync -aP --delete chinstrap:/home/warthogs/archives/rocketfuel-built/ ~/hacking/lp/
[10:15] <mpt> That should be updating sourcecode/
[10:15] <lifeless> yes, it will include sourcecode in what it updates
[10:52] <mpt__> yow, productseries-source is unloved
[11:48] <jordi> kiko SLEEPS!!!?
[12:08] <mpt> aha!
[12:09] <mpt> An essential file is in my tree, but unversioned
[12:11] <mpt> If I bzr add it, I'll lose history
[12:12] <mpt> because I didn't write it
[12:20] <lifeless> mpt be with you in a sec
[12:21] <lifeless> well in 10minues
[12:45] <lifeless> mpt: ok
[12:45] <lifeless> mpt: whats the file ?
[12:49] <mpt> lifeless, lib/canonical/launchpad/templates/translationgroup-appoint.pt
[12:50] <mpt> I have no idea how it got unversioned, but like all the templates in this branch, I've made small changes in it
[12:51] <mpt> It didn't stand out because there are two other templates that (afaict) really are obsolete, but also hung around because I'd changed them
[12:54] <lifeless> bzr st shoul always be clean
[12:55] <lifeless> I dont have such a file
[12:56] <lifeless> translationgroup-portlet-relateds.pt  translationgroup.pt                   translationgroups.pt
[12:57] <mpt> mysteriouser and mysteriouser
[12:58] <mpt> because the error PQM gives me dozens of times is "ConfigurationError: ('No such file', '/home/pqm/arch/queue/workdir/home/---devel/launchpad/lib/canonical/launchpad/templates/translationgroup-appoint.pt')"
[12:58] <lifeless> you have a reference to that in a schema file probably
[12:58] <lifeless> bad merge resolution I'll bet
[12:58] <mpt> translationgroup.zcml
[12:58] <mpt> hrmmmmmm
[12:58] <lifeless> do this
[12:59] <mpt> diff and look what's different in that zcml file
[12:59] <lifeless> bzr diff -r branch:{pathtorocketfuellaunchpad} ../../../translationgroup.zcml
[12:59] <lifeless> adjust paths as needed
[01:00] <mpt> that's the badger
[01:01] <mpt> Looks like someone changed it to use a standard addform instead of a custom one
[01:01] <mpt> and deleted the custom one
[01:01] <mpt> which I still had
[01:01] <mpt> -ve
[01:03] <mpt> Thank you lifeless 
[01:24] <carlos> mpt: my branch does not have that template either, the apoint page uses launchpad-addform.pt (I was disconnected before I was able to send you that)
[01:27] <mpt> I guessed so, carlos, thanks
[01:40] <BjornT> stub: ping
[01:41] <stub> BjornT: pong
[01:43] <BjornT> stub: could you set lastchecked and remotestatus to NULL for all bug watches, and re-run checkwatches.py? a lot of bug watches won't sync the status with their bug tasks, since we do it only if remotestatus has changed.
[01:47] <stub> BjornT: running now
[01:47] <BjornT> thanks
[02:05] <matsubara> good morning!
[02:21] <carlos> matsubara: morning, how was Paris, did you enjoy it?
[02:25] <matsubara> carlos: yes. Wonderful city. 
[02:52] <kiko> morning guys
[02:52] <kiko> how's it going?
[02:55] <kbrooks> how do i attach a patch to a spec?
[02:58] <BjornT> kbrooks: it's not possible atm. it's planned to make it possible to link an implementation branch to a spec, though.
[02:59] <seb128> hi
[02:59] <seb128> bradb: default query should list "fix commited" bugs too
[03:00] <seb128> those are stuff still happening for users, not listing them make people just filing duplicates for those
[03:00] <BjornT> kbrooks: a branch is preferable over a patch, since a spec often requires a significant amount of work, so it's better to link a branch where you get some implementation history.
[03:00] <kiko> seb128, there's a bug filed on that already, right?
[03:01] <seb128> kiko: dunno, lemme try
[03:01] <seb128> I'm used to join that chan instead of using the bug tracker now :)
[03:01] <kiko> lazy!
[03:01] <seb128> no, get borred to be ignored for months every time I took the time to send a bug
[03:02] <seb128> and maybe a bit lazy yeah :)
[03:02] <kiko> it's okay to come to the channel, but having a bug number handy means I can keep an eye on it
[03:02] <kiko> so do both
[03:02] <seb128> https://launchpad.net/products/malone/+bug/28698
[03:02] <Ubugtu> Malone bug 28698 in malone ""Fix committed" bugs are treated as "resolved" bugs" [Normal,Confirmed]  
[03:04] <kiko> thanks seb128, I'll wave my hands a bit
[03:04] <kiko> seb128, do you have some time to talk about what happened to bug 3074 with me?
[03:04] <Ubugtu> Malone bug 3074 in eclipse "Eclipse fails to boot" [Unknown,Rejected]  http://launchpad.net/bugs/3074
[03:05] <seb128> kiko: sure, but I don't know about that bug
[03:05] <kiko> me neither but I stumbled upon it today
[03:05] <kiko> so that one is really interesting
[03:05] <kiko> BjornT, if you can look at it too
[03:05] <kiko> it seems that it was filed as an ubuntu bug
[03:05] <kiko> and then a watch was added /to it/ instead of to an upstream task
[03:06] <kiko> isn't that interesting use of the feature?
[03:06] <kiko> I wonder 
[03:06] <kiko> should we disallow attaching watches to tasks targetted to things that officially use malone?
[03:07] <kiko> what do you think seb128, BjornT?
[03:07] <seb128> kiko: I did a serie of such changes when we switched from bugzilla
[03:07] <kiko> seb128, what sort of changes?
[03:07] <seb128> "a watch was added /to it/ instead of to an upstream task"
[03:07] <BjornT> kiko: yes i think so. you should be able to link to an external bug tracker only by creating a new task.
[03:07] <seb128> I didn't get the point of the extra step of using a new task
[03:08] <kiko> seb128, question is, do you get the point now? :-)
[03:08] <seb128> I used the watch to send the distro task was the pending of upstream
[03:08] <seb128> yeah, I asked here about it and people told me bug were supposed to be syncing status on upstream
[03:09] <seb128> anyway so
[03:09] <seb128> I think we should not allow to use a watch on a task using malone as upstream tracker
[03:09] <kiko> okay
[03:10] <kiko> cool, that's what I wanted to know
[03:10] <kiko> if you concur then three's a party
[03:10] <kiko> BjornT, can you file a bug on that?
[03:10] <seb128> and we should not allow to open an upstream ask without specifying a valid bug number on upstream tracker
[03:10] <seb128> s/ask/task
[03:10] <seb128> because atm when you do that you get an upstream task stucked to unknow :p
[03:12] <kiko> yeah, that's a bit sucky
[03:12] <kiko> but that problem BjornT is well aware of
[03:12] <BjornT> kiko: it's listed as left to implement on https://wiki.launchpad.canonical.com/BugWatches, "Completely remove the possibility to add non-linked bug watches"
[03:13] <kiko> BjornT, hmmmm. I'm not sure I agree with that strategy completely
[03:13] <kiko> for one, it makes it harder for us to sniff bugwatches from comments, doesn't it?
[03:15] <BjornT> kiko: yeah, that's true. so maybe we shouldn't remove the possibility completely. but we should definitely remove the "Link to other bug tracker" link, since it's confusing.
[03:16] <kiko> that I can agree with
[03:18] <kiko> BjornT, which would mean, however, that you'd still need to restrict attaching watches to tasks that are targetted to malone-using creatures, right?
[03:20] <BjornT> kiko: atm you can't attach a bug watch to a task targetted to malone-using things. however, you can add an unlinked bug watch at the same time as creating a new malone-using task. i plan to remove that possibility though.
[03:20] <kiko> ah, ISWYM. and that bug is old.
[03:22] <BjornT> yeah. probably should have ran a migration script which would have unlinked all such bug watches...
[03:26] <kiko> not a big deal and actually, the information on the bug is useful
[03:54] <kiko> stub, any news on the rollout?
[03:54] <stub> kiko: I've been distracted
[03:54] <kiko> stub?
[03:54] <stub> kiko: Maybe I should get around to it ;)
[03:55] <kiko> that'd be nice :)
[04:00] <kiko> stub, BjornT: are you aware of the bustage on send-bug-notifications?
[04:02] <kiko> BjornT, also, reject bug 37111?
[04:02] <Ubugtu> Malone bug 37111 in malone "Post report comments should be emailed as Re:" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/37111
[04:03] <stub> kiko: Missing table... weird
[04:04] <kiko> stub, yeah, will email
[04:04] <stub> It worked when I ran it I thought
[04:06] <BjornT> kiko: i'm not sure if it should be rejected. i wouldn't mind if we used the subject of the relevant comment. again, i don't care either way, since mutt hides the subject line when the email is part of an thread.
[04:06] <stub> Ok... prepared a production branch of r3338 with cherry picks of r3348 and r3353. Running tests.
[04:06] <kiko> stub, rock on
[04:07] <kiko> BjornT, maybe add a trivial test for the send-bug-notifications script to catch this level of bustage?
[04:07] <kiko> BjornT, what is he asking for? In-Reply-To: instead of References:
[04:09] <stub> duh... I misread the cron report. just a missing security declaration in security.py. btw. - what user is that script connecting as?
[04:09] <BjornT> kiko: there are tests. i assume this happened because the patch wasn't applied on staging's database.
[04:09] <BjornT> stub: it's connecting as launchpad for now, i never got around creating a specific user for it. i have plans to do so though.
[04:09] <kiko> security problem it seems -- do the tests actually access the database, and if so, how is it breaking when running on production?
[04:10] <BjornT> kiko: he wants the subject line to begin with 'Re:'
[04:10] <stub> BjornT: Please do.
[04:10] <kiko> BjornT, I see. I don't know if I like that.
[04:12] <BjornT> kiko: well, preserving subjects for comments is a good idea. for pure change notifications, i think keeping the bug title as subject is ok.
[04:13] <kiko> right
[04:32] <stub> Hmm... got some test failures :-( supermirror test failures, all paramiko stuff I think
[04:32] <stub> And some interrupted system calls
[04:33] <stub> No paramiko installed on balleny :-P
[04:35] <kiko> stub, how surprising. how is she even running pqm?
[04:36] <stub> I don't know. I might need to setup some sort of special environment to run the tests - not sure.
[04:37] <kiko> this sucks
[04:48] <stub> So is paramiko  a launchpad dependency now? Or is bzr trying to locate paramiko because something else is failing?
[04:50] <carlos> stub: I think supermirror is using paramiko
[04:51] <carlos> stub: at least spiv fixed a problem I had with supermirror tests and paramiko
[04:51] <kiko> I believe it is a dependency, yes
[05:00] <stub> kiko: Who is responsible for maintaining the launchpad-dependencies package? lifeless?
[05:01] <kiko> isn't it orphaned, and meant to be picked up by someone?
[05:06] <lamont> hrm... if a bug is in "fix released", how do I reopen it?
[05:07] <bradb> lamont: Just change the status.
[05:08] <lamont> mouseover didn't make that a link...
[05:08] <stub> Still getting TacException: Unable to start /home/pqm/tests/launchpad/daemons/authserver.tac :-(
[05:09] <lamont> bradb: which leads directly to the question of "how the hell do I change the status?"
[05:09] <bradb> lamont: By clicking on the package name in the table.
[05:09] <bradb> Yeah, it's confusing.
[05:09] <lamont> ah, duh.  one of these days I'll intuit what it wants me to do.
[05:10] <bradb> mpt: ping
[05:12] <kiko> lamont, it hasn't essentially changed since malone was deployed, so...
[05:13] <lamont> kiko: yeah, so I have little hope.
[05:14] <lamont> but then, I'm used to seeing links on pages, rather than sweeping over the whole damn page looking for something that changes my cursor...  silly me.
[05:15] <kiko> it /is/ an underlined link, fwiw
[05:15] <kiko> and there is an arrow next to it
[05:15] <kiko> :)
[05:15] <kiko> and it is the row where the status is presented
[05:16] <bradb> kiko: but still, if it isn't blindingly obvious how to change the status of a bug in a bug tracking system, that's a pretty serious bug, IMHO
[05:17] <kiko> I might agree, but a) not all users of this bugtracker actually need to change the status (it is not a beginner's task, I don't think) b) I haven't seen a proposed alternative design that would make things better; have you?
[05:17] <bradb> I think it will be become blindingly obvious when the action for changing the status is somehow discoverable when looking at the status
[05:18] <bradb> kiko: yeah, i designed a prototype for the alternative, which you approved of
[05:18] <kiko> an (edit) link? 
[05:18] <kiko> (or what was the prototype?
[05:18] <bradb> the bug page prototype i put up on flickr
[05:20] <kiko> hmmm. hmmmm. url? :)
[05:20] <kiko> bradb, btw, had a chance to look at jamesh' project-bug-page?
[05:21] <bradb> not quite yet. a bit more work left on the security teams than anticipated. just finished the email changes.
[05:22] <bradb> doh, i'm suffering from passwordmanageritis, trying to get to my flickr account on another machine
[05:25] <bradb> kiko: http://flickr.com/photos/84096161@N00/88275619/ -- incidentally, i left out status on the page inadvertently, but mentioned that in the errata on IRC, i think
[05:28] <bradb> I was going to get you to take a look at the filebug and bug page changes I made too. Nothing too major, but hopefully an improvement.
[05:32] <bradb> kiko: http://69.70.209.33:8086/distros/ubuntu/+filebug and http://69.70.209.33:8086/products/firefox/+filebug
[05:33] <bradb> If you try different security/privacy settings, you can see what I've changed.
[05:38] <lamont> kiko: I guess part of it is because I've come to understand that underlining has no special significance on the web site, and hence tried to clik on the status to change it... since that seems to be how most things get done on LP...
[05:38] <lamont> click, even
[06:23] <lifeless> stub: its installed on chinstrap now
[06:23] <lifeless> stub: stub I'm giuessing I gort to mention balleny in my email ...
[06:34] <lamont> dear launchpad.  searching for "gtk+2.0-directfb" on https://launchpad.net/distros/ubuntu/ is borked. kthxbye
[06:50] <kiko-phone> carlos, how is the OOO import going?
[06:50] <carlos> kiko-phone: still importing files...
[06:50] <carlos> it's being slow
[06:50] <carlos> 3 files/hour
[06:51] <carlos> also, we detected a bug with the script that generates the .po files...
[06:51] <kiko-phone> is there an arabic version?
[06:52] <carlos> kiko-phone: no, I don't think so
[06:52] <kiko-phone> can you check?
[06:52] <carlos> 38 files pending to be imported... since yesterday...
[06:52] <carlos> kiko-phone: no arabic files there
[06:54] <kiko-phone> okay. mmmm.
[06:54] <kiko-phone> I just showed off some arabic rosetta 
[06:54] <kiko-phone> people said "wow it works"
[06:54] <kiko-phone> I said "of course"
[06:54] <kiko-phone> ;)
[06:54] <kiko-phone> makes it all sound easy
[06:55] <carlos> kiko-fud: ;-)
[06:55] <lifeless> kiko - whats this test failure you are reporting
[06:56] <carlos> kiko-fud: RTL language support was a good addition ;-)
[06:56] <kiko-fud> lifeless, it's a test failure that happens every time I submit something to pqm
[06:56] <lifeless> kiko-fud: when did it start happening ?
[06:56] <kiko-fud> carlos, this feature is going to get us the spotlight!
[06:56] <kiko-fud> lifeless, since I came back from london AFAICT
[06:56] <kiko-fud> it's only on the sftp tests, did you notice?
[06:56] <kiko-fud> 4 failures IIRC
[06:56] <lifeless> only change I know of in PQM is the installation of paramiko on chinstrap.
[06:57] <lifeless> here it goes
[06:57] <kiko-fud> were these tests not added recently?
[06:57] <lifeless> our favourite. stale processes
[06:57] <lifeless> killwill work now
[06:57] <kiko-fud> our launchpad processes are not super-speedy but they are far from stale
[06:58] <kiko-fud> killwill? is that some extreme sort of ill-will?
[06:58] <kiko-fud> as in "I think PQM has killwill towards our test suite"
[06:58] <lifeless> no, our testsuite has killwill towards itself
[06:58] <kiko-fud> lifeless, should I try and submit again?
[06:59] <lifeless> yes
[06:59] <kiko-fud> done!
[07:02] <lifeless> stub, kiko - launchpad-depndencies isn't 'owned' by anyone wright now
[07:02] <lifeless> I've sent a patch fort he open bugs to mdz
[07:03] <carlos> see you later
[07:10] <bradb> kiko-fud: I sent a review to jamesh 
[07:23] <dilys> Merge to devel/launchpad/: [trivial]  Fix milestone page which regressed when bug summaries were removed, adding a trivial check for it. Also move bugtracker and distroreleaselanguage pages to 2-col (r3358: kiko)
[07:34] <kiko> bradb, I <3 u
[07:35] <kiko> stub, news on the rollout?
[07:39] <kiko> stub, chance of cherry-picking 3358 while you are at it (super-trivial)?
[07:42] <kiko> lifeless, should I forward jamesh' gpgme mail to the admins' rt?
[07:42] <lifeless> no, requests are already in
[07:42] <kiko> really? for installing the dapper version?
[07:42] <lifeless> the launchpad-dependencies package is updated.
[07:42] <lifeless> yes.
[07:42] <kiko> I see
[07:42] <kiko> the package depends on the specific version?
[07:43] <kiko> it'd be nice if you CC:d the launchpad list when forwarding to rt
[07:43] <lifeless> I updated the package, mailed the diff to mdz and separately requested an install of the fixed gpgme via rt
[07:43] <kiko> that way we know the ticket was created without needing any OOB communication
[07:43] <lifeless> sure, I can do that.
[07:43] <mdz> lifeless: I already uploaded your changes
[07:43] <mdz> to dapper
[07:43] <kiko> mdz!
[07:43] <lifeless> mdz: yes, I know, I think I said thanks too :)
[07:43] <kiko> thanks lifeless 
[07:44] <lifeless> mdz: I was giving kiko the background I could tell he was itching to know
[07:44] <lifeless> kiko: no pros
[07:44] <lifeless> erm, probs.
[07:44] <kiko> no cons
[07:46] <lifeless> tchau tchau
[07:51] <Martolod> hello
[07:51] <Martolod> can i know when the package "language-pack-xx" will be updated for dapper ?
[07:54] <kiko> thanks for the review, bradb, well done
[07:54] <kiko> Martolod, "soon". it's pending carlos and pitti doing some handshaking and handwaving
[07:56] <Martolod> ok thank yo
[07:56] <Martolod> u
[08:11] <bradb> kiko: no prob :)
[08:17] <bradb> kiko: BTW, do you have time to look at those filebug URLs I mentioned earlier, to see the changes I made on the filebug and bug pages while doing the security teams work?
[08:54] <kiko> bradb, yes, I did. do you want feedback, or do you want to mptize them? :)
[08:58] <bradb> kiko: mainly interested in seeing if they're in good enough shape UI-wise to submit for review, etc. i'm sure some mpt love will be needed to give them that extra polish, etc.
[08:59] <kiko> well, just a "for instance":
[09:07] <kiko>  This bug should only be visible to people on the Cc list
[09:07] <kiko> "people on the CC list" is rather convoluted
[09:07] <kiko> maybe you meant
[09:07] <kiko> [ ]  This bug should only be visible to its explicit subscribers
[09:08] <bradb> kiko: How is "explicit subscribers" clearer than "Cc list"?
[09:09] <kiko> where in all of launchpad have you read the expression "Cc list"?
[09:09] <bradb> I'd imagine most users have no idea what explicit/implicit subscriptions mean.
[09:10] <bradb> Hm, I guess we don't actually use the term Cc anywhere.
[09:11] <bradb> So, maybe just "to its subscribers"?
[09:11] <kiko> sure, if you think that's better than explicit subscribers.
[09:12] <kiko> don't use the expression "Cc'd"
[09:12] <kiko> use subscribed
[09:12] <bradb> yeah. for some reason i assumed we were using Cc in some places, but grep says no.
[09:12] <kiko> Cc == computerspeak
[09:12] <kiko> it's frowned upon even by me
[09:14] <bradb> indeed
[09:14] <bradb> Any other things that I can touch up before getting it ready for review?
[09:15] <kiko> I am wondering whether you really want the package question to be the first thing on this form
[09:16] <kiko> another question
[09:16] <kiko> when you say it's a security issue shouldn't you set private by default?
[09:17] <bradb> kiko: You mean .js-wise?
[09:17] <kiko> yeah, I know, but yeah
[09:17] <kiko> or select and disable it
[09:17] <bradb> maybe. I'll double-check with the ubuntu devs, just in case.
[09:17] <mpt> kbrooks, you could attach your patch (or link to your branch) from the spec's wiki page itself :-)
[09:18] <mpt> that's what the Launchpad hackers do
[09:18] <kiko> mpt!
[09:20] <bradb> kiko: I think putting the package question after the desc seems reasonable. what do you guys think?
[09:20] <kiko> mpt, are you awake?
[09:20] <mpt> BjornT, I think sniffing bug watches from comments should take the form "Did you mean to...", in whicih case it can guide you to adding the task
[09:21] <mpt> BjornT, in other news, what is the From: header set to when mail notifications are grouped?
[09:22] <bradb> mpt: same as it is now
[09:23] <bradb> if person A makes a change, then person B makes a change, person B making a change will trigger an email getting sent about A's changes, then an email about B's changes
[09:23] <mpt> bradb, pong
[09:23] <bradb> mpt: lamont` couldn't figure out how to change the bug status today :/
[09:24] <mpt> lamont`, the bug page *will* be made obvious one day, I promise. Might not happen for a few months though.
[09:25] <mpt> kiko!
[09:25] <mpt> bradb, yeah, I saw
[09:25] <mpt> completely predictable
[09:26] <mpt> and utterly unnecessary
[09:26] <bradb> indeed
[09:27] <mpt> I did sneak in a wee bit of link underlining (!!)
[09:27] <bradb> on status?
[09:27] <mpt> on the product/package name
[09:27] <bradb> yeah
[09:27] <mpt> but by itself that's not enough
[09:31] <lamont`> mpt: once you figure out that it's monkey-mode (wave the mouse around until you find a link - since they're not underlined), the normal reaction is to simply ignore underlining, since it clearly can't mean that it's a link..
[09:32] <mpt> *sigh*
[09:32] <bradb> kiko: btw, I don't think js-selecting the private checkbox seems ok, but making it impossible to file a public security bug by disabling the widget may be overkill.
[09:32] <bradb> er, s/I don't think/I think/
[09:34] <mpt> lamont`, true, and even if I made them all underlined tomorrow, that low expectation would likely persist for a few weeks
[09:34] <mpt> (even if I *could* make them all underlined tomorrow)
[09:41] <kiko> stu1, stub: ping?
[09:41] <kiko> mpt, uhm, you have a lot of answering to do from the above -- hellp?
[09:41] <mpt> bradb, what's this about subscribers?
[09:41] <kiko> jeez, mpt, you're LAGGED
[09:42] <mpt> ah
[09:43] <mpt> bradb, being a security bug isn't the only reason for keeping a bug report private
[09:43] <kiko> correct
[09:43] <mpt> They're also sometimes kept private for marketing reasons
[09:43] <kiko> it may include revealing pictures!
[09:43] <mpt> I very much like the "I don't know" radiobutton, well done
[09:44] <bradb> thanks
[09:46] <bradb> I tweaked the bug page too, which you'll see if you play around with bug visibility and security
[09:46] <mpt> oh, there's two checkboxes!
[09:46] <mpt> security *and* privacy
[09:46] <mpt> hmm, so what does the first one do?
[09:46] <mpt> oh, is this implementing SecurityTeams?
[09:47] <bradb> yeah
[09:47] <mpt> What's the usefulness of checking the security box if there's no security contact?
[09:47] <kiko> mpt wakes up, imagine that
[09:47] <kiko> mpt, the bug gets marked as "security"
[09:47] <mpt> and...
[09:48] <mpt> we can filter those elsewhere?
[09:48] <bradb> i haven't added it to the search yet
[09:48] <bradb> but, of course, it'd be easy to do
[09:48] <kiko> but that's the idea
[09:48] <kiko> +bugs-security even if we wanted to some day
[09:48] <bradb> and in so doing make filebug harder to use! :P
[09:49] <mpt> hey, you started it :-P
[09:49] <mpt> anyway
[09:49] <mpt> The main change I'd make is putting the first three elements in reverse order
[09:50] <mpt> * In what package does the bug occur?
[09:50] <mpt> * Describe the bug for us:
[09:50] <mpt> * Now summarize that in a single line:
[09:51] <daq4th> * attach fix ;-)
[09:51] <kiko> mpt, the wording for the last item seems to invite saying "YOUR DISTRIBUTION SUCKSXXX!!@@@"
[09:51] <mpt> It does?
[09:51] <mpt> and "Summary" doesn't?
[09:51] <kiko> well, in some situations
[09:51] <kiko> Summary is more neutral :)
[09:52] <mpt> well, anyway, the order's important
[09:52] <mpt> I'm all in favor of asking people to summarize something after the thing exists for them to summarize, rather than before
[09:52] <mpt> bradb, ooh, the button isn't called "Add" any more, yay
[09:52] <kiko> bradb, maybe ask mdz what he thinks?
[09:52] <bradb> "Add" pissed me off
[09:52] <kiko> mdz, hello hello?
[09:52] <mpt> so this is a custom form now, huh
[09:52] <kiko> yeah Add is teh suck
[09:52] <bradb> mpt: yeah
[09:53] <kiko> how custom I wonder
[09:53] <mpt> still, there should be a better wording for AddForm even
[09:54] <mpt> "This bug should be visible only to its subscribers"
[09:54] <bradb> i KNEW someone was going to say that :P
[09:54] <mpt> ("only visible to its subscribers" suggests visible but not editable, or something like that)
[09:55] <bradb> yeah, yeah, i know :P
[09:55] <bradb> most users don't really care about that, but i'll change it for the grammar police
[09:56] <mpt> "Only" is quite easy once you learn the trick of pushing it as late in the sentence as possible while still having the meaning you want
[09:56] <bradb> i get the trick, i just think it sounds a bit weird there
[09:56] <bradb> a bit too grammatical
[09:56] <mpt> "This bug do be a security issue, indeed"
[09:57] <mpt> you could make up for it elsewhere
[09:58] <kiko> "This bug a security issue iseth"
[09:58] <mpt> "Begun, this security bug has."
[09:59] <kiko> ewww
[09:59] <kiko> "[ ]  Somebody already blew the whistle on this bug publically!"
[10:00] <mpt> publically? or privatally?
[10:00] <bradb> "mid-air collision!"
[10:00] <kiko> mpt, will you go on ignoring my emails!?
[10:01] <mpt> kiko, yesterday I went from an Inbox of over 1800 to under 1400
[10:01] <mpt> while trying to land 2006-02-headings
[10:01] <mpt> I'll get to yours in due course
[10:01] <mpt> is it urgent?
[10:01] <kiko> mpt, you need to learn how to filter email. one thing to remember: emails from me should be a priority (only a half-wink)
[10:02] <kiko> having 100+ messages in your inbox is unacceptable
[10:02] <kiko> change your process for dealing with email
[10:02] <mpt> ah, I see it
[10:03] <kiko> mpt, to start off with, filter /all/ non-to-you email into a separate folder
[10:03] <kiko> shouldn't be difficult
[10:03] <kiko> if it is, you should consider using a different email app.
[10:07] <ajmitch> morning
[10:07] <mpt> It's backed up only because I wasn't reading e-mail the past two weeks
[10:09] <ajmitch> bradb: I've been having a few search issues lately with malone, is that on this week's fix-list?
[10:10] <ajmitch> eg bug 33977
[10:10] <Ubugtu> Malone bug 33977 in malone "searching for 'needs info' bugs only yields all bug states" [Normal,Confirmed]  http://launchpad.net/bugs/33977
[10:11] <matsubara> hmm
[10:11] <matsubara> that was fixed last week
[10:12] <bradb> it should be marked Fix Released
[10:12] <ajmitch> it should be, but I still have those issues 
[10:13] <bradb> ajmitch: what issues are you experiencing? bug 33977 is fixed.
[10:13] <Ubugtu> Malone bug 33977 in malone "searching for 'needs info' bugs only yields all bug states" [Normal,Confirmed]  http://launchpad.net/bugs/33977
[10:13] <ajmitch> https://launchpad.net/distros/ubuntu/+source/f-spot/+bugs - any of the links on the right here, eg unassigned, don't change what is shown
[10:13] <ajmitch> ah sorry, assigned to me does
[10:14] <ajmitch> but unassigned shows 7, when it says 5 in the portlet
[10:14] <ajmitch> all bugs reported shows the same 7
[10:15] <ajmitch> so not quite the same as the original report, sorry
[10:15] <bradb> yeah, that's a pretty nasty issue. sorry, i'm trying to find the bug for that one right now.
[10:15] <bradb> bug 33882 would be one
[10:15] <Ubugtu> Malone bug 33882 in malone "Critical bugs are listed as 8 in the side bar, but there actually aren't any" [Normal,Confirmed]  http://launchpad.net/bugs/33882
[10:15] <bradb> and bug 34224
[10:15] <Ubugtu> Malone bug 34224 in malone "wrong bug number counts" [Normal,Unconfirmed]  http://launchpad.net/bugs/34224
[10:16] <bradb> kiko: Can these be prioritized? Maybe matsubara can fix them? If not, I could after I get sec teams sent off.
[10:17] <bradb> ajmitch: Any other specific search issues that are causing you particular pain?
[10:17] <ajmitch> those are the main ones - was trying to find the unassigned bugs on ubuntu to do some assignment to MOTU :)
[10:18] <bradb> ajmitch: https://launchpad.net/distros/ubuntu/+bugs-advanced-search can help you do that
[10:19] <ajmitch> ok, thanks
[10:19] <bradb> (there's a formatting bug on that page, but I've landed a fix for it already)
[10:19] <ajmitch> how does the release-specific search work for components? based off source package?
[10:20] <bradb> ajmitch: yeah
[10:21] <ajmitch> alright, this is looking helpful, thanks for that
[10:22] <bradb> no prob. i'll try and get those count problems prioritized for fixing, because they are pretty annoying.
[10:36] <kiko> bradb, -> matsubara
[10:37] <matsubara> kiko: I already assigned it to myself.
[10:39] <bradb> kiko: thanks
[10:39] <bradb> and matsubara, thanks :)
[10:42] <matsubara> kiko: the make check you left running has finished after 70min and 10 failures
[10:42] <kiko> 10 failures!
[10:45] <kiko> which ones?
[10:55] <matsubara> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/filec5sGGd.html
[10:58] <kiko> thanks
[11:12] <mpt> kiko, ping
[11:13] <kiko> mpt, 
[11:13] <kiko> on the phone with mdz
[11:13] <mpt> ok
[11:34] <kiko> matsubara, that is such a weird failure! I want to look at it
[11:49] <kiko> mpt__!
[11:50] <kiko> mpt_!
[11:50] <kiko> all the mpts in the world
[11:50] <kiko> can we schedule a phone call a bit later?
[11:54] <kiko> mpt__, use my cellphone
[11:54] <kiko> or I can call you, your option
[11:58] <kbrooks> sabdfl, is this you?
[12:00] <sabdfl> kbrooks: indeed.
[12:01] <kbrooks> sabdfl, what's up? my name is kyle brooks, by the way.
[12:01] <sabdfl> hi kyle
[12:02] <kbrooks> sabdfl, heh. i hope we see each other face to face at UBZ one day
[12:04] <kbrooks> sabdfl, well, what's up on launchpad?