[12:09] <dilys> New Malone bug 1378 filed on product Malone by Brad Bollenbach: MaloneApplication needs to be refactored to not use db classes
[12:09] <dilys> https://launchpad.ubuntu.com/malone/bugs/1378
[12:17] <lifeless> ok, I'm disabling the status page for today, theres a bug affecting result mail outs.
[12:18] <lifeless> I'll reinstate it as soon as I trck it down
[12:34] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  use list comprehension instead of list constructor to stop use of __len__, and avoid a commonly repeated warning. (patch-26<EMAIL_ADDRESS>[02:32] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  typo on browser logintoken and testing new email addition and not adding revoked uid with the modified 1024D/DFD20543 key. (patch-2074<EMAIL_ADDRESS>[03:15] <jamesh> so changing the pending-reviews/ page to use "baz get --link" instead of "baz get" shortened the runtime from ~ 1 hour to ~ 10 minutes
[03:15] <jamesh> could probably afford to run it more often
[04:06] <carlos> jamesh, I think the only problem with it is with zope
[04:07] <jamesh> oh?
[04:07] <carlos> but as you are not touching any file, should be ok for pending-reviews page
[04:07] <carlos> jamesh, something related to file changes
[04:07] <jamesh> carlos: yeah.  I just get, merge, diff, rm
[04:08] <jamesh> carlos: things that use "touch" on tracked files cause problems for hard linked trees
[04:08] <jamesh> I think that's the issue for zope
[04:11] <carlos> there is a package to solve that
[04:11] <carlos> but I don't remember its name
[04:12] <jamesh> carlos: fl-cow -- apparently daf uses it
[04:12] <carlos> yes, that one
[04:12] <carlos> but it's not in hoary
[04:12] <carlos> neither in breezy
[04:12] <jamesh> it is an LD_PRELOAD hack
[04:13] <carlos> right, but it makes bazaar really fast ;-)
[04:15] <jamesh> there was a kernel patch a while back: http://lwn.net/Articles/77972/
[04:48] <carlos> is there an easy way to test that a warning is not printed with a test?
[04:48] <carlos> I mean, we were getting a warning while importing po files, I fixed it and I want to add a test to check that we don't get that warning anymore
[04:52] <jamesh> carlos: warnings.filterwarnings() maybe?
[04:53] <jamesh> with warnings.resetwarnings() first to clear the existing handlers
[04:53] <carlos> jamesh, I don't want to remove the warning, I fixed the code that raised that warning
[04:53] <carlos> now, I want to test that it does not appear again
[04:53] <carlos> in the future
[04:53] <jamesh> carlos: I mean add a filter that matches the warning you fixed
[04:54] <jamesh> carlos: and e.g. make the filter raise an exception
[04:54] <jamesh> that would make the warning fatal
[04:54] <spiv> carlos: test_initZopelessTwice in lib/canonical/lp/ftests/test_zopeless.py does that sort of thing.
[04:54] <spiv> There may be an easier way to achieve it that what that code does, though.
[04:56] <jamesh> carlos: ah.  setting action='error' in a warning filter would do what you want
[04:56] <spiv> jamesh: The problem with filterwarnings/resetwarnings is what if there are existing filters you don't want reset?
[04:56] <jamesh> spiv: poke around in the undocumented internals of the warnings module instead of using resetwarnings() ?
[04:56] <spiv> All you really want is a way to add a filter and then remove it, and the public api doesn't seem to allow that.
[04:57] <spiv> jamesh: Right :)
[04:57] <carlos> jamesh, spiv but the warning would appear in other places
[04:57] <jamesh> del warnings.filters[0]
[04:57] <carlos> it comes from sqlobject
[04:57] <carlos> UserWarning: Getting a slice of an unordered set is unpredictable.
[04:57] <jamesh> carlos: so in your test case, you do warnings.filterwarnings(), invoke your code, del warnings.filters[0]
[04:58] <spiv> carlos: you can filter by module and lineno of where the warning was caused from.
[04:58] <jamesh> it'd be nice if the unittest module had some helpers to check for warnings
[04:59] <spiv> Yeah.
[04:59] <carlos> hmm, sounds too complex and the code works exactly the same with or without the warning...
[04:59] <lifeless> jamesh: did you implement all the changes I suggested ?
[04:59] <stub> test.py or test_on_merge.py already has some stuff to change warning filters.
[05:00] <carlos> spiv, do you think jamesh solution is a good one?, it sound easier :-P
[05:00] <carlos> stub, the question is how to test that a warning is not there anymore
[05:00] <spiv> carlos: sure, but with a comment saying this isn't part of the public api of the warnings module.
[05:00] <stub> spiv: What happened to that Librarian branch with the extra config items and the upstream facility?
[05:01] <spiv> stub: I told you where it was, and I thought you were going to use it and it was back in your hands :)
[05:01] <jamesh> lifeless: the pending-reviews/ page is just doing a diff between rocketfuel and rocketfuel+branch, rather than diffing two versions of a branch
[05:01] <carlos> spiv, in that case, I prefer to leave that code without a test as it's not a problem if we get the warning, I'm removing it just to reduce the verbosity of the cronscript...
[05:01] <stub> carlos: Configure the warning handler to die instead of print the message. The test runs, there is no warning.
[05:01] <stub> spiv: Argh!
[05:01] <jamesh> lifeless: so only the "baz get --link" part was relevant (but made a huge performance improvement)
[05:02] <spiv> stub: I seem to recall this happened on irc, which probably wasn't a good idea in hindsight :/
[05:02] <carlos> hmmmm
[05:03] <spiv> stub<EMAIL_ADDRESS>is the branch.
[05:03] <carlos> spiv, what about changing sqlobject so instead of a warning, you raise an exception as stub suggests?
[05:03] <stub> Doesn't need to change SQLObject - just need to change what warning filters we have installed
[05:03] <spiv> carlos: you can add a warning "filter" that raises an exception.
[05:03] <carlos> spiv, 99.9% it will be a programming error...
[05:04] <spiv> carlos: It will break launchpad :)
[05:04] <carlos> spiv, pqm should reject any code that does it, right?
[05:05] <spiv> iirc, it happens in quite a few places, but I could be wrong.
[05:06] <carlos> spiv, then we should fix those ;-)
[05:06] <stub> Install the new filter in test.py or test_on_merge.py (I forget which is already doing this). Its been on my todo to make *all* warnings fail tests, but fixing all the callsites could be difficult ;)
[05:07] <carlos> stub, I think SteveA's work is a first step in that direction, isn't it?
[05:08] <carlos> stub, well, I'm talking about SteveA's mail about tests output
[05:09] <stub> Steve's mail mentioned two warnings in Rosetta that shouldn't be there - they should be logging an error. The Warnings framework is very specific.
[05:15] <carlos> stub, yeah, that's another thing I'm going to fix
[05:17] <lifeless> jamesh: k
[05:30] <carlos> stub, btw, did you see SteveA's suggestion to handle emails on staging?
[06:08] <stub> carlos: Yes. Sucky method, which I've told him before ;) All emails will go to launchpad-error-reports instead where people can see them easily rather that stuffing around with mailboxes.
[06:09] <stub> But we still need t make the same fixes to the mail libraries, which nobody has done yet.
[06:12] <carlos> stub, that will help me a lot to debug poimport script
[06:12] <carlos> it's completely broken and I'm taking production output to fix it
[06:12] <carlos> that means we have it broken on production
[06:12] <carlos> with real data
[06:13] <carlos> well, that would be useful to debug any script ;-)
[06:15] <stub> carlos: Feel free to add the required intelligence sendmail.py
[06:16] <carlos> I don't have any idea about how it should be updated 0:-)
[06:19] <stub> It needs an option so all outgoing email is redirected to a configurable email address instead of going to the requested email address. I think we can already do this for emails from Zope using the existing stub emailer, but the Zopeless email needs this too.
[06:56] <carlos> stub, spiv is it a big issue if I execute a query that returns 17000 rows?, I'm not getting their SQLObject mapping at the same time, I'm using 'yield' to iterate over them
[06:57] <carlos> it's not inside Launchpad but inside a Rosetta cronscript
[06:57] <spiv> carlos: probably fine.
[06:57] <carlos> ok
[07:02] <stub> Sure
[07:36] <carlos> tests take so much time to run....
[07:38] <ddaa> carlos: you know you can restrict tests to a specific module or class? (at least with unittest-based ones)
[07:39] <ddaa> like "python test.py canonical.arch"
[07:43] <carlos> ddaa, hmmm, I thought make check just executes launchpad's tests....
[07:43] <ddaa> yes
[07:43] <lifeless> carlos: make check sets up the db and runs the test suite
[07:43] <ddaa> I see no contradiction
[07:44] <carlos> ddaa, I mean canonical.launchpad
[07:44] <carlos> lifeless, yeah, the db setup is fine, the 'test suite' is the issue if it executes tests outside canonical.launchpad ;-)
[07:45] <ddaa> huh... AFAIK it will run test_suite() that appears under ./lib/
[07:45] <ddaa> * will run any test_suite()
[07:45] <ddaa> except things that are in different trees, of course
[07:46] <carlos> ok
[07:47] <carlos> thanks
[07:47] <ddaa> maybe I'm the one confused...
[07:55] <carlos> stub, the tests are failing with 'Unable to start Librarian' errors, anyhint? I didn't touch anything related with Librarian....
[07:55] <carlos> ddaa, next run I will use your suggestion and will confirm if you are confused or not ;-)
[08:04] <stub> carlos: There might be a librarian process running already, which you should kill
[08:09] <carlos> stub, no librarian process running
[08:39] <SteveA> spiv: i'm going to the dentist shortly, but i'd like to catch up with you later
[08:41] <SteveA> spiv: see sqlobject/dbconnection.py, line 639.  I think there may be transactional issues with the librarian tests, or the librarian libraries.
[08:46] <spiv> SteveA: Ok, I'll take a look.
[09:01] <carlos> spiv, is there any possibility that aSQLObject.sync() call produce a transaction commit?
[09:02] <carlos> SteveA, I'm geting lots of pagetest failures with 404 errors with latest rocketfuel code and my local changes are unrelated to those pages
[09:05] <stub> lifeless: Your pqm queue seems to be down
[09:05] <lifeless> stub: yes, theres a bug, I've reverted the code
[09:11] <spiv> carlos: no, syncing won't ever commit.
[09:11] <carlos> spiv, perfect, thanks
[09:13] <jamesh> spiv: do you think it would be useful to have a function somewhere to retrieve the database transaction time? (like UTC_NOW, but usable in comparisons within Python code)
[09:15] <carlos> stub, seems like the problem with librarian is that it's executed once but it does not ends and the next test is not able to relaunch it
[09:16] <stub> carlos: Sounds like a test forgot to teardown properly.
[09:16] <stub> ie. called LibrianSetup().setUp() but not LibrarianSetup().tearDown()
[09:17] <carlos> I will check it again, but I don't think I changed/added anything related to librarian setup or teardown in my branch
[09:20] <spiv> jamesh: It could even be made into a method of UTC_NOW ;)
[09:20] <spiv> jamesh: UTC_NOW.what_am_i_really() ;)
[09:20] <jamesh> spiv: I just remember catching a problem in Mark's debbugs branch where he misused UTC_NOW
[09:20] <jamesh> spiv: doing "if some_datetime_object > UTC_NOW: ..."
[09:21] <jamesh> which always evaluated to True
[09:21] <spiv> jamesh: I guess at least UTC_NOW should raise an exception in that case.
[09:21] <jamesh> since "some_datetime_object > UTC_NOW" returns an SQLBuilder object
[09:21] <jamesh> spiv: it is useful being able to compare with UTC_NOW though
[09:22] <jamesh> spiv: eg. Table.select(Table.q.datefield > UTC_NOW)
[09:22] <spiv> Sure, but only with objects that can be meaningfully compared to it.
[09:22] <spiv> e.g. other SQLBuilder objects.
[09:22] <jamesh> hmm
[09:22] <jamesh> good point
[09:22] <jamesh> there isn't much reason to compare UTC_NOW against a constant date
[09:23] <jamesh> alternatively, it could magically do the right thing if you do so :)
[09:24] <spiv> Yeah.  It *could* go an issue a "SELECT CURRENT_TIMESTAMP AT TIME ZONE 'UTC';" I guess...
[09:24] <jamesh> although raising an exception or returning NotImplemented would probably be better
[09:24] <jamesh> so people don't confuse UTC_NOW with an actual datetime object
[09:27] <mpt> Anyone got time to give me a little baz help?
[09:29] <carlos> mpt, just ask
[09:32] <mpt> I need to know which was the last patch to alter a particular file
[09:32] <mpt> and baz annotate looks like what I want
[09:33] <mpt> but when I type "baz annotate lib/canonical/launchpad/images/user.gif", it just sits there
[09:33] <mpt> it doesn't exit, or do anything
[09:33] <lifeless> mpt: its not very optimal at the moment
[09:33] <lifeless> mpt: if its sitting there its working. wait.
[09:33] <mpt> Well, last time I tried it had still done nothing after 30 minutes
[09:34] <mpt> so I thought maybe it was expecting input from stdin or something
[09:34] <lifeless> mpt: nope
[09:35] <lifeless> mpt: it hits every revision ever. Takes a while - you might want to do a checkout on chinstrap and run it there
[09:35] <lifeless> oh, and its not tested on binary files. :/
[09:35] <mpt> heh
[09:35] <lifeless> in fact, for you, just run baz changelog | less, grep for \.gif
[09:37] <mpt> ok, I've found it
[09:38] <mpt> It's in the middle of a bunch of other modified files
[09:38] <mpt> ah, even better, I've found a patch I want to replay
[09:39] <mpt> ok, that looks easy enough
[09:39] <stub> lifeless: pqm is hung
[09:40] <lifeless> stub: ack
[09:42] <carlos> stub, https://chinstrap.ubuntu.com/~dsilvers/paste/filer5OmVN.html
[09:43] <carlos> stub, Any hint to debug the problem a bit more?
[09:43] <carlos> spiv, ^^^
[09:44] <carlos> I'm not sure, but the fact that several tests are executed more than once seems also as something broken, isn't it?
[09:45] <stub> The multi-tests are deliberate - I run some of the harness tests multiple times to ensure that they teardown stuff correctly
[09:45] <carlos> ok
[09:45] <stub> tachandler.py is new - it isn't in any of mu trees
[09:46] <carlos> it's not mine
[09:46] <carlos> so it should come from rocketfuel
[09:52] <SteveA> carlos: i was getting lots of errors the other day
[09:52] <SteveA> but i found out what it was
[09:52] <stub> Oh botch your own damn invariant
[09:53] <carlos> SteveA, does it means the error is in my computer?
[09:53] <SteveA> well
[09:53] <SteveA> what happened with me is two things
[09:53] <SteveA> 1. i had a librarian process running
[09:53] <SteveA> 2. i had a /var/tmp/fatsam.test/ directory
[09:53] <SteveA> the librarian parts of the test suite don't handle those cases well
[09:53] <SteveA> and cause lots of failures
[09:54] <carlos> me too, but I killed the librarian and removed the directory
[09:54] <SteveA> and you still get the errors?
[09:54] <carlos> and tests are still failing
[09:54] <SteveA> okay, do two things:
[09:54] <carlos> seems like librarian is not killed after a test
[09:54] <SteveA> 1. get a diff from your tree to rocketfuel
[09:54] <carlos> SteveA, I did it already, and I don't see any change that should affect librarian
[09:55] <SteveA> 2. turn off chunkydiff in launchpad.conf, and run the tests, output to a file with python test.py canonical 2> errors.txt
[09:57] <SteveA> BjornT: there are still two database imports into commands.py
[09:57] <jamesh> mpt: I have a small question about list box vs. combo box usage
[09:57] <mpt> You mean listbox vs. <select>?
[09:58] <SteveA> BjornT: also, do you know what BugDelta and BugTaskDelta are in database ?
[09:58] <jamesh> mpt: list box being <select size="n"> where n > 1, combo box being <select size="1">
[09:59] <SteveA> BjornT: can you take them out of database and put them in components ?
[09:59] <BjornT> SteveA: they don't really belong in the database code. they simply represent differences between Bugs and BugTasks
[09:59] <BjornT> SteveA: sure
[09:59] <jamesh> mpt: in my timezone prefs page branch, I used a list box to display the available time zones (about 400 items).  Bjorn commented that using a list box might indicate multiple select to the user
[10:00] <mpt> jamesh: The latter is an option menu (a "combo box" is a combination of text field + option menu, hence the name)
[10:01] <SteveA> Keybuk: around?
[10:01] <jamesh> mpt: I used a list box rather than the default option menu because the option menu becomes quite difficult to use with that many items.  What do you think?
[10:01] <jamesh> (it being hard to use is of course my own opinion)
[10:01] <mpt> jamesh: I agree, a listbox is more managable when you have more than about 20 or 30 items
[10:02] <mpt> It's unfortunate that browsers haven't visually distinguished between <select size>"1"> and <select multiple>
[10:02] <BjornT> SteveA: i'll remove the database imports from commands.py as well, it should be trivial
[10:03] <SteveA>     canonical.launchpad.subscribers.bugactivity
[10:03] <SteveA>     canonical.launchpad.subscribers.bugprivacy
[10:03] <carlos> stub, this is weird, it took more time to have librarian broken this time...
[10:03] <mpt> jamesh: Since we now have
 for the multi-selection case, I think it's fine to use a <select size>"1"> for the single-select case
[10:03] <SteveA> there's those too
[10:03] <SteveA> i think brad is handling     canonical.launchpad.systemhomes
[10:03] <SteveA> carlos: how's your test runs going?
[10:03] <mpt> jamesh: If you wanted to go to the trouble of making it crystal clear, you could use
 with radiobuttons inside it instead of checkboxes.
[10:04] <carlos> SteveA, stub https://chinstrap.ubuntu.com/~dsilvers/paste/file4qUVdn.html
[10:04] <jamesh> mpt: I don't think that is necessary.  I think it is fairly clear from the context that it is a single select box
[10:05] <SteveA> carlos: you're sure you have no librarian processes?
[10:05] <SteveA> carlos: ps aux | grep python    or something
[10:05] <carlos> SteveA, when I start executing the test I don't have any
[10:05] <carlos> SteveA, after the test run, I have one
[10:05] <carlos> I kill it, rerun the tests and it appears again
[10:07] <SteveA> spiv: ping
[10:07] <SteveA> carlos: are all of your other trees up to date?
[10:07] <carlos> SteveA, yes, I checked it twice
[10:08] <carlos> I'm using the same command that the refuel script uses
[10:08] <stub> carlos: I suggest updating tacserver.py to output the log file before raising the RuntimeError - might have some hints. Possibly something similar in the tearDown
[10:09] <carlos> stub, where is it?
[10:10] <stub> Where the exception is being raised
[10:10] <carlos> I mean, the file
[10:10] <stub>       File "/home/carlos/Work/dists/launchpad/lib/canonical/launchpad/daemons/tachandler.py", line 33, in setUp
[10:10] <carlos> oh
[10:10] <carlos> ok
[10:10] <carlos> I was looking for tacserver.py O:-)
[10:11] <SteveA> it's spelled "tachandler" but pronounced "tacserver" ;-)
[10:14] <BjornT> SteveA: ok, i'll fix bugactivity and bugprivacy as well
[10:14] <SteveA> thanks!
[10:14] <SteveA> when you fix one, you can remove it from the set of warned_database_imports in importfascist.py
[10:16] <stub> lifeless: Can you please check if production--1.25 has been tagged but not mirrored?
[10:17] <lifeless> stub: good guess
[10:18] <stub> erm... 'the usual' you mean :)
[10:22] <sabdfl> hey guys
[10:22] <mpt> Hi sabdfl, review sent
[10:22] <sabdfl> thanks mpt
[10:24] <mpt> BjornT: Can you point me to an example of a test that demonstrates the necessity of a change to security.cfg?
[10:27] <mpt> sabdfl: Currently if you set a bounty subscription from CC/Watch to None, does that leave behind a record in the database that wouldn't have been there if you'd never subscribed to the bounty at all?
[10:28] <sabdfl> mpt: i don't remember. i have a slight allergy to deletions, which stub tells me is paranioa. so i might have done it that way
[10:30] <lifeless> status queue back up - status emails should now be sent properly.
[10:35] <carlos> stub, I'm using pdb
[10:36] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  New production config (patch-95<EMAIL_ADDRESS>[10:36] <carlos> stub, and setUp is not called ever for librarian :-?
[10:36] <carlos> it's only called with buildd
[10:37] <stub> Most tests don't use the librarian, so won't set it up or tear it down.
[10:38] <carlos> stub, but I get the error that it cannot execute librarian
[10:38] <carlos> even without entering into pdb :-?
[10:39] <BjornT> mpt: it does get deleted. the easiest way for you to add a test is to edit pagetests/bounty/04-bounty-subscriptions.txt. copy the last test, change Content-Length: 45 to Content-Lenght: 44, subscription=watch to subscription=none, and adjust the expected output
[10:39] <mpt> BjornT: ok, thanks
[10:40] <carlos> fuck
[10:40] <carlos> stub, ddaa there is a hardcoded message talking about Librarian, but buildd is using also that code. the error comes from buildd
[10:41] <ddaa> -ECONTEXT
[10:41] <ddaa> carlos: what is it your are talking about?
[10:41] <carlos> ddaa, I'm not able to run test in my computer
[10:41] <carlos> ddaa, https://chinstrap.ubuntu.com/~dsilvers/paste/file4qUVdn.html
[10:42] <carlos> ddaa, if you look at the RuntimeError exception, it says Librarian, but it's buildd
[10:43] <ddaa> somebody gotta teach the firefox devels that popping up a certificate dialog in _another_ workspace is WRONG, even if that's the workspace of the first firefox window :(
[10:43] <ddaa> I think I'm going to file this bug, it's way too annoying.
[10:43] <stub> So fix the message?
[10:43] <carlos> stub, anyway, I still have the problem with the tests
[10:44] <stub> So did the logfile give you any useful information? If twisted doesn't start, the information will be in there.
[10:45] <carlos> stub, I don't see any log file write there, just a read one, that's why I'm using pdb
[10:45] <ddaa> carlos: why where you addressing this message to me? I cannot see anything in the error log that I'm better qualified to fix that you are...
[10:45] <carlos> ddaa, I thought buildd is your code...
[10:46] <stub> The output is redirected to self.logfile
[10:46] <ddaa> IIRC it's mostly debonzi, with some real chunks of Kinnison, and spiv seasoning for the review.
[10:46] <ddaa> take or give one...
[10:46] <carlos> ddaa, oh, right, sorry, I confuse it with the import code
[10:47] <carlos> stub, ok, lets try...
[10:47] <ddaa> yeah, my lair is importd... that's is _not_ buildd or and _not_ the other importd rosetta used to run :)
[10:49] <sabdfl> stub: which branch is going to production today?
[10:49] <stub> launchpad--production--1.24
[10:49] <stub> erm.... 1.25
[10:50] <sabdfl> stub: when was it tagged off rf?
[10:50] <sabdfl> i have a branch that tagged off friday morning
[10:50] <sabdfl> it's almost entirely ui
[10:50] <sabdfl> i was hoping to slip it into that production update
[10:50] <sabdfl> Fri Jul  8 09:06:58 BST 2005
[10:50] <sabdfl> was when it last merged rocketfuel
[10:50] <stub> patch-2069
[10:51] <sabdfl> how can i tell the match level i merged into a patch in my branch?
[10:51] <stub> I look at the messages returned by pqm
[10:52] <lifeless> sabdfl: what do you mean ?
[10:52] <lifeless> sabdfl: do you mean 'when did patch-FOO land in my branch' ?
[10:52] <sabdfl> lifeless: baz log shows me the last time my commit message said "merged rocketfuel"
[10:52] <stub> sabdfl: patch-2069 was from Sunday, so yours is in there.
[10:52] <sabdfl> i want to know what patch level of rocketfuel i merged
[10:53] <lifeless> sabdfl: 'baz changelog' is probably the best tool here. baz 1.5 has 'baz log --merges' which will give you that extra detail.
[10:53] <sabdfl> stub: ok, so if i merge from production-1.25, fix tests, get a review...
[10:53] <lifeless> sabdfl: if you are running 1..5, baz log --merges.
[10:54] <carlos> stub, the log file does not exists when we get the exception
[10:56] <stub> carlos: So twistd is not starting at all I guess. Need to debug that os.system call just above to work out why (I'd suggest switching it to use subprocess.Popen() and the communicate() method so you can capture the output easily.
[10:56] <stub> Perhaps you don't have twisted installed?
[10:58] <carlos> stub, the problem is that we have another twisted process running for buildd
[10:58] <carlos> stub, but /var/tmp/buildd is empty
[10:58] <carlos> so I think the problem is that those files are removed before the process is executed
[10:58] <carlos> I mean, It's killed
[10:59] <carlos> is that possible?
[11:00] <carlos> stub, https://chinstrap.ubuntu.com/~dsilvers/paste/filelyRHHV.html
[11:00] <stub> I have no idea - I know little about twisted or buildd ;)
[11:01] <carlos> Kinnison, ?
[11:01] <stub> I'd see if that other process actually *is* running
[11:01] <Kinnison> carlos: Hmm?
[11:02] <carlos> Kinnison, I'm having problems with buildd
[11:02] <carlos> and tests
[11:02] <Kinnison> carlos: cprov wrote the test harness
[11:02] <lifeless> carlos: having multiple twistd processes is probably ok, as the buildd and librarian are separate.
[11:02] <Kinnison> carlos: what's up exactly
[11:02] <carlos> lifeless, it's not a problem with librarian at all, the message talks about librarian, but it's 100% buildd
[11:03] <carlos> Kinnison, a process is left behind
[11:03] <carlos> so next test fails because buildd cannot be executed
[11:03] <Kinnison> carlos: so the buildd stuff isn't being torn down?
[11:03] <carlos> Kinnison, it is
[11:03] <carlos> but seems like the files at /var/tmp/buildd are removed before the process is killed
[11:04] <Kinnison> That's a bit odd
[11:04] <stub> Launchpad and the database are currently down for production upgrades btw.
[11:06] <sabdfl> stub: so i've missed today's production drop? ok
[11:07] <lifeless> carlos: could it be buildd using librarian ?
[11:07] <carlos> lifeless, don't think so, with pdb I only saw buildd executions
[11:07] <stub> sabdfl: It can be cherry picked when you are done. Code only updates are pretty quick.
[11:08] <stub> Assuming it is a bugfix... features should be run on staging and by other developers for a while before getting to production
[11:09] <sabdfl> stub: baz merge and 00star0merge are failing against production--1.25
[11:09] <sabdfl> i'll just skip this cycle - fix, lots of ui cleanup in there
[11:09] <carlos> anyway, I got the test failure with librarian now
[11:11] <sabdfl> stub: will you setup the update-stats.py cronscript too?
[11:11] <stub> sabdfl: Yup. Thanks for the reminder.
[11:11] <stub> I should do Malone email too
[11:11] <sabdfl> maybe run it after the update
[11:13] <carlos> could someone paste the file '/var/tmp/fatsam.test/librarian.log' content so I can see how it looks like?
[11:28] <Kinnison> carlos: oooh
[11:28] <carlos> breezy is using twisted 2.0 now
[11:29] <carlos> and we have a really weak check to know that the server is running
[11:29] <Kinnison> Aaah
[11:29] <carlos> "if 'set uid/gid' in open(self.logfile, 'r').read():"
[11:29] <Kinnison> eww
[11:29] <carlos> that's always False with twisted 2.0
[11:29] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  revert person icon, again (patch-2075<EMAIL_ADDRESS>[11:29] <Kinnison> Go us!
[11:30] <carlos> SteveA, any suggestion to fix it in a way that it's compatible with twisted 2.0 and 1.3?
[11:31] <lifeless> spiv: ^^^
[11:31] <lifeless> carlos: spiv is da twwsted god
[11:32] <carlos> right, I'm a bit confused atm this debug session burned my brain...
[11:36] <sabdfl> stub: update-stats.py running now?
[11:37] <stub> sabdfl: Yes
[11:37] <sabdfl> cool thanks, can't wait to see the results
[11:49] <mpt> that's better
[11:55] <carlos> mpt, I hate that firefox caches the .css...
[11:55] <mpt> carlos: Why shouldn't it?
[11:55] <mpt> I think every browser does
[11:56] <carlos> mpt, if you change the file in the server, it should refresh it
[11:56] <carlos> mpt, launchpad looks really ugly unless I force a reload
[11:56] <carlos> with the ui changes
[11:56] <mpt> that would mean HEADing the style sheet on every page load
[11:57] <carlos> mpt, or setting a timeout for it
[11:57] <mpt> and delaying the page layout until that response arrived
[11:57] <mpt> Setting a timeout for it is the server's job
[11:57] <mpt> But the server didn't know, yesterday, that the style sheet was going to have major changes in it today :-)
[11:58] <carlos> mpt, then launchpad has a bug, it needs to know the future
[11:58] <carlos> :-)
[11:58] <sabdfl> spiv: i've put a branch in your queue, should be quick and easy it's 90% templates which mpt has already reviewed
[11:59] <sabdfl> the code changes are primarily just shuffling code into the right places, especially DummyFooBar's
[11:59] <mpt> carlos: If we were really worried about it, we could temporarily rename launchpad.css to something else, and change the main template to match, so that it appeared to be a new file
[11:59] <mpt> and then change it back to the old name after a week or two
[12:00] <carlos> mpt, so every week the .css changes its name? ;-)
[12:00] <mpt> only for major changes
[12:02] <sabdfl> mpt: what's the current timeout?
[12:02] <mpt> sabdfl: I can't tell, I don't have LiveHTTPHeaders installed, and none of the online cacheability checkers seem to do HTTPS
[12:03] <mpt> ah, lynx to the rescue
[12:03] <mpt> Cache-Control: public,max-age=86400
[12:04] <mpt> So, you shouldn't be stuck with the old style sheet for more than 24 hours
[12:06] <sabdfl> you beat me to it :-)
[12:07] <lifeless> oh schweet
[12:07] <lifeless> new lp ROCKS
[12:07] <lifeless> great work
[12:07] <lifeless> sabdfl: I'm having trouble tracking elmo down.
[12:07] <lifeless> sabdfl: are you near him ?
[12:08] <sabdfl> carlos: https://launchpad.ubuntu.com/distros/ubuntu/hoary/+translations
[12:08] <sabdfl> i think that's worth a mail to the ubuntu translators list
[12:09] <sabdfl> lifeless: i haven't seen him today
[12:09] <carlos> wow
[12:09] <carlos> sabdfl, nice
[12:09] <lifeless> sabdfl: well, if you do ... please ;0
[12:10] <sabdfl> carlos: will you point our translators at that page please?
[12:10] <sabdfl> this one is pretty cool too, if you are Jordi :-)
[12:10] <sabdfl> https://launchpad.ubuntu.com/distros/ubuntu/hoary/+lang/ca
[12:10] <carlos> sabdfl, sure, let me try to contact daf first so we can use the same Rosetta announcement
[12:10] <sabdfl> jordi: ^
[12:10] <sabdfl> carlos: i need to edit that announcement
[12:10] <sabdfl> i think it's worth infomrally pointing people at that page now that it's in production
[12:11] <carlos> sabdfl, I know, but I don't know where is it
[12:11] <carlos> ok
[12:12] <SteveA> carlos: what's the twisted issue?
[12:12] <lifeless> SteveA: a twisted 2.0 incompatability, hes running breezy
[12:13] <carlos> SteveA, https://launchpad.ubuntu.com/malone/bugs/1385
[12:14] <spiv> lifeless, carlos, SteveA: this issue was already fixed by daf :(
[12:14] <lifeless> spiv: heh
[12:14] <lifeless> spiv: I thought you would know
[12:15] <carlos> spiv, then it's not merged into rocketfuel
[12:15] <spiv> carlos: It was :(
[12:15] <stub> sabdfl: stats have finished their first update
[12:16] <spiv> carlos: patch 1922, I think.
[12:16] <sabdfl> stub: looks wonderful, thanks!
[12:18] <SteveA> stub: i got a pqm rejection, couldn't set up the database as another user was accessing it
[12:18] <SteveA> * Creating database "launchpad_ftest_template" with sample data.
[12:18] <SteveA> createdb: database creation failed: ERROR:  source database "template1" is being accessed by other users
[12:18] <SteveA> createlang: could not connect to database launchpad_ftest_template: FATAL:  database "launchpad_ftest_template" does not exist
[12:18] <stub> send it again
[12:18] <SteveA> i have done
[12:18] <SteveA> why does it fail?
[12:19] <carlos> spiv, seems like cprov changes to add buildd tests reverted daf's changes
[12:20] <stub> SteveA: Some connection hadn't dropped. Can't drop or duplicate databases if there are open connections.
[12:20] <SteveA> do you know why open connections hadn't been dropped?
[12:20] <stub> SteveA: That case could be fixed by trying again
[12:20] <Kinnison> OOI is malone meant to list 'Fixed bugs' rather than simply hiding them?
[12:21] <lifeless> sabdfl: cvd needs you to call SA
[12:21] <stub> SteveA: Nope. Just happens - when you close a connection at the client, the backend might take a while to actually kill the process. Or some process left by the previous test was still hanging around.
[12:21] <stub> In this case process 9231, but it died before I could see
[12:22] <SteveA> jamesh: how often does the pending-reviews script run now?
[12:24] <carlos> spiv, ok, I see daf's patch, but I still see it too hacky
[12:24] <jamesh> still every 6 hours.  It managed to complete a run in 20 minutes using "baz get --link", but the next one ran in 40 minutes
[12:24] <lifeless> jamesh: does it have a revlib ?
[12:24] <carlos> spiv, isn't there a better solution than check log's output?
[12:24] <jamesh> lifeless: yeah
[12:25] <lifeless> jamesh: mmm
[12:25] <jamesh> lifeless: could depend on whether pqm is active during the run
[12:25] <jamesh> disk contention
[12:25] <lifeless> right
[12:26] <jamesh> but it is probably feasible to do more frequent checks
[12:26] <spiv> carlos: There's a more complex solution I used to have for the librarian, but really the added complexity isn't worth it.
[12:26] <carlos> ok...
[12:27] <spiv> carlos: (a TCPService subclass in the .tac that writes a foo.ready file that the launching process can wait for)
[12:41] <SteveA> BjornT: I'm getting mails from malone saying a new bug has been filed
[12:42] <SteveA> but it doesn't tell me who filed the bug
[12:43] <SteveA> i'd also like to see the summary of the bug included above each comment in mails notifying me of comments
[12:43] <BjornT> SteveA: hmm. it's brad who changed the notification mails. better to talk to him about it.
[12:45] <dilys> Merge to<EMAIL_ADDRESS>[r=jamesh]  Utility to run meld on a launchpad branch against the most recent merge of rocketfuel (patch-2076<EMAIL_ADDRESS>[12:45] <SteveA> maybe the spammers have joined launchpad without realizing it...
[12:45] <SteveA> ----
[12:45] <SteveA> I get online and I get this email from this girl
[12:45] <SteveA> Gina. She invites me to join her favourite dating
[12:45] <SteveA> site and see all her friends.
[12:45] <SteveA> ----
[12:45] <SteveA> no dude, it was a launchpad error message
[12:46] <Kinnison> SteveA: dude, gina *loves* you
[12:46] <Kinnison> SteveA: bend over and prepare to be filled with binary packages
[12:53] <SteveA> sabdfl: spiv's getting dinner.  I looked through the code on that branch.
[12:53] <SteveA> sabdfl: there are some minor PEP-8 issues.  The only code issue I have is this
[12:53] <SteveA> in browser/person.py, you have added the method no_bounties
[12:54] <SteveA> the method name should represent its boolean status, so something like "has_no_bounties".
[12:54] <SteveA> i think it would be clearer with a positive method name, such as "has_bounties".
[12:54] <SteveA> even though it is used in the opposite sense in page templates
[12:55] <SteveA>  "not: view/has_bounties" reads well enough to me.
[12:55] <carlos> sabdfl, I have the email ready to be sent, do you want to read it first? (regarding the statistics)
[12:56] <sabdfl> carlos: no, go ahead
[12:56] <carlos> ok
[12:57] <carlos> I got also the draft from daf
[12:57] <carlos> will review it and send it to you after lunch
[12:57] <carlos> just in case you want to take a look now, https://wiki.launchpad.canonical.com/RosettaOneDotZeroAnnouncement
[12:58] <SteveA> sabdfl: i'm happy for you to merge that branch.  i'll polish up the minor pep-8-isms later, as that'll be easier than commenting on it, and will free up spiv to work on some librarian issues i want him to work on.
[12:59] <sabdfl> SteveA: thanks!
[01:00] <sabdfl> test fixes in progress (lots of little page changes)
[01:00] <sabdfl> i'll change the view/has_bounties thing
[01:00] <SteveA> cool
[01:00] <SteveA> the dummy language stuff reads well
[01:01] <sabdfl> tests are taking a long time to run these days
[01:01] <SteveA> what do you do to run the tests?
[01:01] <SteveA> i tend to run them selectively, except immediately before landing
[01:03] <stub> BjornT: I remember what is needed doing for the inbound email configuration now. We have no way of configuriring the mailbox without hacking script.zcml directly now, because scripts do not load any .zcml overrides. I'll sort .zcml overrides for zopeless since it is quick.
[01:12] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  fixed up some unneeded imports (patch-2077<EMAIL_ADDRESS>[01:18] <lifeless> I am a duplicate code removal GOD
[01:19] <SteveA> you replaced hackerlib ?  ;-p
[01:19] <lifeless> if only it was duplicate code ;0
[01:20] <lifeless> no, I finally drilled in enough to remove arch_changeset_rewrite_indexes, which was a stupendously stupid function to ever exist
[01:20] <lifeless> theres now only a couple of places the changeset format leaks through in on the creation side, which I'm well placed to attack with extreme prejuidice.
[01:22] <lifeless> SteveA: we're up to changeset 11K in zope3
[01:22] <lifeless> thats the svn number
[01:25] <SteveA> is there a simple way to get vim to understand that a filename that ends in :NNN like foo.py:123 means "open foo.py and go to line 123" ?  It knows about vim foo.py +123
[01:27] <SteveA> lifeless: are you able to answer a question about the hct path API for launchpad?
[01:27] <Kinnison> SteveA: write a simple shell script in ~/bin/vim
[01:28] <jordi> sabdfl: hehe
[01:28] <SteveA> oh yeah, i could write a simple python script in ~/bin/vim
[01:29] <Kinnison> python seems a tad overkill
[01:29] <SteveA> okay, lua
[01:29] <SteveA> i object to shell
[01:29] <Kinnison> why do you object to shell?
[01:30] <Kinnison> and I'd recommend python over lua
[01:30] <Kinnison> you'd have to do fun shell escaping with lua
[01:30] <Kinnison> lua lacks an exec() wrapper
[01:30] <Kinnison> it only has system()
[01:30] <SteveA> do i need a reason to object to shell?
[01:33] <SteveA>  https://launchpad.ubuntu.com/people/stevea/+assignedbugs  takes a while
[01:35] <Kinnison> SteveA: yes, for shell is handy and neat
[01:38] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Reapplied daf's patch to use twisted 2.0 with launchpad (Closes: #1385) (patch-2078<EMAIL_ADDRESS>[01:44] <SteveA> BjornT: i'm having a weird problem with finding bugs assigned to me
[01:44] <BjornT> SteveA: what kind of problems?
[01:45] <SteveA> well, i've just spent 15 minutes searching in various ways for but 1240
[01:45] <SteveA> i didn't know its number until i found it
[01:45] <SteveA> so, it doesn't appear here: https://launchpad.ubuntu.com/people/stevea/+assignedbugs
[01:45] <SteveA> but, it does appear here: https://launchpad.ubuntu.com/malone/assigned
[01:45] <SteveA> i want a place where i can see all the bugs assigned to me, no matter how many, no matter what the priority
[01:46] <SteveA> spiv: i handled mark's ui review
[01:46] <spiv> SteveA: I just saw.  Thanks!
[01:46] <SteveA> did you get a chance to look at the librarian tests?
[01:46] <spiv> Looking now.
[01:47] <SteveA> i'd like to make transactions obsolete on commit
[01:47] <SteveA> and these tests are the only things that seem to stop that
[01:47] <spiv> I suspect my librarian-cleanups branch is relevant here, but that's just a guess at this stage.
[01:47] <SteveA> what do you need to do to land it?
[01:47] <Kinnison> jamesh: when is the next update of your pending reviews page due?
[01:48] <spiv> SteveA: A review.
[01:48] <spiv> SteveA: It was added to the general review queue before I went on holidays, but for some reason hasn't been reviewed.
[01:49] <SteveA> +    # XXX: There really should be a formal interface that both this and
[01:49] <SteveA> +    # ZopelessTransactionManager implement.
[01:50] <SteveA> own it
[01:50] <SteveA> +    # XXX: update the whole file to use 2.4's decorator syntax.
[01:50] <SteveA> looks more like a bug to be filed
[01:50] <SteveA> own the other XXXs you added
[01:51] <SteveA> note that i made some changes to sqlos and sqlobject recently
[01:51] <SteveA> including changing the ConnectionDescriptor
[01:52] <SteveA> spiv: looks good to me, with the comments above taken into account.
[01:53] <spiv> Ok, I'll act on those.  Thanks!
[01:58] <BjornT> SteveA: ok, +assignedbugs seems to show bugs on packages/products that you maintain, not bugs where you are the assignee. i'll talk to salgado and brad about it, we should coordinate a bit better in that area.
[01:58] <SteveA> my own use cases are like this:
[01:59] <SteveA>  - 1. stuff that i need to code: what bugs that aren't rejected or fixed, do i need to work on.  i want to see them all.
[01:59] <jblack> ddaa: ping
[01:59] <SteveA>  - 2. stuff i'm responsible for makeing happen indirectly.  these will be open launchpad bugs that no one else has claimed.
[02:00] <ddaa> jblack: heya
[02:00] <SteveA> on https://launchpad.ubuntu.com/people/stevea/+assignedbugs, there's some very confusing text
[02:00] <jblack> How are you?
[02:00] <SteveA> The bugs with greater priority assigned directly to Steve Alexander or to one of the packages/products (s)he maintains.
[02:00] <SteveA> What does "The bugs with greater priority..." mean?
[02:01] <ddaa> jblack: filing a bug on firefox... that's incredibly painful when you follow the steps, but I'm seeing the end of it.
[02:01] <jblack> heh.
[02:01] <jblack> btw, do you have that url for roomba-readyy-to-enable page?
[02:01] <jblack> Lifeless asked me to scan that this mornign. Its built up apparently.
[02:02] <ddaa> launchpad.ubuntu.com/bazaar
[02:02] <ddaa> you've got a link somewhere there to the search form
[02:02] <BjornT> SteveA: i don't know. salgado is responsible for that page
[02:02] <ddaa> (I could give you the exact url, I prefer to let you find by yourself)
[02:02] <SteveA> cprov, debonzi: where's salgado today?
[02:02] <jblack> Manage upstream imports?
[02:03] <ddaa> yup
[02:03] <cprov> SteveA: coming soon, I hope
[02:03] <jblack> That can't be right. There's only one there. Robert asked me about 1-2 hours ago to do 30
[02:03] <ddaa> the tricky bit on the form is the "ready" checkbox, AIUI it roughly means "restrict only to series whose product was approved".
[02:04] <ddaa> That's "Testing"
[02:04] <ddaa> you are interested in "Auto Tested"
[02:05] <debonzi> SteveA, don't know.. working from home today
[02:05] <jblack> 06:08 <lifeless> there are 30 autotested-ok but not enabled imports - can you move them
[02:05] <jblack>                  all to enabled today ?
[02:05] <jblack> I only see one link there. :)
[02:05] <ddaa> did you read what I just wrote?
[02:06] <jblack> Oh, ok. there we go. I had to change filter criteria to auto-tested.
[02:06] <jblack> and turn off ready as you suggest.
[02:06] <jblack> Thanks, ddaa
[02:08] <spiv> SteveA: My librarian-cleanups branch does make those tests pass.
[02:09] <SteveA> cool
[02:09] <SteveA> what was the critical change?
[02:10] <spiv> SteveA: Explicity beginning and committing transactions, probably.
[02:19] <SteveA> daf: ping
[02:23] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Add upstream librarian support for the staging environment (patch-2079<EMAIL_ADDRESS><EMAIL_ADDRESS>[02:29] <SteveA> hi salgado
[02:29] <salgado> hi SteveA
[02:29] <SteveA> on https://launchpad.ubuntu.com/people/stevea/+assignedbugs
[02:29] <SteveA> what does  "The bugs with greater priority..." mean?
[02:30] <SteveA> i had a problem finding a bug that is assigned to me
[02:30] <SteveA> i eventually found it on https://launchpad.ubuntu.com/malone/assigned.  it was not on https://launchpad.ubuntu.com/people/stevea/+assignedbugs
[02:30] <SteveA> very confusing
[02:31] <SteveA> as i was explaining to bjorn earlier, i have two use-cases for seeing bugs assigned to me
[02:31] <SteveA> 1. bugs that i'm directly responsible for fixing
[02:31] <SteveA> 2. bugs that i need to sort someone out to fix -- that is, launchpad bugs with no one assigned to them
[02:32] <salgado> yes, this is true. that page on foaf is supposed to be only the 10 most recent/prioritized bugtasks assigned to you
[02:32] <SteveA> i need to see all such bugs that are not rejected or fixed, no matter what the priority
[02:32] <SteveA> the 10 most recent is useless to me
[02:32] <SteveA> and the page doesn't make that clear
[02:32] <SteveA> the 10 most recent is okay, if i can get to a page that shows them all
[02:33] <SteveA> but, i simply can't use malone to do my job if i can't find out what bugs are assigned to me, or what bugs i need to get handled by someone.
[02:33] <salgado> well, when I created that page we didn't have this page where you could see all bugs assigned to you (we had but it was unusable)
[02:33] <SteveA> as i'm using malone more and more for launchpad development, that's what i'm finding i need
[02:34] <SteveA> brad asked me the other day whether it would work to assign a bug to me to get me to work on it
[02:34] <SteveA> i said "okay", but i was assuming i'd be able to find the bug later :-)
[02:35] <SteveA> as an instant improvement, the +assignedbugs page needs to clearly say it shows at most 10 bugs in each category, and be clearer about what the categories are.
[02:35] <SteveA> doesn't actually help my problem, but would have stopped me thinking i'd lost a bug from the system, or it had been fixed.
[02:37] <salgado> I see your point. I'll fix this and get that page linking to malone/assigned
[02:38] <SteveA> what's the longer term plan?
[02:39] <salgado> people suggested that it should be possible to search and see all bugtasks assigned to you on that page
[02:40] <salgado> I don't think this is reasonable because of the portlets. we don't have enough space to display a bugtask listing with all these options
[02:40] <SteveA> okay.  i have those two categories of assigned bugs i want to see.
[02:40] <SteveA> i'd be happy to see the two categories on the same page, or on different pages.
[02:40] <SteveA> i typically want to see either one or the other, not both at once.
[02:41] <cprov> stub: ping ?
[02:41] <salgado> the categories being: 1) bugs assigned to you.   2) bugs assigned to packages/products you're the owner/maintainer.
[02:41] <salgado> is that right?
[02:42] <stub> carlos: pong
[02:42] <cprov> stub:  me ...
[02:42] <carlos> cprov, blame nick autocompletation ;-)
[02:42] <SteveA> 1. open bugs assigned directly to me.  2. open bugs not assigned directly to a person, on packages / products i'm the owner/maintainer of.
[02:42] <cprov> stub: have you seen my mail to cherrypick the patch-2054 ?
[02:42] <stub> Blame Carlos bugging me too often ;)
[02:43] <SteveA> in case 2, the bugs are my responsibility to get assigned to someone.
[02:43] <carlos> stub, O:-)
[02:43] <stub> cprov: That would be in. production was tagged from 2069
[02:43] <cprov> carlos:  the situation is against you now
[02:44] <cprov> stub: great, second question: Staging and emails, do you have any plan or agree with the intra DC POP account ?
[02:45] <stub> cprov: I think it is a silly idea - pain in the arse to interrogate a remote pop server and multiple people will have trouble monitoring it. I'd rather just have all the emails bounced to launchpad-error-reports@ instead, where people can see them by subscribing to the relevant topic or in the Mailman archives.
[02:46] <stub> cprov: Not that it matters - launchpad still needs the same fix no matter what approach we use.
[02:46] <carlos> wow, make check shows me real bugs! finally!
[02:47] <SteveA> carlos: eh?
[02:48] <carlos> SteveA, just that I'm able to see tests breakage due my changes instead of random failures like this morning
[02:48] <SteveA> cool
[02:51] <cprov> stub: cool, and indenpendent of the solution adopted when is the ETA ?
[02:52] <salgado> mpt, around?
[02:53] <stub> cprov: There is no ETA as far as I'm aware. I haven't had a chance to look at it and I don't know of anyone else giving it a go.
[02:55] <stub> 14:19:03) stub: It needs an option so all outgoing email is redirected to a configurable email address instead of going to the requested email address. I think we can already do this for emails from Zope using the existing stub emailer, but the Zopeless email needs this too.
[02:55] <cprov> stub: uhm ... bad, but not that much ...
[02:57] <carlos> sabdfl, I think we should hide the languages that we have disabled by default from the list at https://launchpad.ubuntu.com/distros/ubuntu/hoary/+translations
[03:00] <SteveA> it would help to make rosetta look more used
[03:00] <SteveA> and the more used something appears to be, the more people feel like using it
[03:01] <carlos> SteveA, I'm talking about remove fr_FR, es_ES, es_MX, etc...
[03:01] <SteveA> yes
[03:01] <carlos> those are useless because never will be at 100%
[03:01] <SteveA> yes
[03:01] <carlos> oh, I thought you mean you prefer to leave all languages so we have "more"
[03:01] <SteveA> no
[03:02] <SteveA> i am arguing for removing them, so that the overall appearence of % translated appears higher
[03:02] <carlos> I appreciate your direct answers. Thanks ;-)
[03:02] <carlos> yeah
[03:03] <carlos> I need to prepare a script to remove POFiles that are empty so we remove other uncommon languages that were added by mistake when we were creating POFiles just when someone selected that language
[03:37] <carlos> ddaa, https://launchpad.ubuntu.com/products/imp/+addseries
[03:38] <carlos> ddaa, I thought you said that you don't want branches/series called 'head'
[03:38] <ddaa> nah
[03:38] <salgado> SteveA, do you know if we have a commit hook on sqlobject to run its tests?
[03:38] <ddaa> carlos: the help text is wrong, I should fix it whenever I can come around to it.
[03:38] <SteveA> i think to run its tests, but not to run any other tests
[03:38] <SteveA> not sure though
[03:38] <carlos> ddaa, you prefer 'main', right?
[03:39] <ddaa> yes, "main" in the emerging standard for all mainlines
[03:39] <ddaa> (cvs, svn, tarballs only, other rcs in the future) when a specific series is not needed.
[03:40] <ddaa> besides, HEAD is absolutely _not_ a branch in CVS.
[03:40] <ddaa> it's a magic tag
[03:40] <salgado> SteveA, looks like we don't have it. one test is failing here on a rocketfuel tree
[03:41] <salgado> lifeless, can you confirm to me that we don't have a commit hook to run sqlobject's tests?
[03:42] <lifeless> salgado: what do you mean ?
[03:42] <salgado> lifeless, if sqlobject's tests are run when I merge something into rocketfuel
[03:43] <lifeless> they should be
[03:43] <lifeless> if not its a bug
[03:43] <Keybuk> cool, sourcerer falls over on one of the linda "bad example" test cases
[03:44] <salgado> ok. I'll find out in a few minutes
[03:44] <carlos> cprov, debonzi: https://launchpad.ubuntu.com/products/imp/+series/main/+source <- That page is useless for HEAD/MAIN series
[03:44] <carlos> cprov, debonzi you say "Don't select a sourcepackage for MAIN/HEAD unless you are sure the package comes from that branch" but you cannot leave that field blank
[03:46] <debonzi> carlos, sorry but I don't know anything about this page
[03:46] <carlos> hmm
[03:46] <carlos> sorry
[03:46] <carlos> duded
[03:46] <carlos> dudes
[03:46] <carlos> I'm a bit tired today...
[03:46] <carlos> morgs, ?
[03:46] <cprov> carlos:  I see, blame morgs or lifeless, they are more related with those pages
[03:46] <carlos> cprov, right, I got confused with the sourcepackage, sorry
[03:46] <morgs> carlos: hi
[03:46] <cprov> carlos: no worries ;)
[03:47] <debonzi> carlos, hey.. no problem..
[03:47] <carlos> morgs, do you see my complain about the +series/main/+source URL?
[03:48] <morgs> carlos: yes, but it IS sourcepackage stuff...
[03:48] <carlos> morgs, but it's a 'Register' form
[03:48] <morgs> carlos: I'll have to dig a bit to see what the purpose of it is, and if there is a reason for the current way it works.
[03:49] <carlos> morgs, My point is that I don't care about the sourcepackage link
[03:49] <morgs> carlos: Yes... I'm not sure who added the source package bit in there, so I'll check it out.
[03:49] <carlos> ok
[03:49] <carlos> thanks
[03:49] <morgs> thanks
[03:51] <SteveA> hi brad
[03:51] <bradb> morning
[03:51] <bradb> hey SteveA
[03:51] <SteveA> so, i've been ranting on the channel about malone, person pages, and finding bugs that are assigned to me
[03:51] <SteveA> i'd lost a bug
[03:51] <SteveA> but also
[03:52] <SteveA> i'm suprised that emails i've received lately from malone don't tell me who made the change that's being reported
[03:52] <SteveA> it's made the mails much less useful to me
[03:52] <bradb> SteveA: that's my fault. i'll fix that this morning (it didn't make the cutoff for trying to keep my FBN patch down to a reasonable size)
[03:52] <SteveA> also, when a comment is left on a bug, i'd find it really helpful to get the bug's summary included in the email
[03:52] <SteveA> phew -- so it isn't a design decision :-)
[03:53] <SteveA> can you talk with salgado about the issues i had with looking for bugs that are assigned to me?
[03:53] <bradb> SteveA: do you find the bug summaries useful?
[03:53] <SteveA> bradb: yes, and i edit them when they're not.
[03:53] <SteveA> basically, i want to be able to find two lists of bugs assigned to me.
[03:54] <SteveA> 1. the list of bugs directly assigned to me.  that is, the ones i have to write code and such in order to fix.  i want to see ALL such bugs that are open.
[03:55] <SteveA> 2. the list of bugs that are on products i maintain, that aren't assigned to an individual.  it is my responsibility as launchpad owner / maintainer to ensure that someone gets assigned to these bugs.
[03:55] <bradb> right, makes sense
[03:56] <SteveA> my issue today is that
[03:56] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  New database baseline (patch-2080<EMAIL_ADDRESS>[03:56] <SteveA> 1. i crashed my X by pressing ctrl+alt+backspace accientally.  WHY is this enabled by default?
[03:57] <SteveA> 2. i lost my browser state, in which i had a bug report i was about to work on.
[03:57] <SteveA> 3. i restarted X and tried to find the bug.  i couldn't find it anywhere.
[03:57] <SteveA>   i knew daf had reported it, but i'm not allowed to see what bugs daf has reported.
[03:57] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Break a test to see if the tests are run when merging into rocketfuel. If this gets in, salgado will have to fix the test and make sure we have a commit hook to run the tests on rocketfuel. (patch-27<EMAIL_ADDRESS>[03:57] <SteveA>   i knew it had "facet" in its name, but i could find no text search box
[03:58] <salgado> about your browser state you can use the session saver extension
[03:58] <salgado> great. we don't run the tests for sqlobject. all tests I wrote where in vain
[03:58] <lifeless> SteveA:
[03:58] <lifeless> bah
[03:58] <lifeless> salgado: you sure about that?
[03:58] <SteveA>   i knew it was assigned to me, but it didn't appear in the list of bugs assigned to me
[03:58] <salgado> yes, I am
[03:59] <SteveA> then salgado told me that these lists of bugs only show a maximum of 10 bugs. there's no link to get to a full list of such bugs.
[03:59] <bradb> SteveA: you could find no text search box...interesting...
[03:59] <SteveA> i eventually found it on the "assigned bugs" list under /malone/
[03:59] <SteveA> is there one?
[03:59] <lifeless> salgado: sqlobject commits, or rocketfuel commits that should trigger sqlobject tests ?
[03:59] <SteveA> jakob n. says there should be a search box on every page.  but then again, he's on the board of google.
[03:59] <salgado> I guess rocketfuel commits, as we have for launchpad
[04:00] <salgado> lifeless, ^^
[04:00] <lifeless> salgado: uhm, I meant launchpad vs sqlobject commits to rocketfuel in both cases.
[04:00] <bradb> SteveA: (since this isn't a "user testing" session per se, i'll just cheat and tell you) yes, on the contextual bug listing page itself. but i agree with you that it's not very obvious how to get there.
[04:00] <lifeless> salgado: which are you sure doesn't test.
[04:00] <bradb> SteveA: e.g. https://launchpad.ubuntu.com/products/launchpad/+bugs
[04:00] <SteveA> lifeless: when pqm is committing code into sqlobject, i'd like sqlobject tests and then launchpad tests to be run.  possible?
[04:01] <lifeless> SteveA: yes, we commented it out for some reason
[04:01] <lifeless> enabled now
[04:01] <lifeless> someone should test that asap incase its borked
[04:01] <salgado> lifeless, so, if I commit to sqlobject now it should run all sqlobject /and/ launchpad tests?
[04:01] <SteveA> bradb: thanks.  oddly enough, i think i went to that page.
[04:02] <SteveA> bradb: i think i just missed seeing the search box.  i think i know why.
[04:02] <bradb> SteveA: why's that?
[04:02] <SteveA> bradb: it says "Bug ID or Keywords" where i scan pages along the left hand edge.  It doesn't say "Search with Bug ID or keywords"
[04:02] <SteveA> the word "search" is missing
[04:02] <bradb> ah
[04:02] <SteveA> it only occurs over towards the right
[04:03] <SteveA> and the box is so minimalist and ploney
[04:03] <SteveA> it just doesn't stick out as a text entry box
[04:03] <SteveA> it just looks like a random rectangle
[04:03] <bradb> i think i might have other ideas of why you missed that. we slightly violate nielsen's recommendations re: what users expect a search to be.
[04:03] <bradb> right
[04:03] <SteveA> a subheading saying "search..."
[04:04] <SteveA> in a different coloured div... something to draw attention to it
[04:04] <bradb> SteveA: imagine this possibility for improving the page:
[04:04] <lifeless> salgado: salgado yes
[04:04] <bradb> 1. don't show any "results" by default (i.e. when first entering into the page.)
[04:04] <SteveA> it certainly is odd to get results when i haven't searched
[04:04] <bradb> 2. just show a search box, and a button labelled search, and possibly further down the page some columns of info (your involvement, random bugs, etc.)...
[04:04] <SteveA> instead, it could show some kind of overview of canned searches
[04:05] <bradb> 3. search results returned on a separate page
[04:05] <SteveA> like "unassigned open launchpad bugs, 600 results, use this search"
[04:05] <bradb> right
[04:07] <bradb> mpt: around?
[04:17] <bradb> SteveA: there's are lots of page titles that need lovin' in Malone atm, but there's not much i can do until I have a way to set page titles for pages that don't have their own specific .pt. might you have a chance to look into the titles problem in the next couple days?
[04:18] <SteveA> sure
[04:19] <bradb> great, thanks
[04:26] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Add karmacacheupdater section to production config (patch-2081<EMAIL_ADDRESS>[04:29] <morgs> lifeless: pqm queue traceback - coming to your inbox
[04:36] <salgado> morgs, https://chinstrap.ubuntu.com/~dsilvers/paste/fileLrYXDX.html
[04:36] <salgado> is this the traceback you got?
[04:45] <bradb> i seem to be having a slight "ant" emergency in my house. damn bugs.
[04:45] <bradb> bbiab
[04:45] <SteveA> bradb: that is so ironic, oh malone hacker.
[04:48] <kiko> hey, production looks cool
[04:48] <kiko> SteveA, how's linkify going?
[04:48] <kiko> I bet it's forgotten
[04:49] <carlos> kiko, I need to talk with you about cronscripts and lock files
[04:49] <carlos> kiko, but not now, I need to leave
[04:49] <carlos> kiko, will you be around this evening?
[04:50] <kiko> in a few hours?
[04:52] <daf> SteveA: pong
[04:52] <stub> carlos: I have a branch up for review that tweaks quite a few bits in the cronscripts (but not the lockfiles). So you might want to merge or look at that branch to avoid conflicts.
[04:53] <carlos> kiko, in about 3 hours or so perhaps a bit later, I need to go to the flat to see things about the electric installation and the AC
[04:54] <carlos> stub, are you touching anything outside cronscripts/?
[04:54] <carlos> stub, I'm only touching at lib/canonical/launchpad
[04:54] <stub> carlos: I don't think that branch touched anything else.
[04:54] <carlos> stub, except for the lock code that I didn't start yet
[04:55] <stub> carlos: If the interface stays the same, there won't be any conflicts.
[04:55] <carlos> stub, then we should not conflict
[04:55] <carlos> right
[04:55] <salgado> lifeless, https://chinstrap.ubuntu.com/~dsilvers/paste/fileLrYXDX.html
[04:55] <carlos> see you later
[04:56] <kiko> carlos, okay.
[04:59] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Bug 1391: RDF export format still missing bits (patch-2082<EMAIL_ADDRESS>[04:59] <lifeless> salgado: fixed
[05:01] <kiko> argh
[05:01] <kiko> bradb!
[05:02] <Keybuk> syndicate modified-sources% diffstat -p1 libapache-mod-auth-mysql_4.3.9-2ubuntu1.diff.gz | head
[05:02] <Keybuk>  ,,changes.1110405409.7948.1/mod-dirs-index                                             |   14
[05:02] <Keybuk> Matthew Palmer, come on down
[05:03] <kiko> aiee
[05:10] <kiko> morgs, do you have a south african passport or is the one with a number ending in 729 not safrican?
[05:23] <dilys> Merge to<EMAIL_ADDRESS>Cherry pick patch-2081 into production (patch-1<EMAIL_ADDRESS><EMAIL_ADDRESS>[05:24] <cprov> lifeless: ping
[05:26] <cprov> lifeless: could you cherrypick also the patch-2074 into production, it solves the bug 1395
[05:33] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Fix the test I (intentionally) broke on last commit. (patch-28<EMAIL_ADDRESS>[05:39] <morgs> kiko: Yes it is south african.
[05:40] <morgs> salgado: no, it was a traceback in the pqm status page on chinstrap...
[05:40] <kiko> thanks morgs
[05:41] <bradb> ant killer powder, raid and ant traps, WDFA
[05:42] <bradb> kiko: what's up?
[05:42] <kiko> bradb, EMAIL NOTIFICATIONS ARE HEADLESS
[05:43] <bradb> i'm fixing that right now (two things: the From: address and the individual deliveries to each recip)
[05:43] <bradb> i.e. From: Christian Reis via Malone<EMAIL_ADDRESS>[05:44] <kiko> NOW
[05:44] <kiko> NOW!!!
[05:44] <bradb> it was one of the things i left out to keep the patch manageably small and hadn't yet gone back to finish that bit
[05:44] <kiko> no joke, that is a very serious regression
[05:44] <kiko> it makes bugmail a lot less valuable
[05:45] <kiko> it should not have landed in the intermediate state
[05:45] <kiko> (for future record)
[05:47] <bradb> right, the fix'll be in shortly for that
[05:47] <bradb> kiko: how does one avoid landing it in an intermediate state, btw?
[05:47] <bradb> (without creating 2000+ line patches, i mean)
[05:50] <kiko> hmmm
[05:51] <kiko> well, my point is that regressions should be avoided
[05:51] <kiko> if your patch will cause an intermediate regression, you need to negotiate with your reviewer
[05:51] <kiko> have him review up to patch X and then only from patch X to Y later?
[05:52] <bradb> true, that might work. i'll try that for keeping big patches manageable in the future.
[05:58] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  New database baseline (patch-2083<EMAIL_ADDRESS>[06:02] <bradb> salgado: might you be available in a few minutes (baz time) to review this small patch? it's a fairly urgent last bit of the implementation of FormattingBugNotifications.
[06:08] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Break a test again (this is the last time, I swear) because it still looks like tests are not being run. (patch-29<EMAIL_ADDRESS>[06:10] <bradb> rock on! somebody made the description display not look horrifyingly ugly!!!
[06:10] <bradb> was that you kiko?
[06:10] <bradb> and, well, all the comments, really
[06:11] <salgado> bradb, how big is the diff?
[06:11] <kiko> bradb, what are you referring to specifically
[06:13] <bradb> salgado: 2 files changed, 54 insertions(+), 38 deletions(-), but really straightforward (just adding an arg to a function and changing callsites, and, of course, small test updates.)
[06:13] <salgado> bradb, mail it to me, then
[06:13] <bradb> kiko: https://launchpad.ubuntu.com/malone/bugs/365. description is no longer in that horrifying blue box, and comments are no longer
'd, by the looks of it.
[06:13] <SteveA> daf: ping again
[06:14] <kiko> bradb, isn't that DPoT?
[06:14] <bradb> oh, perhaps
[06:15] <bradb> makes a huge difference on the bug page
[06:17] <bradb> salgado: sent
[06:17] <kiko> bradb, I removed the reply to comment expander thingy though :)
[06:19] <kiko> there are some spacing issues left there, I'll polish further
[06:19] <bradb> kiko: do you like the "boxy" look of comment display?
[06:19] <kiko> I hate it
[06:19] <kiko> but one step at a time
[06:19] <bradb> me too :)
[06:20] <bradb> right
[06:24] <kiko> man, web links are crack.
[06:24] <kiko> https://launchpad.ubuntu.com/malone/bugs/478
[06:24] <kiko> look at that portlet
[06:25] <SteveA> so, that's a launchpad link
[06:25] <SteveA> but only because it is reported on the "rosetta" product
[06:26] <SteveA> here's a suggestion
[06:26] <SteveA> 1. in "related web links", abbreviate all links to [launchpad.ubuntu.com]  or [fish.shallowwater.net]
[06:26] <SteveA> 2. make the title of the links be the full url, so you can see the url on a hover
[06:27] <SteveA> 3. add an expando-button that shows an otherwise hidden div that shows all the links
[06:27] <kiko> SteveA, you already see the full URL in the webbrowser statusbar, so the title is overkill
[06:27] <SteveA> you have a status bar?
[06:27] <bradb> SteveA: why not just show the title of the link in the portlet?
[06:28] <kiko> bradb, that's the right approach
[06:28] <SteveA> if we want to avoid magic, then at the bottom of the bug report, have a section called "links" that has the links in full
[06:28] <SteveA> using the body of the page for it
[06:28] <SteveA> the title of the link?
[06:28] <SteveA> what does that mean?
[06:28] <SteveA> in the example kiko shows, i see no title
[06:28] <bradb> click on [Edit]
[06:29] <SteveA> oh cool. i never would have guessed.
[06:29] <SteveA> so yeah, show the title, with the url as the, um, title attribute
[06:29] <bradb> right
[06:29] <SteveA> it means i can use my mouse to see the titles without having to look several inches down to the status bar
[06:29] <SteveA> assuming i have left it on the screen
[06:30] <SteveA> bradb: be sure to add a related web link to that bug
[06:30] <bradb> !
[06:30] <SteveA> maybe to the bug kiko pointed out
[06:30] <kiko> placing the URL in the link title is bad usability, I'm quite sure
[06:31] <kiko> I agree with the other points
[06:31] <SteveA> well...
[06:31] <SteveA> usually a link points to other data.  in this case, the link itself is the data.
[06:31] <SteveA> i'm not passionate about the point though
[06:32] <kiko> for 99% of the web browsers the statusbar will be visible and you will be displaying the same information twice
[06:32] <kiko> it is inconsistent behaviour with 99% of all the other links that exist on the web today
[06:32] <kiko> (ask yourself, have you ever seen a URL in a link title?)
[06:33] <dilys> Merge to<EMAIL_ADDRESS>Buildd packaging stuff. r=jamesh,daf (patch-2084<EMAIL_ADDRESS>[06:40] <bradb> daf: is dilys unable to cope with the new bugmail format?
[06:40] <bradb> she doesn't appear to have noticed the bugmail for 1401
[06:47] <bradb> anyone know of a tool that can tell me if i'm calling a method or func with spaces around the "="? i can't seem to find such an option in pylint.
[06:48] <bradb> hm, interestingly, it warns me of exactly the opposite
[06:50] <kiko> bradb, remind me why it is no longer possible to retarget a task?
[06:50] <kiko> that's causing bugspam and taskspam as people report bugs on launchpad that need to be retargetted to malone, etc.
[06:52] <bradb> i can't remember the exact reason but, as you point out, experience has shown that to not be the right approach.
[06:53] <bradb> ideally, i'm hoping that we can fix that with a small workflow.
[06:56] <kiko> why is it not the right approach?
[06:56] <bradb> kiko-fud: sorry, i meant experience has shown that the *not* allowing retargetting is not the right approach
[06:57] <kiko-fud> so we should allow retargetting. ah.
[06:57] <kiko-fud> I see -- the workflow would make it clear to the end-user that this change has some more severe impact that simply changing a severity
[06:58] <kiko-fud> on the same grounds changing the status would warrant also a different widget or a workflow, don't you think?
[07:00] <bradb> kiko-fud: to the former, exactly.
[07:00] <bradb> kiko-fud: to the later, yeah, maybe. currently, there doesn't seem to be enough "impact" when a bug is marked Fixed.
[07:00] <bradb> s/later/latter/
[07:01] <kiko-fud> or ASSIGNED
[07:01] <kiko-fud> or REJECTED
[07:01] <kiko-fud> etc
[07:01] <bradb> right
[07:04] <bradb> some days i wish mpt was in my timezone
[07:04] <bradb> most days, actually
[07:37] <dilys> Merge to<EMAIL_ADDRESS>[r=salgado]  implement the From address part of FormattingBugNotifications (patch-2085<EMAIL_ADDRESS>[08:03] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  make the login page work when there are several query parameters that have the same name.  this fixes a lot of the broken links on staging. (patch-2086<EMAIL_ADDRESS>[08:56] <kiko-fud> bradb, he will be -- soon.
[08:56] <bradb> heh
[09:02] <dilys> Merge to<EMAIL_ADDRESS>Fix PersonSet's methods to always return results ordered by Person._defaultOrder if no orderBy argument is provided. r=SteveA (patch-2087<EMAIL_ADDRESS>[09:04] <kiko> salgado, bradb: email.
[09:10] <bradb> i can write a docstring and rename that method to clarify
[09:11] <bradb> and perhaps rename the user parameter to something that better communicates "the user who made the change" or something.
[09:12] <kiko> why can user be none?
[09:13] <salgado> from what I saw it looks like the user will be none if we allow not-logged-in people to report bugs
[09:13] <salgado> in that case event.user will be None
[09:13] <bradb> mm, basically, the API isn't communicating the following two possibilities very well:
[09:14] <bradb> 1. we want to see "From: Foo Bar via Malone <...>" (e.g. after Foo Bar edited the bug)
[09:14] <bradb> 2. we don't want to see "From: Foo Bar via Malone <...>" (e.g. for a transactional error message when Foo Bar tried to change the bug.)
[09:15] <bradb> maybe i'll break it up into two methods
[09:15] <bradb> get_bugmail_from_addr and get_error_mail_from_addr
[09:15] <bradb> what do you think?
[09:19] <kiko> that's the correct approach
[09:19] <kiko> I have no clue why you are using the same method for both things
[09:20] <kiko> def a(foo, bar=None):
[09:20] <kiko>    if bar:
[09:20] <kiko>      do_x()
[09:20] <kiko>   else:
[09:21] <kiko>     do_y()
[09:21] <kiko> there is no commonality
[09:25] <bradb> kiko: changed locally. they changes'll be merged with the one-email-per-recipient change
[09:25] <bradb> s/they/the/
[09:29] <kiko> that's fine.
[10:32] <kiko> bradb, when adding a remote watch to a bugtask, the task_delta generated is zero in watch
[10:33] <bradb> ok, i'll file a bug report on it. thanks for pointing it out.
[10:34] <kiko> sorry in karma.py:bugtask_modified
[10:35] <bradb> it should be in mailnotification.py
[10:35] <kiko> bradb, no, my point is that task_delta is None there
[10:35] <kiko> in karma.py:bugtask_modified
[10:35] <bradb> ah
[10:36] <bradb> i have a function that calculates task deltas, but it looks like that feature went in untested
[10:36] <kiko> right
[10:36] <kiko> can you fix that and add a test?
[10:36] <kiko> it's broken in production..
[10:37] <bradb> maybe BjornT can fix it?
[10:37] <kiko> ask?
[10:37] <bradb> BjornT: can you fix the problem kiko's talking about above?
[10:42] <bradb> kiko: btw, have you confirmed that it sends out an empty bugmail when assigning a bugwatch to a task?
[10:42] <bradb> (from what you've said so far, i'm not 100% sure on what i should file as the bug report)
[10:43] <kiko> bradb, it currently crashes
[10:43] <kiko> indeed, it sends out an empty bugmail
[10:43] <bradb> er, by "crashes", you mean, you can't even /save/ an external bug watch from the task page?
[10:43] <kiko> right
[10:43] <bradb> wow
[10:43] <kiko> traceback boom-boom
[10:44] <kiko> non-tested features courtesy of the sab himself :)
[10:44] <kiko> I'll see if I can fix it
[10:44] <bradb> great. now that i have an idea of the extent of it, i'll file the bug and assign it to you for now, ok?
[10:45] <kiko> btw
[10:45] <kiko> get_task_delta is totally in the wrong place
[10:45] <bradb> right
[10:46] <bradb> maybe it should be in helpers.py? or, where do you want it to be?
[10:46] <bradb> (helpers.py is slightly evil, imho, but i'm not sure what other package it's better suited for, atm)
[10:47] <kiko> it should probably be in database/bugtask.py
[10:47] <kiko> (for lack of a better place)
[10:47] <kiko> SteveA is the man with the plan for that though
[10:47] <SteveA> i think bjorn is moving the task delta stuff to components
[10:48] <kiko> I scratch my head because for all the N-M relationships it seems that bugtask and remote bugwatch are N-1..
[10:48] <kiko> thank god
[10:48] <SteveA> if it is in database, then we would need an API via getUtility to get at a bugdelta
[10:48] <SteveA> i don't really see the point
[10:48] <SteveA> it really is a component
[10:48] <kiko> well
[10:48] <kiko> okay, whatever, not helpers.py
[10:48] <salgado> bradb, have you seen this: https://launchpad.ubuntu.com/errors/showEntry.html?id=1121201203.030.164754340775
[10:48] <SteveA> as it is database independent, and stores the differences between two different components, depending on their interfaces
[10:49] <bradb> salgado: it doesn't ring a bell offhand. how did you make it happen?
[10:51] <salgado> bradb, go to https://launchpad.ubuntu.com/malone/bugs/1311 and click on the 'Ubuntu' link
[10:52] <bradb> daf: when's dilys going to be back in service?
[10:52] <bradb> daf: she appears to not understand the format of the new bugmails
[10:52] <bradb> salgado: i'm filing a bug on that now, thanks.
[10:53] <bradb> filed as 1403
[10:54] <kiko> how weird
[10:54] <kiko> a bugtask without a bug?
[10:54] <kiko> regression?
[10:55] <bradb> dunno, don't have much time to look deeper atm, but it seems like an isolated case
[10:57] <kiko> very very odd
[10:57] <carlos> kiko, hi
[10:57] <bradb> ah, i think i might know why
[10:57] <bradb> but only maybe. /me tests something.
[10:58] <kiko> hey carlos
[10:58] <carlos> kiko, I'm a bit tired atm do you think the explanation will take too long?
[10:59] <kiko> carlos, probably not
[10:59] <carlos> ok
[10:59] <carlos> kiko, do you have time now?
[10:59] <kiko> yeah
[10:59] <bradb> kiko: right, i think it's because canonical URLs are not setup for distro release tasks.
[11:00] <kiko> bradb, that needs to be fixed asap, drop everything and do it
[11:00] <carlos> ok
[11:00] <kiko> carlos, what's the problem
[11:00] <bradb> kiko: ok
[11:00] <carlos> kiko, we have a script that is executed every 10 minutes
[11:00] <carlos> that creates a .lock file
[11:00] <kiko> bradb, mailnotification problem fixed, can you add a test for it for me later?
[11:01] <kiko> carlos, sounds good. :)
[11:01] <carlos> and under some circunstances, the lock file is left behind when the script is killed
[11:01] <carlos> so it locks new runs
[11:01] <bradb> kiko: sure, am i testing to make sure that a notification email gets sent when the watch info is changed on a task?
[11:01] <carlos> stub suggested me to add a timeout for that lock file
[11:01] <carlos> but with the poimport script it's a problem when it has a high load to import (like breezy)
[11:01] <kiko> bradb, well, perhaps two tests -- checking that the notification email gets sent correctly, and that the page doesn't bork.
[11:02] <bradb> right, ok
[11:02] <bradb> i'll file the bugs for those in malone
[11:02] <bradb> (i.e. that they need tests)
[11:02] <carlos> as it takes more than one day to finish (the default lock timeout is 1 day)
[11:02] <kiko> bradb, thanks.
[11:02] <kiko> carlos, I see your problem.
[11:02] <kiko> well
[11:02] <carlos> kiko, stub told me that you have a way that removes always the .lock file even with a kill -9
[11:03] <kiko> carlos, it doesn't always remove the lock file -- it checks to see if the process holding the lock is still alive
[11:03] <kiko> I sent it to the mailing list
[11:03] <carlos> oh really?
[11:03] <kiko> yes
[11:03] <carlos> I missed it ....
[11:03] <carlos> and that solution makes much more sense, I was not able to understand how is that kill -9 was working ;-)
[11:04] <kiko>   F 2709 Jun 21 To Dafydd Harries   (  11K) Re: urgent production fix: patch-1899
[11:04] <kiko> attached to that message
[11:04] <bradb> SteveA: btw, sorry, but it's looking like I have to delay the systemhome.py cleanup for another day.
[11:05] <kiko> carlos, hoho, I lied, the kernel actually does ensure the lock is released
[11:05] <kiko> see my follow-up email
[11:05] <carlos> kiko, ok, thank you
[11:06] <kiko> enjoy.
[11:06] <kiko> that thread should help you understand my point
[11:06] <kiko> everything there is untested
[11:06] <kiko> :)
[11:07] <kiko> bradb, mailnotification has some hairy functions but is pretty easy to follow
[11:08] <carlos> kiko, I don't have any answer from you to that thread
[11:08] <bradb> kiko: good to know that it's not /too/ hairy then ;)
[11:08] <carlos> kiko, I only have mails from stub and daf
[11:08] <kiko> carlos, that's because I don't love you
[11:09] <carlos> kiko, I know that ;-)
[11:09] <carlos> thank you
[11:09] <kiko> I may love you if you bring me a 19" monitor
[11:09] <kiko> but maybe not
[11:10] <kiko> bradb, I'm going to ask you to review my changes
[11:10] <bradb> kiko: sure, whenever you're ready
[11:11] <kiko> it's not a trivial branch because there are other fixes with it
[11:11] <kiko> but it's all healthy
[11:12] <carlos> kiko, dude, I think you choose the wrong person ;-)
[11:12] <bradb> kiko: is this something you'll have ready today, or tomorrow?
[11:12] <carlos> kiko, my sould is not mine any more it belongs to my bank
[11:12] <kiko> bradb, tomorrow is okay
[11:12] <bradb> kiko: ok, cool
[11:12] <carlos> for the next 30 years...
[11:12] <carlos> :-P
[11:12] <kiko> carlos, your bank needs to give me a 19" monitor dammit
[11:12] <bradb> carlos: is your move complete?
[11:13] <carlos> bradb, not really, I got the keys on Saturday
[11:13] <carlos> I'm planning to move this weekend
[11:13] <bradb> ah, right on, welcome to the club
[11:13] <carlos> it depends If I'm able to connecto to my university wireless from my home (the link works, the VPN does not work) or I get my DSL line installed
[11:14] <carlos> bradb, thank you!
[11:15] <carlos> kiko, I will try to integrate that into Launchpad using that code as a library in its own file so we don't have legal issues.
[11:15] <kiko> carlos, cool, thanks
[11:15] <carlos> I think it's time to sleep after a 37hours day...
[11:15] <carlos> good night
[11:15] <bradb> 37!
[11:16] <bradb> i wish every day had that many hours in it
[11:16] <kiko> bradb<EMAIL_ADDRESS>contains the fix if you want to look at it
[11:17] <bradb> kiko: is it going to be part of the thing i'm going to review tomorrow? if so, i'll wait so i can fix this canonical url thing now instead.
[11:17] <carlos> bradb, don't think it's a good idea to do it often, I do it every one / two months and at the end I'm really tired, but the night without sleep is a good one talking about productivity ;-)
[11:18] <kiko> bradb, yeah, sure, wait
[11:18] <bradb> carlos: cool, sleep well then ;)
[11:20] <kiko> adding a bugwatch is horrific
[11:20] <bradb> BjornT: how many Malone bugs do you have assigned to you?
[11:20] <kiko> it should obviously take a URL and parse it
[11:20] <kiko> bradb, that's easy to check :)
[11:20] <bradb> is it?
[11:21] <bradb> maybe that's one of those foaf things
[11:21] <kiko> no
[11:21] <kiko> malone/assigned?
[11:22] <bradb> ew, that makes me /count/ the rows :)
[11:22] <bradb> it looks better than it did before though, which is nice
[11:22] <kiko> bradb, I can add a counter, doh
[11:22] <bradb> and paging?
[11:22] <kiko> NO
[11:22] <bradb> searching?
[11:22] <kiko> go away horrible man
[11:22] <bradb> filtering?
[11:22] <kiko> yeah yeah
[11:22] <kiko> ANORAK
[11:24] <bradb> kiko: one question: in what way is my life made easier by clicking on a page that shows 150 bugs assigned to me? what do i do with that information?
[11:24] <bradb> what would make me want to look at that information?
[11:25] <bradb> (ok, that was more than one question)
[11:26] <kiko> well
[11:26] <kiko> I like looking at it to see what I need to do
[11:27] <bradb> with column-click sorting, it would be more useful to that end, i think
[11:28] <bradb> kiko: btw, re: paging, i hate the 20 bugs/page thing too (*hate*). but sabdfl shot me down pretty quickly when i suggested bumping it up to something usable.
[11:30] <bradb> kiko: strangely, based on his "Malone UI" email he also seems to indicate that the table layout "isn't working for us". i wonder if showing him a google-style listing of 150 assigned bugs would change that viewpoint.
[11:31] <kiko> I think a google-style listing is pretty much the only way to go with bugs and tasks (and tasks on upstream versus distro, for that reason)
[11:32] <bradb> kiko: i.e. are you imagining a scenario where you're looking at the list of Malone bugs (say there are currently 75 on your screen) in a google-style listing?
[11:33] <kiko> yeah
[11:33] <bradb> (making each style optional makes 100% sense to me, but i'm trying to figure out how a 50+ bug long google-style listing would meet scannability requirements)
[11:35] <bradb> Google gets away with it pretty well. I rarely read more than 2-3 search results, /maybe/ the whole first page in somewhat rare cases. they batch bigtime though.
[11:35] <kiko> well, the problem is that bugtasks are heterogeneous enough to make a tabular listing kinda impractical
[11:36] <lifeless> morning all
[11:37] <zer> good evening
[11:37] <bradb> kiko: let's say you're looking at a row result for bug #42 in package Ubuntu Foo. let's say it's also reported in 3 other places. to what extent do you want to know anything about those three other places when looking at the listing in the Ubuntu context? (i can think of exactly one thing that matters re: any context that isn't mine)
[11:38] <kiko> bradb, they could be expanded (little plusses)..
[11:39] <bradb> kiko: other than "does a fix exist for this bug?" what else is an average malone user going to want to know about the bug re: the other contexts in which it exists?
[11:43] <bradb> SteveA, kiko: can i delete the absolute_url stuff left around for bug tasks?
[11:44] <kiko> bradb, think it's still used here and there
[11:44] <bradb> kiko: shouldn't everything use canonical url now?
[11:49] <bradb> no turning back now!
[11:54] <kiko> well
[11:54] <kiko> bugwatch for instance is a bit tricky
[11:54] <kiko> there is no parent for it :)
[11:54] <lifeless> ?
[11:55] <kiko> you assume too much young padawan
[11:56] <bradb> kiko: bugwatch isn't effected by this.
[11:56] <bradb> i've already changed all the callsites
[11:57] <bradb> (i.e. that were using @@absolute_url)
[11:57] <kiko> great
[11:57] <bradb> s/effected/affected/
[11:58] <kiko> bradb, can't you make the bugtask page in view mode link to the assignee and remote bug?
[11:58] <kiko> that's a really annoying bug
[11:58] <bradb> kiko: sure
[11:58] <kiko> is it trivial?
[11:58] <kiko> I don't know how to deal with this autogenerated content, it makes me cry
[11:58] <bradb> now that i've made them two different pages, it should be pretty straightforward (i.e. more flexibility to move away from the widgets in the view page)
[11:59] <kiko> thank god
[11:59] <bradb> you can even change it, if you want. just change the call to view/assignee_widget (or whatever it is), to context/... whatever you wanted.
[12:00] <bradb> if you already know what you want it to look like, that is, and know the ZPT that will get you there
[12:01] <bradb> in the meantime, i've cleaned up a whole bunch of abs url cruft and fixed that exception
[12:01] <kiko> fun fun
[12:01] <kiko> filing distro bug tasks is broken
[12:02] <salgado> bradb, please confirm to me that the bugtask table doesn't have a submitter column?
[12:02] <bradb> salgado: it doesn't
[12:03] <bradb> kiko: the tabindex, you mean?
[12:03] <kiko> bradb, no. file a package bug but forget to type in the distribution name.
[12:04] <salgado> ok. I'm asking because both IBugtaskSet.search() and IBugTaskSubset.search() have a submitter parameter, which is not tested, obviously
[12:04] <bradb> kiko: oh, we have to get rid of that page.
[12:04] <bradb> kiko: i.e. better drilldown to the distros, instead of treating distro like a piece of info in the form.


[08:31] <elacheche> o/
[08:31] <elacheche> Na3iL: feedback! :)
[08:33] <Na3iL> elacheche, \o
[08:33] <Na3iL> just amazing! and a lot of tricks to learn :D
[08:33] <elacheche> Yep! You're stick @what stage?
[08:33] <elacheche> stuck*
[08:34] <Na3iL> stage 2, I stopped last night due to some important tasks, but I am going to play it again today :D
[08:35] <elacheche> I was stuck in there for 24h too, but the quizz dev gived me some hints, try again, if you can't findout what's wrong I'll share the hints with you..
[08:36] <Na3iL> Cool :D
[08:41] <elacheche> Na3iL: let's give that to MarwenDo as well :)
[08:41] <elacheche> MarwenDo: There is a nice It/SysAdmin quizz that you'll like to try :D → https://redd.it/4y46zb
[08:44] <Na3iL> He will like it indeed :D
[08:49] <MarwenDo> why i don't watch fails youtube video ?  haha :p
[08:50] <MarwenDo> at least i know how to navigate around :D
[08:52] <elacheche> Try the challenge MarwenDo :) it's a good one
[10:13] <elacheche> o/ nizarus :)
[10:13] <nizarus> ahla elacheche :)
[10:16] <nizarus> quoi de 9 ?
[10:16] <elacheche> Que des fêtes de mariage x) J'avance sur rien x(
[10:17] <nizarus> LooL oui c'est la saison :p
[10:17] <elacheche> yep