[12:04] <kiko> I got the failure notice
[12:04] <kiko> I'm just wondering what happened to the one I sent right after the failure
[12:05] <lifeless> 15:49
[12:05] <lifeless> it was recieved
[12:05] <kiko> and then?
[12:06] <lifeless> erm tz confusion
[12:06] <lifeless> let me just check
[12:06] <kiko> lifeless, never mind, I think -- let's see if this merge request goes through
[12:06] <lifeless> ok
[12:07] <kiko> salgado says it's me!
[12:08] <salgado> mpt, around?
[12:17] <bradb> daf: you removed findSourcesByName, right?
[12:18] <daf> bradb: yup
[12:18] <daf> bradb: trying to merge it now
[12:25] <bradb> daf: did rosetta explode? i'm getting several large (3M+) batch error log emails
[12:25] <bradb> from a quick scan of about 10% of the file, it looks like it might be something to do with table perms
[12:26] <daf> oo
[12:26] <daf> maybe stub changed some permissions
[12:27] <bradb> daf: are you getting the error emails?
[12:27] <daf> yep
[12:30] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Long list of little UI tweaks and fixes that I've been working on for a week. r=BjornT on most of it. Fixes bug 1127, bug 1123 and possibly bug 688. Initial fix for bug 676, more work required there (patch-2022: christian.reis@canonical.com, bjorn.tillenius@canonical.com)
[12:41] <kiko> T L!
[12:43] <kiko> wooooo
[01:01] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Require launchpad.Admin to the reassignment of teams. Otherwise team administrators will be able to change the owner of a team. (patch-2023)
[01:06] <lifeless> daf: can you please ask rosetta to not mail 3MB spam at me ?
[01:16] <kiko> hey 
[01:16] <kiko> does anyone know if you can apply multiple fmt: rules to the same string?
[01:18] <mdz> probably
[01:18] <mdz> the first fmt should evaluate to a string, noL
[01:18] <mdz> ?
[01:22] <kiko> yeah, that's how it looks here
[01:22] <kiko> my tests seem to say "it works"
[01:23] <kiko> my 1gig box is swapping, whee
[01:25] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Implements the karma framework (according to the KarmaImplementation spec) and hook it into Malone events. r=spiv,stub (patch-2024)
[01:31] <mpt> kiko: https://wiki.launchpad.canonical.com/PageTemplateHacking#head-193daf137ed8b89de36d47c3df5fd8f66c0e1d14
[01:33] <kiko> mpt, which are you pointing out to me
[01:33] <kiko> tables or lists?
[01:33] <mpt> tables
[01:33] <kiko> oh!
[01:33] <kiko> oh!
[01:33] <kiko> thanks!
[01:33] <mpt> specifically the bit about using <thead>
[01:35] <daf> lifeless: complain to stub
[01:36] <lifeless> daf: ?
[01:36] <kiko> mpt, thead and tbody are correct, right?
[01:36] <lifeless> daf: its not rosetta ?
[01:36] <daf> it is
[01:36] <mpt> kiko: correct
[01:36] <daf> but (a) stub controls the scripts and (b) I think it was him that broke it
[01:48] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Small fixes: move some functions (createPerson, personFromPrincipal and traverseTeam) to their right places and remove dead code from pofile-export.pt and potemplate-export.pt. r=SteveA (patch-2025)
[01:57] <mpt> * Searching for best merge point .../pqm/build_dir/thelove@canonical.com/thelove@canonical.com---bazaar--devo--1.5/src/baz/libarch/namespace.c:595:botched invariant
[01:57] <mpt>     !!version_end
[01:57] <mpt> baz: uncaught exception: -1:(exiting on botched invariant)
[01:57] <lifeless> mpt: its finished
[01:57] <lifeless> mpt: thats the second time I've seen that
[01:57] <lifeless> this is very strange, I'm smelling a regression
[01:58] <mpt> so it's fully merged?
[01:59] <mpt> it didn't list any modified files
[01:59] <lifeless> no
[01:59] <lifeless> its failed
[01:59] <lifeless> baz tree-id please
[01:59] <mpt> mpt@canonical.com/launchpad--devel--0--patch-84
[02:00] <lifeless> and baz msissing rocketfuel@canonical.com/launchpad--devel--0
[02:02] <mpt> lifeless: everything from rocketfuel@canonical.com/launchpad--devel--0--patch-2011 to -patch-2025
[02:02] <lifeless> thanks
[02:02] <lifeless> do a star-merge
[02:02] <mpt> yup
[02:04] <mpt> I'm assuming that, though star-merge works in ~90% of the cases where normal merge does not, it works in less than ~80% of the cases where normal merge does work ... otherwise why not use star-merge by default :-)
[02:05] <sabdfl> mpt: could you review a branch for me please, that has some new UI?
[02:05] <sabdfl> need it done today
[02:06] <mpt> sabdfl: sure, what branch
[02:06] <kiko> mpt, star-merge worked
[02:06] <kiko> for me when that happened
[02:06] <mpt> kiko: and it's just worked for me too
[02:07] <kiko> sabdfl, I just added auto-linkifying to malone for links and bugtext :-)
[02:07] <mpt> thanks
[02:08] <sabdfl> kiko: superb!
[02:08] <sabdfl> how do you guys like today's be landing? any conflicts?
[02:08] <mpt> be?
[02:09] <kiko> I landed like a baby today, only 8 conflicts :-P
[02:10] <mpt> like a defenestrated baby?
[02:12] <kiko> heh
[02:12] <kiko> Keybuk is such an australian timezoner
[02:12] <Keybuk> lies
[02:13] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Fixed 100% #1036 + test added (but useless as the whitespaces are ignored :-( ) (patch-2026: carlos.perello@canonical.com)
[02:13] <kiko> and rosetta is SUCH A SPAMMER!
[02:14] <kiko> 3.7MB OMG
[02:15] <lifeless> yes
[02:20] <mpt> so where's all this calendar?
[02:21] <mpt> I don't see links to calendars anywhere
[02:25] <kiko> mpt, click on the link to person12
[02:25] <kiko> or person16
[02:25] <kiko> one of the two have calendars
[02:26] <mpt> aha
[02:28] <mpt> So, people have calendars, not distros/releases/products yet
[02:28] <mpt> and I can add an event from the weekly/monthly calendar, but not from the daily/yearly calendar yet
[02:30] <kiko> maybe report bugs or write to jamesh cc launchpad-list
[02:31] <jamesh> mpt: products and projects can have calendars -- however the owner of the product/project has to create it
[02:31] <kiko> lifeless, can you please check if stub can work around the rosetta permissions problem that is spewing 3MB email every 5 minutes to me?
[02:31] <lifeless> kiko: me too
[02:32] <kiko> it's probably a set of grants and a slap on the wrist
[02:32] <kiko> but you know best
[02:42] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  use thead and tbody in assigned bugs page (patch-2027: christian.reis@canonical.com)
[02:46] <kiko> mpt, the spacing when using <li> is still not optimal, can you try tweaking it a bit?
[02:47] <kiko> the vertical alignment looks looks kinda fishy too
[02:47] <mpt> Yes, I think that's a problem with the GIFs
[02:47] <kiko> it's interesting that using the <img> tags it worked well, no?
[02:48] <mpt> Some of them have padding on the top and bottom, so when the browser arranges their "bottom" on the baseline, it looks wrong
 was just closer, I think
[02:48] <kiko> maybe
[02:48] <mpt> horizontally better, but not vertically better
[02:48] <kiko> fix that and rs=kiko
[02:49] <mpt> but I can fix that
[02:49] <kiko> I'll send you a screenshot
[02:50] <kiko> mpt, I'll also send you some tal changes to see if I'm doing the right thing or not in the portlets
[02:52] <kiko> mpt, sent
[02:52] <sabdfl> night all
[02:55] <kiko> night sab
[02:57] <jamesh> kiko: figured out the datetime bug you found
[02:59] <kiko> you are such a hacker
[02:59] <kiko> thanks a million
[02:59] <jamesh> the timezone name was unknown
[02:59] <jamesh> but it worked for mark and pqm because unknown timezones were treated as localtime, which happened to match :)
[03:00] <kiko> it's great when at least the owner can run tests successfully :-)
[03:01] <jamesh> so you can fix the problem by moving to sunny London
[03:03] <sabdfl> jamesh: i have a zinger of a datatime bug for you
[03:03] <kiko> good weather can't be expensed
[03:03] <sabdfl> kiko: cant be dispensed either
[03:03] <jamesh> sabdfl: oh?
[03:08] <sabdfl> jamesh: add a fmt:date to line 103 of templates/productseries-ubuntupkg.pt
[03:08] <sabdfl> now visit http://localhost:8086/products/evolution/+series/main/+ubuntupkg
[03:09] <sabdfl> and change the source package to something like pmount
[03:09] <sabdfl> boom
[03:09] <sabdfl> you get a security proxied thing in the result of a totally different query
[03:09] <sabdfl> i've tried flush_database_updates and object.sync()
[03:09] <sabdfl> with no joy
[03:10] <sabdfl> so... i just left the date unformatted, because that works (!)
[03:10] <jamesh> I'll check in a sec.  Just want to get this test fixed
[03:11] <sabdfl> jamesh: btw - very smooth landing of the calendar bits
[03:14] <jamesh> thanks
[03:19] <jamesh> sabdfl: the SQLConstant thing is almost definitely UTC_NOW
[03:20] <jamesh> when I reload the page after changing the packaging, it displays a valid date
[03:20] <sabdfl> jamesh: yes, but interestingly flush_database_updates does not convert it to a real sql object
[03:20] <jamesh> yeah
[03:21] <sabdfl> i was just amazed that it would come back like that through a totally different query
[03:25] <jamesh> sabdfl: problem seems to go away when I add a line "pkg.sync()  # convert UTC_NOW to real datetime" at lone 145 in database/productseries.py
[03:28] <sabdfl> jamesh: ah.... i tried it on line 152 and of course that's not the codepath for an update, but a create...
[03:28] <sabdfl> could you see if it's required for the create as well?
[03:28] <sabdfl> and fix-n-land with your next landing, no rush?
[03:28] <sabdfl> just slip it into whatever branch you are currently working on?
[03:29] <sabdfl> jamesh: and thank you!
[03:29] <sabdfl> now,.. night - for real!
[03:29] <kiko-zzz> heh
[03:30] <kiko-zzz> jamesh, is the issue SQLObject not invalidating the cached object state?
[03:31] <kiko-zzz> anyway
[03:31] <kiko-zzz> NIGHT
[03:35] <stub> SQLObject should be clearing its caches on commit, and I think this is being/has been fixed upstream 
[03:35] <stub> (not that I have any idea if this is relevant, having missed the start of the conversation)
[03:38] <jamesh> I think this is happening within a single transaction
[03:38] <jamesh> set new package (which sets date), then display results
[03:46] <jamesh> the create new packaging code path seems broken too (in a different way)
[03:55] <kiko-zzz> stub, any luck you can fix the permission issue generating 3MB email from rosetta? :-)
[03:55] <stub> kiko-zzz: In a tick ;)
[03:56] <kiko-zzz> heh
[03:56] <kiko-zzz> lifeless, is PQM busy? I've sent two merges and no output after a few hours...
[03:58] <lifeless> kiko-zzz: hung twisted process
[03:58] <kiko-zzz> aha
[03:58] <lifeless> killed
[03:58] <kiko-zzz> thanks
[03:58] <lifeless> lunchtime
[03:58] <lifeless> bbiab
[03:58] <kiko-zzz> tell this twisted dude to stop hanging
[03:58] <kiko-zzz> gone for good
[03:59] <jamesh> kiko-zzz: he's on leave
[03:59] <jamesh> :)
[03:59] <stub> Someone should review that autokill the tests patch I put in...
[05:26] <debonzi> hi stub 
[05:27] <stub> debonzi: Hi
[05:28] <debonzi> stub, did you get the patch I did for your gina branch?
[05:28] <dilys> New Malone bug 1246 filed on product The Launchpad by Matthew Paul Thomas: Events only addable from week/month views, not day/year
[05:28] <dilys> https://launchpad.ubuntu.com/malone/bugs/1246
[05:28] <stub> debonzi: Yes - looks good. Do you want to stick it in the review queue or should I?
[05:29] <mpt> jamesh: What is the relationship between launchpad/lib/schoolbell/ and upstream schoolbell? Will they be merged regularly?
[05:29] <stub> debonzi: Or maybe we should just commit it rs=kiko ;)
[05:30] <mpt> dilys, you forgot bug 1244 and bug 1245
[05:30] <debonzi> stub, just the same for me.. as you prefer.. may be it is easy for you since you can commit on your branch and I can't
[05:30] <debonzi> stub, hehe.. I like this rs=kiko :)
[05:30] <jamesh> mpt: it is a fork at the moment that needs to be merged.  Once we have subversion syncing working, it should be a proper bazaar branch off the mainline
[05:31] <stub> debonzi: oh - I thought you would have created a local branch in your own archive. I'll merge your patch and chase it through to rocketfuel.
[05:31] <debonzi> stub, no, I worked in your branch
[05:32] <debonzi> stub, maybe you want to change/remove the modification I did on launchpad.conf
[05:33] <debonzi> stub, are you going to setup this "version" on staging/production or are you going to use the "old" gina?
[05:33] <stub> debonzi: We need something there for documentation, even if it is specific to your workstation. This can be removed when we have a proper Gina functional test (which will pull its config out of the <canonical testrunner> section)
[05:33] <stub> debonzi: I was going to run with this version against staging, and then production if people think its updates are sane. I don't know anything about old gina.
[05:35] <debonzi> stub, uhmmm .. I think I was not clear :) this version = your branch ; old gina = gina before your changes 
[05:36] <stub> debonzi: oh. I will run this version. I suspect the old version will generate too much noise to be useful. With the new version, I can run it with '-q' and ony the warnings get reported (and I can switch it to '-v' if things are screwing up and people need to see the debugging output).
[05:37] <debonzi> stub, thats cool for me.. your changes realy rocks :)
[05:38] <debonzi> stub, and how do you want to coordinate that? will you take responsability off it?
[05:38] <stub> Should it run now against the staging database? old gina died due to missing distro releases or something, and I'm not sure if these need to be created manually by somebody or if gina handles all that.
[05:39] <debonzi> stub, right... good point
[05:39] <stub> debonzi: I'll give it another run. If it looks like it needs more tweaking, I'll enable access to the staging database from gina@macquarie and hand it over to you and/or salgado to get going.
[05:40] <stub> debonzi: All production code will be the joint responsibility of myself, lifeless and salgado once we have gangotri and launchpad.net all sorted.
[05:40] <debonzi> stub, gina just creates: people and emails (maintainers), sourcepackage and binarypackage names, sourcepackagerelease, build, binarypackage, sourcepackagepublishinghistory, packagepublishinghistory, source and binarypackage files
[05:41] <debonzi> stub, she needs:
[05:42] <stub> debonzi: ok. We will need somebody to setup any missing distributions or distroreleases. I suspect Kinnison will be designated victim for this, unless you know enough about the Ubuntu distro to do it.
[05:42] <debonzi> the distribution, distrorelease, the distroarchreleases, the components, processor and processorfamily
[05:42] <stub> Or sabdfl
[05:43] <debonzi> stub, does he (Kinninson) have access to do that?
[05:43] <stub> debonzi: I think he is a Launchpad administrator, and I can make him one if he isn't already.
[05:43] <stub> debonzi: Although I'll need to do anything that there is no web UI for.
[05:44] <stub> debonzi: I could hack it up, but I'd rather get the descriptions, owners, maintainers etc. all sorted correctly because it is important to Mark.
[05:45] <debonzi> stub, thats what I was writing to you about get me creating this stuff... but you are faster than me :)
[05:45] <stub> debonzi: We should be able to get gina going for at least one distrorelease though - everything should be setup for Hoary already. 
[05:46] <debonzi> stub, thats true... I think before cape town, salgado was working on that and created this stuff.
[05:46] <debonzi> stub, for hoary
[05:48] <stub> ok. I think I have enough to run with for now. I'll merge your patch and chase it through to Rocketfuel. You will need to write at least one test for the gina script (by setting up a miniature distro mirror in scripts/ftests/gina_test_archive or something) and running it.
[05:49] <stub> debonzi: Either branching off my archive or rocketfuel if I can get it in today.
[05:50] <stub> debonzi: This will involve setting up a <gina> section in the <canonical testrunner> part of launchpad.conf, which the test runner will use automatically. It might also need you to make Gina handle relative paths to the archive root properly.
[05:51] <debonzi> stub, ok I will take care of it..
[05:52] <debonzi> stub, but I am not sure about the test itself.. would the test be just a call to the gina script using the launchpad.conf section and the miniature distro mirror
[05:52] <debonzi> ?
[05:54] <stub> debonzi: Yes. subprocess.Popen([sys.executable, 'gina.py', 'porky'] , stdout=PIPE, stderr=PIPE).
[05:54] <debonzi> stub, cool... 
[05:54] <stub> debonzi: p.wait() for the process to terminate, p.returncode to check for major errors, ensure output is empty or contains the warnings or errors you expect to be triggered
[05:55] <stub> ok
[05:55] <stub> err. p.communicate() is better for this...
[05:55] <stub> whatever )
[06:00] <mpt> arrrrrrr, crap
[06:01] <debonzi> stub, ok.. I think I got it... again about the gina production run, something else I can do to help? can you check with Kinninson and/or mark about the distro,distrorelease,distroarchreleases production setup?
[06:02] <stub> I will chase that up with Kinnison and Mark when they come online this afternoon.
[06:03] <stub> But don't worry, I'm sure there will be bugs for you to fix ;)
[06:03] <debonzi> stub, as you cold see, kiko is in our back and It will start blocking people
[06:03] <debonzi> stub, yes.. I think she is a bug :)
[06:12] <debonzi> stub, well, I will get some sleep because a realy need it.. please, every problem I got from gina (I hope you get none) report to me.. 
[06:13] <stub> debonzi: Yup. No problem.
[06:13] <debonzi> stub, thanks dude.. 
[06:40] <stub> lifeless: PQM is dead
[06:41] <lifeless> checking
[06:41] <lifeless> oh wow
[06:41] <lifeless> it really is
[06:42] <lifeless> nukified
[07:12] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  linkify assignee's name in the bug task headlines (patch-2028: christian.reis@canonical.com)
[07:37] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [rs=stub]  Remove cruft from our Makefile; I should note I added a 'schema' shortcut target a while back (patch-2029)
[08:07] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  use rfc2822 date format to fix test failure (patch-2030: james.henstridge@canonical.com)
[08:24] <SteveA> stub: morning
[08:26] <stub> SteveA: Morning
[08:26] <SteveA> i tracked down a bug in sqlos / sqlobject yesterday
[08:27] <SteveA> where when an sqlobject transaction is GCed, it will often clear the in-progress transaction's stuff out of the object cache
[08:28] <SteveA> look at the "rollback" method of 
[08:28] <SteveA> Transaction, sqlobject/dbconnection.py
[08:28] <SteveA>         for subCache, ids in subCaches:
[08:28] <SteveA>             for id in ids:
[08:28] <SteveA>                 inst = subCache.tryGet(id)
[08:28] <SteveA>                 if inst is not None:
[08:28] <stub> SteveA: I think this has been discussed on the mailing list recently. The fix is to make commit() clear the caches.
[08:29] <SteveA>                         # so, we get an instance from this transaction's
[08:29] <SteveA>                         # cache.  then we tell the instance to expire itself.
[08:29] <SteveA>                         # The instance is from this dying transaction.
[08:29] <SteveA>                         # But, the instance will get hold of the current
[08:29] <SteveA>                         # connection to expire itself by its id.  So, it will
[08:29] <SteveA>                         # be expiring an equivalent object in the current
[08:29] <SteveA>                         # transaction's cache.
[08:29] <SteveA>                         #
[08:29] <SteveA>                         # To fix, consider in sqlos that once the connection
[08:29] <SteveA>                         # descriptor has been used on an object, that object
[08:29] <SteveA>                         # will always be associated with that connection.
[08:29] <SteveA> so, i'd say the fix is to write the connection to the instance the first time it is used with that instance.
[08:30] <SteveA> as, i don't know what other cases there are of an object being used with an inappropriate connection
[08:31] <SteveA> but, the thread-bound connection descriptor that sqlos uses is prone to such bugs
[08:32] <SteveA> making commit() clear the caches would not be enough anyway.  rollback() would need to clear the caches too, and you'd always need to do an explicit commit or rollback before a transaction gets GCed
[08:33] <SteveA> i believe my proposed fix is more robust.
[08:33] <stub> http://sourceforge.net/mailarchive/forum.php?thread_id=7559932&forum_id=30269
[08:33] <stub> http://sourceforge.net/mailarchive/forum.php?thread_id=7559933&forum_id=30269
[08:34] <stub> rollback already does clear the caches. Not clearing them in commit is a bug (IMO, and will probably be fixed this way upstream if it hasn't already)
[08:37] <SteveA> the issue is more one of threading
[08:37] <stub> Your fix would help the situation where you 'lose' a transaction without committing it or rolling it back (and in this case, you should bitch loudly!)
[08:37] <SteveA> if the commit or rollback occurs in a different thread than the transaction was operated in
[08:38] <SteveA> then the wrong objects will be uncached
[08:38] <stub> SteveA: That is a bug - I don't think you should be sharing transactions across threads (?)
[08:39] <SteveA> so, for sqlos, making a transaction bound to an object once that object has been used with that transaction, avoids all such ambiguity
[08:39] <SteveA> the code in dbconnection makes an assumption
[08:39] <SteveA> it assumes that when it gets an object, and calls that object's expire() method
[08:39] <SteveA> that the object will expire itself
[08:39] <SteveA> right now, that is the assumption that is broken
[08:40] <SteveA> the object will expire the object with that classname and id from the cache of the current transaction
[08:40] <SteveA> not of the transaction the object was used in
[08:40] <SteveA> one fix for exactly this to to allow the transaction to be given in object.expire()
[08:40] <SteveA> another fix is to ensure that an object always talks to the same transaction
[08:40] <stub> An SQLObject instance will only get used with one transcation anyway (?)
[08:41] <SteveA> yeah, right
[08:41] <SteveA> not when sqlos is in the mess^Wmix
[08:41] <stub> That is the bug then.
[08:41] <SteveA> sqlos replaces the class-level connection object with a thread-local-style connection-lookup descriptor
[08:42] <SteveA> so, the object will be used with whatever transaction is associated with the current thread
[08:42] <stub> Yes, but the cache is part of the connection, so objects cannot be pulled out of another threads cache
[08:42] <SteveA> that sentence doesn't add up
[08:43] <SteveA> yes, the cache is part of the connection
[08:43] <SteveA> but, an sqlos object can have an inappropriate ._connection
[08:43] <SteveA> when it is accessed outside of the thread it was first used in
[08:43] <stub> How do you do that?
[08:43] <SteveA> or outside of the normal transaction boundary it was first used in
[08:44] <SteveA> in GC
[08:44] <SteveA> or, in the case of various errors that people might make
[08:44] <SteveA> such as keeping objects around between transactions / sharing them accidentally among threads
[08:44] <SteveA> you can get objects with the wrong state associated with a transaction
[08:44] <stub> So you forgot to call commit() or abort() in your thread (trying to rollback in the __del__ method is the real breakage IMHO)
[08:45] <SteveA> yes, that is one case
[08:45] <stub> ok. I don't think the fix is to try and cope though. I think the fix is to bitch loudly and raise an exception.
[08:45] <SteveA> i agree
[08:45] <SteveA> the current case is not to try and cope
[08:45] <SteveA> the current behaviour is to happily remove another object from a different transaction from the cache
[08:46] <SteveA> what i am suggesting is not "coping"
[08:46] <SteveA> it is ensuring that an object does't shit over other transaction's caches
[08:47] <SteveA> to do that, i'd change sqlos's connection descriptor to write the connection to the instance the first time it is used with that instance
[08:47] <SteveA> interestingly, this will also speed things up a little
[08:48] <SteveA> i consider this orthogonal to fixes in sqlobject to ensure the cache is cleared on commit
[08:48] <SteveA> and any refactoring to remove __del__
[08:48] <SteveA> then, when you can reliably identify the transaction an object is associated with
[08:49] <SteveA> you can raise errors if that object is used when its transaction is no longer the current one
[08:49] <SteveA> right now, such errors are not straightforward to detect
[08:49] <SteveA> because an object "pretends" it is part of whatever the current transaction is
[08:49] <stub> If we replace the objects _connection with a real reference, when the transaction is committed what stops that instance continuing to use the same transaction? Is the transaction invalidated on commit/rollback? Or is the same one kept in use?
[08:50] <SteveA> it is invalidated
[08:50] <SteveA> the transaction's _obsoete flag is set
[08:50] <SteveA> and guards at each method ensure it can no longer be used
[08:50] <SteveA> exactly appropriate "complaining loudly" behaviour
[08:51] <SteveA> and complaining with a useful message
[08:51] <stub> I think we also need to fix commit to nuke the caches though or else any instances left around for garbage collection are going to bitch in their __del__ methods.
[08:51] <stub> Because they cannot rollback, because their transaction is obsolete
[08:51] <SteveA> yeah, that's fine.  but that's orthogonal to the issue i'm trying to get your support on ;-)
[08:52] <SteveA> also, it's an sqlobject issue, and i'm talking about an sqlos issue.  although, it wouldn't be a bad thing to make sqlobject bind objects with the transaction they were first used in
[08:52] <lifeless> heres a square rule
[08:52] <stub> I agree that replacing the instances _connection is a good idea. We might lose some functionality, but I would call it dangerous functionality (being able to reuse an instance across transactions and/or threads)
[08:53] <SteveA> that is not supported in sqlobject's model
[08:53] <SteveA> it is supported in the zodb, btw
[08:53] <SteveA> because the zodb has richer and better-defined semantics for when an object needs to get new state
[08:54] <SteveA> but, has lead to "George Bailey" objects
[08:54] <SteveA> which was one of the more entertaining ZODB developers discussions
[08:54] <stub> It is supported in SQLObject I think, provided your underlying database api does (such as psycopg). Probably not thread safe through without locking.
[08:54] <SteveA> okay, cool.
[08:55] <SteveA> it cannot be supported, because of how the caches work
[08:55] <SteveA> it cannot be supported because of what i'm describing.
[08:55] <lifeless> stub: I notice you went with pound, even after my extra data on the wiki :[
[08:55] <SteveA> maybe it was designined in there, in a half-arsed way
[08:55] <stub> Your extra data on the wiki?
[08:55] <lifeless> stub: I updated the wiki page you put up with specifics for squid
[08:55] <stub> SteveA: Nah - it would have been purely by accident ;)
[08:55] <SteveA> but, it is quarter-arsed support
[08:56] <SteveA> okay, so plan: make an object bound to the connection it is first used in.  make caches get cleared on commit.
[08:58] <jamesh> stub: I suppose it would be a bad idea to make the test suite pick a random time zone for each run ...
[08:58] <SteveA> random ain't good in tests
[08:58] <SteveA> just ask tom lord
[08:59] <jamesh> just so long as we don't end up with tests that only pass in Calcutta.
[08:59] <stub> jamesh: I would support randomly choosing between Asia/Calcutta and Pacific/Pitcairn. Fully random has a chance of getting your current timezone ;)
[09:00] <stub> SteveA: Random test environment in an attempt to ensure things are environment neutral
[09:00] <jamesh> Pitcairn Island is where they molest children, right?
[09:00] <stub> jamesh: That is the one
[09:01] <SteveA> stub: no randomness in tests.
[09:01] <SteveA> if we need to do that, run the tests twice
[09:01] <SteveA> once in each timezone
[09:01] <SteveA> but don't introduce randomness
[09:01] <SteveA> unless you set the seed first ;-)
[09:03] <stub> SteveA: We already have randomness - every developer runs in a subtly different environment.
[09:04] <stub> But I suspect running tests in a known timezone is good enough - it doesn't really matter if they are timezone specific tests, as long as the tests always run in that timezone
[09:04] <SteveA> that is not randomness.  that is stable, but different in multiple locations.
[09:04] <SteveA> we have randomness due to python's GC, though
[09:05] <SteveA> but that only hurts when there's a bug in sqlobject, or other similar things.
[09:07] <lifeless> jamesh: do I have r=jamesh without mucking with that iterator foo ?
[09:07] <jamesh> lifeless: yes.
[09:08] <lifeless> btw you missed a PEP8 violation ;)
[09:08] <lifeless> the sortedDictIterator's docstring was multiline - the ending """ should be on a line of its own
[09:09] <lifeless> how is this for a docstring ?
[09:09] <lifeless> Topologically sort a list of dicts by the length of a a keyfield and provide an iterator to the result.
[09:09] <jamesh> sounds good.
[09:10] <lifeless> ok, can I ask a small favour ?
[09:10] <jamesh> sure
[09:10] <lifeless> can you review the patch robert.collins@canonical.com/cscvs--devel--1.0--patch-366 
[09:10] <lifeless> its mingled with the same branch - my bad - which is why its a favour that I am asking
[09:13] <lifeless> jamesh: also, your patch for added files is applied to mainline courtesy of matthieu moy
[09:13] <lifeless> stub: btw, rosetta script is triggering permissions
[09:13] <lifeless> 3Mb emails are not cool. 
[09:13] <SteveA>  the length of a a keyfield
[09:14] <SteveA> two "a" s
[09:14] <stub> lifeless: It still happening? I fixed a permission issue for Carlos earlier.
[09:14] <jamesh> lifeless: I'll get to the patch in a bit -- I've got some others I'm working on right now.
[09:15] <lifeless> stub: as of 1652 yes
[09:15] <lifeless> jamesh: thanks
[09:16] <lifeless> SteveA: good catch
[09:16] <jamesh> stub: just looking at your branch testrunner branch.  I think it could easily deadlock while reading from the test script
[09:16] <jamesh> since it is doing blocking reads
[09:17] <stub> jamesh: That code is the same as the mechanism the subprocess module does it. If you do foo.read() it will block. If you do read(foo.fileno(),1024) it won't. 
[09:17] <stub> I think :-)
[09:23] <SteveA> lifeless: does it give a particular topological sort, where there's more than one possible sort?
[09:25] <jamesh> stub: you are right
[09:26] <lifeless> SteveA: uhm
[09:26] <SteveA> just curious
[09:27] <lifeless> SteveA: the interface is a topological sort
[09:27] <lifeless> the implementation is key-length
[09:31] <jamesh> "The main use for this is to keep the pqm queue flowing without having to give it a lifeless enema."
[09:31] <stub> lifeless: fixed one more permission. No idea if it is the last one. *sigh*
[09:32] <dilys> New Malone bug 1248 filed on product Registry by Morgan Collett: Bugs in RDF output
[09:32] <dilys> https://launchpad.ubuntu.com/malone/bugs/1248
[09:32] <lifeless> jamesh: there are multiple deadlocks in the codebase
[09:32] <lifeless> jamesh: droopped connections to the local cvs in the tests, librarian connection issues, observed.
[09:32] <jamesh> SteveA: the result is a topological sort of a set of path names.  It does it by sorting by string length, which works because the parent path name is always shorter than its children
[09:33] <SteveA> i see
[09:33] <jamesh> lifeless: I just found stub's comment a little funny
[09:34] <stub> lifeless doesn't find enemas funny - just a lifestyle choice
[09:34] <lifeless> stub: giving them is funny
[09:35] <SteveA> so you can get variable output depending on in what order the dict returns its items, when you have multiple keys of the same length.
[09:35] <lifeless> SteveA: right. and thats fine.
[09:36] <stub> We have been on the public channel for 1 day and we are already discussing enemas.
[09:44] <lifeless> stub: your code won't fix the hangs
[09:44] <lifeless> stub: it needs to go into pqm, not launchpad.
[09:48] <stub> lifeless: What is the issue? Are the tests completing but PQM doesn't realize it or something?
[09:48] <lifeless> stub: there are three I've seen
[09:48] <lifeless> two are hangs in the test suite - one in the cscvs test suite, one in the lp test suite, and the third is the test suite dying off but leaving a stale process that is never reaped
[09:49] <lifeless> basically the lp test runner is too deep in the stack
[09:51] <stub> ok. I thought cscvs was being run from test_on_merge.py, but I see that isn't actually the case
[09:52] <SteveA> when i interrupt a test run, i often get a twistd process sitting around
[09:53] <lifeless> right
[09:53] <SteveA> any way to fix this?
[09:53] <lifeless> teach pqm to watch for output for 10 minutes, then kill all elements of the process group
[09:53] <lifeless> should be much the same as the code stub wrote for the testrunner
[10:23] <carlos> morning
[10:24] <jamesh> lifeless: is there a more efficient way of getting the changes between two revisions of a branch than the commands I list at the end of this page? https://wiki.launchpad.canonical.com/TipsForReviewers
[10:24] <jamesh> lifeless: the idea being to ignore merges from rocketfuel, and compare what the two different revisions look like merged to rocketfuel
[10:31] <stub> lifeless: pqm has hung
[10:33] <jamesh> on the subject of detecting test suite hangs, since the launchpad test suite doesn't print anything til it completes (both with and without stub's testrunner patch), pqm can't just check its stdout/stderr to detect whether it has hung or not
[10:34] <stub> jamesh: You can if you set the timeout to 40 mins or their abouts...
[10:34] <stub> (suboptimal, but still fulfills the basic requirements)
[10:34] <jamesh> stub: sure, but it would be nice to have a shorter timeout than that
[10:35] <stub> yup
[10:35] <jamesh> you only want to kill the suite if things stop happenning; not if it takes longer than expected to run
[10:35] <jamesh> (I think)
[10:35] <stub> We could redirect test output to stdout, then generate the end-of-test report to stderr. Might be best (?)
[10:38] <stub> jamesh: You didn't include a review in that message regarding Scott's branch
[10:47] <carlos> stub, I suppose I don't need to subscribe to the new topics you add if I didn't select any topic ever, right?
[10:47] <carlos> I mean, I should get all mails by default
[10:47] <stub> carlos: That is correct. If you really want that much spam ;)
[10:48] <carlos> stub, well, atm we (Rosetta) are the kings of SPAM
[10:48] <carlos> so it's not a big issue, we are going to improve the log output so it gets reduced, but until that moment...
[10:49] <lifeless> stub enemad
[10:57] <jamesh> stub: there wasn't really anything to review.
[10:57] <stub> jamesh: ok. it just read like there was supposed to be one ;)
[10:58] <jamesh> stub: it was all conflicts (a lot of them being due to fixes on Mark's branch from my previous review)
[11:03] <sabdf1> mpt: thanks for the review
[11:06] <mpt> a pleasure, sir
[11:07] <sabdf1> mpt: good?
[11:07] <jamesh> mpt: was it any good?
[11:07] <jordi> sabdf1: I just sent that mail.
[11:07] <mpt> It was better than ID4, which it most resembles
[11:07] <jordi> morning folks
[11:08] <lifeless> great movie, shame they fucked the plot
[11:08] <mpt> (in my *extremely* limited movie-viewing experience)
[11:08] <sabdf1> jordi!
[11:08] <jordi> mpt: is ID4 "Independence Day"?
[11:08] <mpt> jordi: yes
[11:08] <lifeless> jordi: yes
[11:08] <jordi> mpt: I blogged about that one yesterday. So funny. :)
[11:08] <jordi> sabdf1: hey mark
[11:09] <mpt> The ending was rushed
[11:09] <jordi> I haven't funny recovered from the early rise on Monday -- Stansted is *very* far away! I really need a nap...
[11:09] <jordi> I love when POTUS in person saves our asses.
[11:11] <carlos> jordi, morning
[11:11] <SteveA> i saw WOTW in sweden.  imo, the suckiest film i've seen in ages.  nice special effects, though.
[11:11] <ddaa> SteveA: even worse that THGTTG?
[11:12] <ddaa> 'cause _that_ was baaaaaad...
[11:12] <mpt> deus ex machina!
[11:12] <mpt> That's what was wrong with WOTW, it was a big deus ex machina.
[11:12] <jordi> carlos: hola
[11:12] <mpt> dammit
[11:12] <jordi> carlos: when is "keys day", again?
[11:12] <jordi> today?
[11:13] <Kinnison> h2g2 was fantastic
[11:13] <carlos> jordi, no, tomorrow
[11:13] <Kinnison> ddaa: I think that you simply haven't grown up with h2g2 in your national psyche and as such you don't understand why it is so good
[11:13] <carlos> jordi, I will try to prepare a lunch on Saturday there with some friends, If I get a table and some chairs... do you want to come?
[11:14] <stub> Kinnison: How well do you know Gina? 
[11:14] <jordi> carlos: will be flying to .fi :/
[11:14] <carlos> oh, right!
[11:14] <ddaa> Kinnison: I have been a h2g2 fan for years, although maybe my experience is a bit limited by being restricted to the novels.
[11:14] <carlos> jordi, have fun then ;-)
[11:14] <jordi> carlos: I was going to propose another day, but my nights are pretty busy this week.
[11:14] <carlos> jordi, well, I only have thursday and Friday night...
[11:14] <jamesh> ddaa: you need to realise that h2g2 has been subtly different in each incarnation, so the fact that the movie differed from the books a bit isn't necessarily bad
[11:15] <jordi> today I invite some people for dinner, tomorrow I'll go to the cinema with beln and on Friday I should be busy packing
[11:15] <ddaa> jamesh: no problem with that.
[11:15] <ddaa> jamesh: my problem is about the movie being a BAD movie on its own merits.
[11:15] <carlos> jordi, btw, will I meet Belen ever?
[11:15] <carlos> ;-)
[11:15] <jamesh> ddaa: okay ;)
[11:16] <mpt> ddaa: How good it is on its own merits doesn't matter, if it has a large target audience who are going to see it because it's a variation on the theme they know well
[11:17] <jordi> carlos: I guess. :)
[11:17] <jordi> a few Canonical people did already. :)
[11:17] <carlos> jordi, really?
[11:17] <jordi> sure, she was in London
[11:17] <ddaa> mpt: that it matters or not, does not matter, really :) I was just asking how bad WOTW was is comparison to h2g2, which prompted this discussion about whether h2g2 was really bad or merely sucky.
[11:18] <jordi> ask mdz, we went out with him.
[11:18] <carlos> jordi, dude, I will not forget that, we live in the same city! ;-)
[11:18] <jordi> la la la
[11:18] <jordi> Quim knows her too. :)
[11:19] <Kinnison> stub: pretty well
[11:19] <mpt> ddaa: So you're asking people whose judgement you have good reason to doubt :-P
[11:19] <Kinnison> stub: although I notice you and debonzi have been making more changes to her
[11:19] <ddaa> mpt: right
[11:19] <ddaa> Ya
[11:19] <ddaa> Ya all suck!
[11:20] <daf> mpt: you could equally argue that its own merits are even more important as it is a reworking of an existing plot and the audience will want it to live up to its predecessors :)
[11:20] <Kinnison> A lot of people don't realise that the film was meant to be the definitive plot rework by Adams
[11:21] <Kinnison> I.E. it is the story as he wanted to tell it
[11:21] <stub> Kinnison: She is trying to read debian-installer/Packages.gz that doesn't exist. I just stuck an 'if os.path.exists' in there but don't know if that will cause other failures.
[11:21] <mpt> Well, I've listened to the WOTW radio play, and the movie is completely different, it's not really worth comparing them.
[11:21] <ddaa> Kinnison: I guess the poor lad was getting senile or something.
[11:22] <daf> senile? he was 49 when he died!
[11:23] <ddaa> that's a bit premature for being senile, indee
[11:23] <Kinnison> stub: that certainly sounds like what I would have done
[11:24] <Kinnison> stub: essentially everything is keyed off what she reads from those Packages.gz files
[11:24] <Kinnison> stub: and the d-i ones are "additional"
[11:25] <stub> Oh joy! There is some Zopeless stuff in there too ;)
[11:26] <Kinnison> Well, she is a zopeless script
[11:27] <stub> Kinnison: The DB-API level stuff isn't ;)
[11:28] <Kinnison> stub: Remember she has to connect to two different dbs
[11:28] <Kinnison> stub: But the KatieDB stuff is pretty irrelevant for us right now
[11:28] <Kinnison> we don't need it to do the imports we need currently
[11:28] <stub> Kinnison: Yup. Sorted that. I was just surprised ;)
[11:30] <stub> Kinnison: I expect that she will need some distributions, distroreleases, architectures, components and whatnot created on the production system. Are you designated victim for that?
[11:30] <Kinnison> stub: *nod*
[11:30] <Kinnison> stub: I guess so, I'll need access to an appserver to do that though won't I? (the UI isn't in place for it I don't think)
[11:32] <stub> Kinnison: I have no idea about the UI. Access can be arranged - I expect it will be simpler for you do do it directly rather than via me? Or better yet, do it on staging and cut & paste the the statements into a script to run on production?
[11:33] <Kinnison> Sure, staging sounds sane
[11:33] <stub> Kinnison: I can give you access to the database from your mawson account.
[11:33] <Kinnison> stub: that'll be grand
[11:34] <Kinnison> stub: I'll construct a script to run and then punt it over to you
[11:35] <Kinnison> stub: I'll need the commandline to run on mawson though since I'm not sure about remote pgsql connections
[11:36] <daf> psql -h asuka.ubuntu.com -U ro launchpad_staging
[11:36] <Kinnison> ro?
[11:36] <daf> read only
[11:36] <stub> lifeless: pqm has hung (22759 pqm       16   0     0    0    0 Z  0.0  0.0   0:00.01 make <defunct>)
[11:37] <stub> Kinnison: What is your unix username again?
[11:37] <daf> yay pqm
[11:37] <Kinnison> stub: dsilvers
[11:37] <lifeless> killed
[11:38] <Kinnison> daf: won't read-only mean I can't even test the inserts in a transaction though?
[11:38] <daf> dunno, ask stub
[11:38] <carlos> SteveA, sabdf1, stub we need gettext installed into production server or the .mo exports fail
[11:39] <carlos> do you know if he will be available today?
[11:39] <sabdf1> elmo's moving today
[11:39] <stub> Kinnison: psql -d launchpad_staging -U dsilvers -h asuka.ubuntu.com
[11:40] <carlos> hmm, right, I forgot that :-(
[11:40] <carlos> sabdf1, ok
[11:40] <Kinnison> stub: yep, that seems to be good
[11:40] <carlos> thanks
[11:40] <Kinnison> stub: I'll do everything inside a transaction to keep it clean
[11:40] <sabdf1> stub: can you install packages on macquarie?
[11:40] <stub> Kinnison: You have write access to staging. Let me know if you screw it - I can reset the db (but it will take staging out for an hour)
[11:41] <stub> sabdf1: Nope
[11:41] <Kinnison> stub: noted
[11:41] <carlos> sabdf1, lifeless We have xchat and xchat2 products in launchpad. I think both should be merged as are the same...
[11:41] <daf> I asked elmo to install it on macquarie when I asked him to install it on staging
[11:41] <Kinnison> stub: I have no access to things like processorfamily
[11:41] <daf> I guess there was a mixup
[11:43] <stub> We will need it on asuka, macquarie, gangotri and mawson at a minimum. Possibly emperor too if it is required for build.
[11:43] <carlos> daf, I think production is not on macquarie anymore. lifeless told me that we are moving into a clustering mode or something like that
[11:43] <carlos> stub, only at runtime
[11:43] <carlos> stub, for build we use an internal copy of gettext
[11:43] <carlos> stub, https://launchpad.ubuntu.com/errors/showEntry.html?id=1120642938.830.514391828289
[11:43] <daf> carlos: arg, that could be it
[11:43] <stub> Production is still on macquarie until elmo has time to sort the next steps of migration to gangotri
[11:43] <daf> stub: it's not required for build
[11:43] <carlos> stub, ^^^ Any idea to fix that?
[11:43] <Kinnison> stub: I'll need fairly unrestricted access to make sure I hit all the right tables
[11:43] <daf> stub: it is listed on the Launchpad dependencies page
[11:44] <Kinnison> stub: can you manage that easily, or do you need a list of tables from me?
[11:44] <stub> Kinnison: You should have access to everything... hang
[11:45] <stub> carlos: yes. Don't use selectOne if the query might return more than one result. Fix your where clause or use normal select and handle it returning 16000 rows.
[11:45] <Kinnison> stub: Also, what "person" should be owning all of this?
[11:45] <carlos> stub, the selectOne is not used in my code
[11:45] <stub> Kinnison: I have no idea. That was one of the things I was hoping you might be more familiar with ;)
[11:46] <Kinnison> stub: Do we have a "nobody" type person?
[11:46] <carlos> ok, it is
[11:46] <stub> carlos: Then the code you are relying on is broken. Still needs to be fixed the same way.
[11:46] <carlos> stub, but it should not get more than one row
[11:46] <carlos> sorry, I looked at it yesterday
[11:47] <stub> Kinnison: Nope - everything that can be owned should be owned by something sane. We can create groups, but the owner of the distros and distroreleases should probably be Mark for now.
[11:48] <Kinnison> So at some point we'll go through everything owned by Mark?
[11:48] <stub> Kinnison: What do you need to create besides the DistroReleases that have an owner?
[11:49] <Kinnison> processor families, processors
[11:49] <Kinnison> distributions
[11:49] <Kinnison> distroarchrelease
[11:49] <stub> Kinnison: They have owners??? Yech - I have *no* idea who/what should own them :-(
[11:51] <Kinnison> Well, right now I can't even select from person
[11:51] <Kinnison> or distribution
[11:51] <stub> I can't think of a reason why processor families or processors should have an owner, or even what it would mean if they have one. I suspect these will need to have their owner set to 'admins' and we drop the owner columns after clarification with Mark.
[11:51] <Kinnison> so I'll see what I can come up with, once I can read the data
[11:51] <stub> Kinnison: I'll sort your perms now
[11:51] <jamesh> daf: your daf@c.c--2004/launchpad--trivial--0 branch has been sitting in merged-conditional state for a long time.  Is there anything that needs to be done before you can merge it?
[11:52] <daf> jamesh: Steve pointed out a bug in the algorithm -- I should probably just take it out of the queue
[11:52] <daf> until I have a fix for it
[11:52] <daf> SteveA: I believe you had a suggestion for a better fix
[11:52] <carlos> stub, isn't this method correct?: https://chinstrap.ubuntu.com/~dsilvers/paste/filefYmv0s.html
[11:52] <SteveA> fix to what?
[11:52] <stub> Kinnison: Argh... I know. I needed to reset staging after PQM accepted my patch. Which it hasn't done yet. I'll get back to you.
[11:53] <daf> SteveA: this is to do with the tab escaping code
[11:53] <Kinnison> stub: Right, so when will that be? 2h? 3h?
[11:53] <carlos> stub, with that code is impossible that we get more than one ProducRelease, right? or am I missing anything?
[11:53] <daf> SteveA: you pointed out that it it wouldn't round trip properly if you had an odd number of backslashes
[11:53] <jamesh> daf: I think Steve's explanation made sense (that only "[tab] " and "\[tab] " are important)
[11:54] <jamesh> daf: so not highlighting the extra backslashes is fine
[11:54] <SteveA> daf: we discussed a new method of escaping, using [[tab] ]  or [[[tab] ] ]  and a way of using regular expressions + a simple function to match it
[11:54] <SteveA> jamesh: the existing \[tab]  thing is lossy :-(
[11:54] <daf> right, so I should merge that branch and change the escaping method later?
[11:54] <stub> carlos: That code is broken. There is no product.id == productseries.product, or productrelease.productseries == productseries.id
[11:55] <carlos> stub, then we have more code broken inside vocabularies
[11:55] <SteveA> daf: yeah, i think we need to change the escaping method, and what we intend to do should be written up somewhere.
[11:55] <SteveA> daf: but it is good to merge the current improvements now.
[11:55] <daf> ok, thanks for clarifying
[11:56] <carlos> DistroReleaseVocabulary
[11:57] <carlos> stub, is there an easy way to test a vocabulary?
[11:58] <SteveA> get the vocabulary, call its API
[11:59] <SteveA> a vocabulary is a named utility
[11:59] <stub> carlos: Have a look at canonical/launchpad/doc/vocabulary.txt -- add more tests there
[12:00] <carlos> ok
[12:00] <carlos> thanks
[12:01] <daf> lifeless: can you tell me if I have a merge waiting in the queue, or did it get lost when PQM got booted?
[12:02] <mpt> Who here is experienced with Debian elections?
[12:02] <lifeless> daf: pqm boots don't lose merges - they either fail clean or retry
[12:03] <daf> lifeless: ok, that's reassuring
[12:03] <SteveA> mpt: mako
[12:03] <mpt> of course
[12:03] <mpt> ta
[12:07] <Kinnison> stub: from what I can find on the website, we might have a large proportion of the right stuff in the db already
[12:07] <Kinnison> stub: all we need is to get the gaps filled for gina :-)
[12:08] <stub> Kinnison: Yup. I think everything is there for hoary, which is what I'm running gina against for testing.
[12:08] <Kinnison> stub: cool
[12:08] <stub> At least until it died with a permission error ;)
[12:31] <sabdf1> jamesh: oops, pinged you on #ubuntu-devel
[12:31] <stub> Kinnison: perms sorted.
[12:32] <Kinnison> stub: cool thanks
[12:32] <Kinnison> stub: So we're going with making everything owned by launchpad admins for now?
[12:32] <Kinnison> stub: or by mark?
[12:33] <stub> Kinnison: distros and distroreleases by mark, components, architectures, processors, processorfamilies by launchpad admins (unless you can think of a better idea) and drop the columns later. Don't know about anything else.
[12:33] <Kinnison> okay
[12:34] <stub> Kinnison: This only has to run on production, so you can use integer ids to keep things simple.
[12:34] <Kinnison> seems sane
[12:34] <sabdf1> Kinnison: we need to find a relevant owner for the distros and distroreleases
[12:34] <Kinnison> sabdf1: Clearly there should be an ubuntu team
[12:34] <Kinnison> sabdf1: to own the project, product, distro etc
[12:34] <stub> erm - but don't assume stuff *you* insert will get the same integer id when run on production....
[12:34] <sabdf1> Kinnison: in production, there is already an ubuntucommunitycouncil
[12:34] <sabdf1> and an ubuntumembers
[12:34] <Kinnison> stub: aye, I know
[12:35] <sabdf1> we should not be auto-creating distros and distroreleases in scripts
[12:35] <Kinnison> sabdf1: I don't think either of them are quite right
[12:35] <Kinnison> sabdf1: we're not
[12:35] <stub> sabdf1: Kinnison is being my bitch
[12:35] <sabdf1> stub: good choice
[12:35] <sabdf1> kthkxbye....
[12:37] <Kinnison> We're not importing ports.ubuntu.com for now
[12:39] <Kinnison> As a comment, someone has chosen the shortname 'admin' (or been given it)
[12:39] <Kinnison> This is a touch close to our 'admins' team for comfort
[12:39] <stub> We have no blacklist - I can change it easily enough but someone else would get it again I think (or I could just create noise entries to chew up names?)
[12:40] <Kinnison> ERROR:  permission denied for sequence component_id_seq
[12:41] <daf> I think PQM is wedged again
[12:42] <daf> looks like it's stuck in the hct/sourcerer tests
[12:42] <stub> Kinnison: fixe
[12:43] <Kinnison> stub: https://chinstrap.ubuntu.com/~dsilvers/paste/filepwdbDG.html
[12:43] <Kinnison> eh?
[12:44] <daf> lifeless: ^^
[12:44] <stub> Kinnison: ERROR:  permission denied for sequence component_id_seq
[12:44] <SteveA> stub: we should have a blacklist system, but i don't think it is urgent.  a topic for brazil perhaps?
[12:45] <Kinnison> stub: pardon?
[12:45] <SteveA> sabdf1: i don't see your topics for brazil on the wiki yet.  are they up there somewhere?
[12:45] <sabdf1> SteveA: sorry, i dropped the ball there
[12:45] <sabdf1> will do it shortly
[12:45] <SteveA> cheers
[12:46] <sabdf1> i'll just dump it in as plain text, for jazzing up later
[12:46] <stub> Kinnison: I fixed the permission denied error you got
[12:46] <Kinnison> stub: and subsequently I got that error I nopasted
[12:46] <stub> Kinnison: The 'duplicate' error you pasted indicates the sequence got out of whack.
[12:46] <stub> Kinnison: It should work if you try it again
[12:46] <Kinnison> stub: okay
[12:47] <Kinnison> stub: cool, seems good
[12:47] <Kinnison> INSERT 923517353 1
[12:47] <Kinnison> cor that's a big OID
[12:50] <Kinnison> Can someone explain what the schema table is all about?
[12:54] <ddaa> Kinnison: I think you should use a distinctive nickname if you are this annoyed by people calling you like that.
[12:54] <ddaa> Kinnison: maybe something like danielss
[12:55] <Kinnison> ddaa: I got accused of being in the Nazi secret police when I did that
[12:55] <stub> sabdf1: ^^^ schema table? It ain't documented
[12:55] <ddaa> BTW, could anyone remind me what Gina does?
[12:55] <Kinnison> ddaa: I'm tempted to simply establish another connection to freenode as 'dsilvers'
[12:55] <stub> ddaa: Not much at the moment ;)
[12:56] <ddaa> I hear of running gina on warty, so I'm wondering how that would be related to some sort of import work.
[12:56] <stub> ddaa: It appears to dredge archive.ubuntu.com and extract information from all those source and binary packages.
[12:56] <ddaa> Kinnison: as you as you don't mind people calling you deesilverz
[12:57] <ddaa> stub: to what end?
[12:58] <ddaa> I guess that's the thing that has created those tons of dummy products and stupid "head" series in launchpad...
[12:58] <stub> ddaa: To populate the launchpad database with interesting information, so hct can branch, so rosetta knows what can be translated, so malone knows what can have bugs reported on it and whom to notify.
[12:58] <sabdf1> SteveA: https://wiki.launchpad.canonical.com/BrazilTopics
[12:59] <Kinnison> ddaa: If it really has to be something I'm prepared to be referred to in speech then I guess I'll have to log in as 'GingerNinja' or something
[12:59] <sabdf1> i've put stuff there for mpt, stub, daf, carlos, spiv, bradb, keybuk and kinnison
[12:59] <stub> ddaa: I don't think Gina knows about products - just sourcepackages and binarypackages. Nicole was going to link them to Products, but the data sources were too dirty
[12:59] <Kinnison> sabdf1: thanks, I'll look in a sec
[12:59] <sabdf1> pelase could i ask you guys to break those things (that are understandable) into separate specs
[12:59] <sabdf1> also add your own specs for features you want to discuss
[12:59] <Kinnison> ;nods
[12:59] <sabdf1> and label them BrazilTopic
[12:59] <ddaa> stub: okaydokey, so that essentially does not interfere with the doap things we're doing here. Thanks.
[01:00] <Kinnison> stub: I'm just pondering... distrorelease, distroarchrelease and component. I think that's all gina relies on and can't create
[01:00] <sabdf1> ddaa: i don't mind doing a mass rename of head to main...
[01:00] <Kinnison> stub: other than that, she'll make people, sourcepackagereleases etc
[01:00] <ddaa> sabdf1: not the right time for that, as importd cannot cope with job migration.
[01:01] <sabdf1> ddaa: ok
[01:01] <sabdf1> in due course
[01:01] <stub> Kinnison: debonzi said t'he distribution, distrorelease, the distroarchreleases, the components, processor and processorfamily'
[01:01] <Kinnison> stub: yeah, distribution is already there, as are the processor and processorfamily entries
[01:01] <Kinnison> stub: care to cast your eyes over mawson:~dsilvers/add-distro-for-gina.sql and let me know if it looks complete to you?
[01:03] <ddaa> Kinnison: that would be a reasonable thing to do (GingerNinja), or pick an _utterly_ unpronouceable nick like dnlslvrstn... though I can predict that people will then call you "danielsilverstone" or "all consonnants".
[01:03] <stub> sabdf1: What you talk about in cve handling makes it sound like it wants to be a bug watch
[01:03] <sabdf1> stub: hmmm.....
[01:05] <sabdf1> Kinnison: nickjam
[01:05] <ddaa> "it's one for the money, two for the show"
[01:05] <sabdf1> i moved from home to the office
[01:05] <Kinnison> sabdf1: is that like toejam?
[01:05] <stub> Kinnison: Change your nick to kiko2
[01:05] <Kinnison> stub: *snigger*
[01:05] <sabdf1> Kinnison: just not as tasty
[01:05] <Kinnison> sabdf1: BTW, did anyone find 9 dead gay guys on your plane?
[01:06] <sabdf1> Kinnison: ?!?
[01:06] <sabdf1> we dumped the bodies over the atlantic!
[01:06] <ddaa> the right answere is:  :)
[01:06] <Kinnison> ddaa: mu to you too
[01:07] <Kinnison> hi mdz
[01:07] <mdz> morning
[01:07] <Kinnison> stub: Does that patch look right?
[01:07] <ddaa> I've been learning how to type it in japanese, so happpy to have a chance to use it :)
[01:07] <Kinnison> ddaa: *g*
[01:07] <stub> Patch? I see no steenking patch?
[01:08] <carlos> ddaa, just get daf's laptop and it will start printing japanese characters without any notice, you don't need to learn how to type them, they will just appear :-P
[01:09] <Kinnison> 12:01 < Kinnison> stub: care to cast your eyes over mawson:~dsilvers/add-distro-for-gina.sql and let me know if it looks complete to you?
[01:09] <Kinnison> carlos: mine does hebrew with little bidding
[01:10] <carlos> Kinnison, another laptop I should not touch ;-)
[01:11] <stub> Kinnison: That all looks fine thanks (although I guess that rollback will need to go ;) )
[01:11] <Kinnison> carlos: tbh, you have to manage to press both shift keys at the same time to change keymap
[01:11] <Kinnison> stub: aye
[01:11] <Kinnison> stub: that's just for testing
[01:13] <daf> is there anyone apart from lifeless who can boot pqm?
[01:13] <Kinnison> elmo
[01:13] <Kinnison> (who is moving today)
[01:13] <daf> right
[01:14] <daf> apart from lifeless and elmo...
[01:14] <Kinnison> ...what have the romans ever done for us?
[01:17] <daf> nothing!
[01:17] <carlos> Kinnison, could you take care of https://launchpad.ubuntu.com/malone/bugs/1249/ ?
[01:17] <Kinnison> Sorry, you don't have permission to access this page.
[01:17] <Kinnison> You are logged in as Daniel Silverstone
[01:17] <Kinnison> apparently not
[01:18] <carlos> Kinnison, still outside the admin team?
[01:18] <Kinnison> nope
[01:19] <Kinnison> Daniel Silverstone is
[01:19] <Kinnison> Approved Member of Launchpad Administrators
[01:19] <Kinnison>  Administrator of The Aranha Team
[01:19] <carlos> Kinnison, then it's a malone bug...
[01:19] <carlos> Kinnison, retry now, please
[01:19] <Kinnison> I can see that now
[01:19] <carlos> bradb-away, BjornT did you changed anything about private bugs visibility?
[01:20] <Kinnison> carlos: I'm not in the launchpad developers team
[01:20] <Kinnison> carlos: only in the admin team
[01:20] <carlos> oh, I thought it was the same...
[01:20] <Kinnison> nup
[01:21] <carlos> Kinnison, done
[01:22] <carlos> stub, I did it already
[01:22] <stub> Yay - somebody else knows how to drive it!
[01:22] <carlos> x-)
[01:22] <Kinnison> How do I unsubscribe my specific CC?
[01:22] <carlos> stub, I'm managing most of the Ubuntu l10n teams 
[01:23] <carlos> Kinnison, there is no way, change it to Watch so you don't get the emails twice
[01:23] <Kinnison> pity it uses my person number and not my name
[01:23] <Kinnison> inthe URL
[01:23] <Kinnison> Anyway, I shall read the bug now
[01:24] <carlos> stub, would you apply to production the patchset I sent you some hours ago? Pretty please :-)
[01:24] <stub> nag, nag, nag ;)
[01:24] <carlos> ;-)
[01:26] <stub> Gina is still a noise bitch
[01:26] <stub> erm... noisy
[01:27] <Kinnison> stub: aye, but consider how annoying women are who won't actually *TELL YOU* when something is wrong
[01:28] <stub> Kinnison: I've gone a fair way to making her shut up until you ask for her input ;)
[01:28] <stub> Still some subprocess output leaking through
[01:28] <Kinnison> dpkg-source -x mostly I guess
[01:32] <sabdf1> mpt: i'm afraid someone has revered the user_icon to the ShadowMan, could you fix it please?
[01:33] <mpt> sabdf1: sure
[01:33] <sabdf1> thanks. re-revert it!
[01:35] <carlos> did we lose the feature to move bugs from one product to another?
[01:36] <carlos> I'm not able to move https://launchpad.ubuntu.com/malone/bugs/893 from launchpad to Rosetta
[01:36] <carlos> at least I don't see where should I do it...
[01:37] <Kinnison> carlos: So, that bug
[01:37] <Kinnison> carlos: I think your answer looks good
[01:37] <Kinnison> carlos: although won't it need a clauseTables?
[01:37] <carlos> Kinnison, I fixed the same problem with ProductReleaseVocabulary
[01:37] <carlos> Kinnison, no, as the way it uses SQLBuilder
[01:38] <Kinnison> carlos: Right
[01:38] <Kinnison> carlos: Well, seems you know the answer and since I'm not an SQLObject guru, nor do I understand the Vocabulary objects right now, you're best placed to fix it
[01:39] <Kinnison> carlos: but agree with your concern and your proposed fix
[01:39] <carlos> ok, not sure if that would break other things in Soyuz
[01:39] <carlos> if you think the fix is ok, will apply the fix now
[01:40] <carlos> that vocabulary will break on production as soon as we import warty and breezy 
[01:40] <Kinnison> Well all of soyuz is meant to assume unique distroreleasename in distribution
[01:41] <carlos> hmm,  perhaps it will not break with hoary and breezy as we only have one distribution, right
[01:41] <carlos> but the DB model was changed to let us have two releases with the same name
[01:42] <carlos> stub, wasn't it?
[01:42] <stub> Kinnison: What prints "Check Sourcepackage libtie-cache-perl Version 0.17-1 before process it
[01:42] <stub> "
[01:42] <Kinnison> carlos: aye, the UNIQUE is (name,distribution)
[01:42] <Kinnison> stub: not a clue
[01:43] <carlos> sabdf1, I need to add some sample data to add a test for that bug, did you merge your changes already?
[01:45] <cprov> morning all
[01:45] <Kinnison> hi cprov
[01:46] <cprov> Kinnison: hi there, how is it going, hopefully I'll be back to buildd review soon, gpg-ng is almost done
[01:46] <cprov> stub: ping 
[01:46] <Kinnison> cprov: excellent news
[01:46] <stub> cprov: pong
[01:47] <cprov> stub: have you looked the patch to rename GPGkey.revoked to active ?
[01:48] <stub> cprov: Nope - my queue is empty. No idea where the patch is.
[01:48] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Rosetta permission updates (patch-2031: stuart.bishop@canonical.com)
[01:49] <ddaa> Yiiiiiipeee!
[01:49] <cprov> stub: still in jamesh's .. but could you preempt the movement and goes there (celso.providelo@canonical.com/lauchpad--gpg--ng--0) ?
[01:49] <ddaa> EP finally rejected the swpat directive!!!!
[01:49] <ddaa> http://mail.fsfeurope.org/pipermail/press-release/2005q3/000109.html
[01:49] <Kinnison> ddaa: Quite definitively too
[01:50] <cprov> stub: i'm finishing the last small changes required by jamesh ...only UI
[01:50] <ddaa> Kinnison: they'll come back. But that's a significant victory, as the political class is now a bit more educated about the stakes and tricks involved in the issue.
[01:52] <Kinnison> Hmm, London got the Olympics
[01:52] <ddaa> Good for you guys. The Paris campain was abysmal :)
[01:53] <Kinnison> ring me if you need me
[02:00] <carlos> Kinnison, and software patents were rejected ;-)
[02:08] <Kinnison> carlos: yes, ddaa said
[02:12] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  sync with database after updating Packaging records for +ubuntupkg page (patch-2032: james.henstridge@canonical.com)
[02:17] <daf> /home/pqm/arch/queue/workdir/rocketfuel@canonical.com/rocketfuel@canonical.com--+-launchpad--devel--0/launchpad/lib/canonical/launchpad/ftests/../pagetests/foaf+/30-mergepeople.txt ... /bin/sh: line 1: 18718 Killed
[02:17] <daf> humph
[02:17] <carlos> fuck, breezy has been imported already into launchpad...
[02:17] <Kinnison> carlos: pardon?
[02:17] <carlos> Kinnison, breezy has been created into production
[02:18] <carlos> so all its transaltions are being imported atm 
[02:18] <carlos> and I was not ready
[02:18] <Kinnison> carlos: It has been created, yes
[02:18] <Kinnison> carlos: oh
[02:18] <Kinnison> sorry
[02:18] <carlos> instead of 41 reviews now I have 187...
[02:18] <Kinnison> My patch created all the relevant bits of distroness for Ubuntu
[02:18] <carlos> Kinnison, it's my fault I should did this review long time ago
[02:18] <carlos> so don't worry
[02:19] <Kinnison> okay
[02:23] <debonzi> hi all
[02:25] <cprov> stub: I've finished jamesh requests, should I move the branch to your queue just for registering or it's no necessary
[02:26] <stub> cprov: i have already created it in my queue
[02:27] <cprov> stub: I see, tks
[02:28] <stub> cprov: Do you know what is printing all these "Check Sourcepackage xtartan Version 2.3-10 before process it" lines in gina ?
[02:28] <stub> debonzi: ^^^
[02:30] <debonzi> stub, yep... on gina.py import_sourcepackage and import_binarypackage ... it still have some print calls 
[02:31] <debonzi> stub, I didn't change they on my patch... sorry
[02:32] <stub> debonzi: Ahhh! I was grepping in lib/canonical ;)
[02:33] <debonzi> stub, heh.. do you want me to change then together with the test stuff or will you change them by tourself?
[02:33] <debonzi> s/tourself/yourself
[02:33] <debonzi> stub, did you get gina running for hoary?
[02:34] <stub> debonzi: Looks like it, although it hasn't finished
[02:35] <stub> debonzi: I'm make these last few tweaks and leave a run overnight
[02:35] <kiko-zzz> here I am
[02:36] <kiko-zzz> o/~ rock you luck a hurricane o/~
[02:36] <jamesh> kiko: are we having a reviewer meeting tonight?
[02:37] <kiko> I was supposing it would happen in 20m 
[02:37] <jamesh> good.  just checking.
[02:37] <kiko> (even though we didn't send out mail on the subject)
[02:37] <debonzi> stub, cool... and how about warty and breezy? did you talk with Kinnison/mark?
[02:38] <Kinnison> debonzi: myself and stub got things ready for the run today
[02:38] <debonzi> Kinnison, that is great.. tanks Kinnison 
[02:39] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Improved the test for #1036 so it detects future breakages (patch-2033: carlos.perello@canonical.com)
[02:42] <sabdf1> stub: your mod to -39-0.sql needs a tweak, i think
[02:42] <stub> sabdf1: eh?
[02:42] <sabdf1>  UPDATE CVERef SET cvestate=2 WHERE cveref LIKE 'CVE-%';
[02:42] <sabdf1> these lines will not work
[02:42] <sabdf1> there's only one of them, but for correctness...
[02:43] <sabdf1> so i guess the update has to be, like:
[02:43] <sabdf1> UPDATE CVERef SET cveref=substring(cveref from 5), cvestate=2 WHERE cveref LIKE 'CVE-%';
[02:43] <sabdf1> do them both at once
[02:43] <sabdf1> same for the CAN's
[02:45] <sabdf1> stub: make sense?
[02:45] <stub> sabdf1: yes - that is correct. I'll fix it now (I have that branch open)
[02:45] <Kinnison> eww, is sql 1-based offsets too?
[02:45] <sabdf1> stub: ok cool
[02:45] <sabdf1> Kinnison: hideous, innit
[02:46] <Kinnison> sabdf1: I'm shuddering as we speak
[02:46] <Kinnison> icky
[02:47] <sabdf1> salgado: pls see mail
[02:47] <salgado> sabdf1, just saw it. (and I'm already taking care of it. ;)
[02:47] <sabdf1> salgado: thanks ;-)
[02:51] <jamesh> launchpad looks really pretty now
[02:52] <sabdf1> jamesh: thanks :-)
[02:53] <sabdf1> salgado: i've just mirrored up a few more tests
[03:02] <kiko> jamesh, salgado, SteveA, stub: it's that #canonical-meeting time
[03:02] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Permission and patch fixes (patch-2034)
[03:02] <stub> meeting?
[03:02] <kiko> heh
[03:03] <kiko> stub, it's the reviewer meeting; we had proposed to invite you to participate if you so wanted to
[03:04] <jamesh> stub: same password as for the other channels
[03:04] <daf> use the password, luke^Wstub
[03:04] <kiko> talentlesstramps
[03:04] <Kinnison> go kiko
[03:04] <daf> oh dear
[03:22] <SteveA> kiko: 
[03:23] <kiko> canonical-meeting baby
[03:23] <SteveA> what's the password again?
[03:23] <kiko> very funny
[03:25] <salgado> jblack, around?
[03:29] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Fixed a bug with ProductReleaseVocabulary + test (patch-2035: carlos.perello@canonical.com)
[03:29] <jblack> salgado: Sure am, though I'm a little hectic at the moment. WHat's up? 
[03:30] <mpt> salgado: Sorry I've taken so long to finish BasicVoting
[03:30] <salgado> jblack, had a problem trying to merge rocketfuel: https://chinstrap.ubuntu.com/~dsilvers/paste/filey9keu4.html
[03:30] <salgado> jblack, seems to be always reproductible, with baz COTM
[03:30] <mpt> salgado: My main blocker now is knowing exactly what is going to be presented when a preferential voting poll closes
[03:32] <salgado> mpt, no worries. I still owe you some answers for questions you raised.
[03:32] <mpt> salgado: and thanks for your work on decruftify-b--1
[03:38] <jblack> salgado: Could you msg me the up for that url? A couple weeks ago I had a filesystem failure (two, actually) 
[03:39] <salgado> jblack, sure
[03:43] <SteveA> mpt: a table, 1st column is number of votes.  subsequent columns are the preferences.  one row in the table for each unique set of preferences observed.
[03:44] <mpt> hmmm, that makes sense
[03:44] <mpt> though it might get very long
[03:44] <SteveA> yes
[03:44] <SteveA> but short as can be, if we're not calculating the results
[03:45] <SteveA> i'd suggest sorting by number of votes.  not sure what to sort on after that.
[03:49] <SteveA> jamesh: would it be possible to have scripts that represent the operations in TipsForReviewers available in RocketFuel and on chinstrap as scripts that run with a few simple options?
[03:50] <jamesh> SteveA: I suppose so.  Sounds like a good idea
[03:51] <dilys> New Malone bug 1251 filed on product Bazaar by Guilherme Salgado: baz merge always failing with "exiting on botched invariant"
[03:51] <dilys> https://launchpad.ubuntu.com/malone/bugs/1251
[03:53] <mpt> COW
[03:53] <mpt> Moin ate my changes again
[03:54] <SteveA> you have the moin editor backup thing?
[03:55] <mpt> yes, but I hadn't clicked "Preview" yet for these changes, so the backup is even more out of date than the current version
[03:55] <dilys> Merge to rocketfuel@canonical.com/launchpad--production--1.24: Cherry pick patch-2026 into productin (patch-3: carlos.perello@canonical.com, rocketfuel@canonical.com)
[03:55] <carlos> stub, thanks
[03:59] <salgado> jamesh, I'm quite sure that extra createPerson() method is the result of a badly solved conflict. I'm merging from rocketfuel now and will reply to your review soon
[03:59] <jamesh> salgado: yep.  There are two createPerson()'s in rocketfuel too (not just your branch)
[04:00] <jamesh> salgado: so fixing it is good.
[04:02] <salgado> jamesh, sure. I'll fix it. I think it's that because I don't have these two createPerson()s on my branch
[04:03] <jamesh> salgado: okay.  I assumed you'd removed one, rather than one being added on rocketfuel :(
[04:08] <lifeless> dilys: ping
[04:08] <lifeless> bah
[04:08] <lifeless> ddaa: ping
[04:08] <ddaa> lifeless: pouet
[04:08] <ddaa> wazza?
[04:09] <lifeless> ddaa: can you do your rollout foo for me, for robert.collins@canonical.com/cscvs--devel--0, and cherry pick robert.collins@canonical.com/launchpad--devel--0--patch-139 into the launchpad checkout on the importd machines ?
[04:09] <ddaa> duh launchpad is down :(
[04:10] <lifeless> ddaa: I've been fighting test failures all evening on this :[
[04:10] <lifeless> - fixes svn update and the x bit.
[04:10] <ddaa> ha, so you reckon update was broken?
[04:10] <lifeless> yes
[04:11] <ddaa> what's the status of /tmp cleanup? Just out of curiosity.
[04:11] <ddaa> If I have to make a rollout, I'd rather roll that one out as well.
[04:11] <lifeless> code for that was going to be written tonight, but after the test wrangling I went through, it ain't gonna happen
[04:11] <ddaa> cause otherwise I expect we're going to have /tmp trouble on hoover soon
[04:11] <lifeless> will be my first thing tomorrow morning though
[04:12] <ddaa> mind if we delay that rollout until that is done too?
[04:12] <bradb> morning all
[04:12] <kiko> morning bradb
[04:12] <ddaa> lifeless: ?
[04:14] <bradb> hey kiko 
[04:14] <lifeless> ddaa: yes
[04:14] <ddaa> okay will do
[04:14] <lifeless> ddaa: kamion has a bunch of stuff pending
[04:15] <kiko> jamesh, the header padding in PR could use some beautifying :-P
[04:15] <kiko> and I had an idea
[04:15] <kiko> if the branch had conflicts 
[04:16] <kiko> instead of merge
[04:16] <kiko> print "conflicts (23)" as the linktext
[04:16] <jamesh> good idea
[04:16] <kiko> that removes the need for the (conflicts) header
[04:16] <kiko> and then
[04:16] <kiko> aha
[04:16] <kiko> one way to solve the header padding
[04:16] <kiko> remove the header border
[04:17] <kiko> IOW the border only starts right under the "Date  Branch [...]  Full" header 
[04:17] <kiko> jamesh, sound reasonable? the Run Date being so glued into the border was bothering me
[04:18] <jblack> is lp broken?
[04:18] <jamesh> sounds like a good idea
[04:18] <kiko> lp is down apparently
[04:18] <kiko> lifeless?
[04:20] <mpt> bradb: Better that it failed while you were sleeping than that it failed while you were waiting for it
[04:20] <bradb> indeed
[04:26] <lifeless> kiko: I don't have the account on the new box yet
[04:26] <kiko> lifeless, uhm. can you elaborate?
[04:26] <lifeless> kiko: we're moving boxes
[04:27] <lifeless> kiko: but nm, it looks like prod is building a clean run now
[04:27] <kiko> oh. right now?
[04:27] <kiko> cool
[04:29] <lifeless> should be up now
[04:29] <kiko> thanks mr.
[04:29] <salgado> lifeless, have you seen https://launchpad.ubuntu.com/products/bazaar/+bugs/1251 ?
[04:30] <salgado> jamesh, still around?
[04:30] <jamesh> salgado: yep
[04:30] <salgado> jamesh, would you like to have a look at the changes I did after your review of my smallfixes branch?
[04:37] <jamesh> grabbing them
[04:38] <salgado> jamesh, great. thank you
[04:42] <mpt> wow, moin logged me out twice in two hours
[04:47] <jamesh> salgado: your changes look good.
[04:47] <jamesh> salgado: I'll set your branch to merge-approved
[04:47] <ddaa> lifeless: I see that your cscvs is not up to date with mine (i.e. production)
[04:48] <ddaa> lifeless: is that intentional?
[04:48] <salgado> jamesh, cool. thanks
[04:48] <lifeless> ddaa: I merged mainline in, 
[04:48] <lifeless> ddaa: just merge mine into yours
[04:48] <ddaa> Okay, I'll do that and run the tests. That may take some doing though. Mesh merge sucks.
[04:49] <ddaa> Note that I do not say _your_ mesh merge.
[04:49] <ddaa> It's just that it does not actually work as expected.
[04:52] <ddaa> cause diff and friends are purposefully stupid
[04:56] <jblack> 
[04:56] <mpt> [0014] 
[04:57] <ddaa> 
[04:57] <mpt> ooo, pretty
[04:57] <ddaa> "appearance of a dragon walking" according to wikipedia
[04:57] <ddaa> or "here be a dragon" according to me :)
[04:57] <jblack> sorry for the reverse S. 
[04:58] <mpt> it's a degrees symbol according to AbiWord :-/
[04:58] <jblack> I meant to switch over to go back to ddaa's email. : )
[04:58] <jblack> Ooohhh. I wonder how I made it.
[04:58] <jblack>  ? 
[04:58] <mpt> no, 
[04:59] <jblack> I can't do ctrl-x. :( 
[04:59] <mpt> and in OOo it's a box
[04:59] <mpt> bah
[04:59] <ddaa> http://en.wiktionary.org/wiki/%E9%BE%98
[05:01] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Fix patch-17-39-0 gooder (patch-2036: stuart.bishop@canonical.com)
[05:07] <kiko> SteveA, about linkifying, what do you suggest I do?
[05:07] <SteveA> kiko: which bit?
[05:08] <kiko> the escaping issue.
[05:08] <SteveA> i want to be the one to integrate your work into launchpad, as i want to take responsibility for the conceptual integrity of the TALES additions
[05:08] <SteveA> so, i'll happily handle that part
[05:08] <SteveA> maybe you can do the bug lookup ?
[05:08] <kiko> yes
[05:08] <kiko> I'll handle that now
[05:08] <SteveA> cool
[05:08] <kiko> can I do a full import?
[05:08] <kiko> i.e. in the header
[05:08] <SteveA> of?
[05:08] <kiko> without being concerned about dependencies 
[05:08] <kiko> of interfaces.bug
[05:08] <SteveA> you can always import interfaces anywhere
[05:09] <kiko> okay
[05:09] <SteveA> interfaces.IBugSet
[05:09] <SteveA> that's the beauty of interfaces
[05:09] <kiko> I thought it would be nice to be able to linkify to a task
[05:09] <kiko> bug x task y
[05:09] <SteveA> cool.  anything goes if you use interfaces
[05:09] <SteveA> go wild
[05:09] <kiko> where y would be a context
[05:09] <kiko> but that won't ever work :-(
[05:09] <kiko> bug 23 context product foo
[05:10] <SteveA> ___bug_23_on_product_foo__ ?
[05:10] <kiko> bug 23 product foo
[05:10] <ddaa> mh... actually, "baz merge" seems to work better when merging by smaller steps...
[05:10] <kiko> maybe
[05:10] <SteveA> talk to mpt
[05:10] <SteveA> he will give ideas
[05:10] <kiko> he's the ideas man
[05:10] <kiko> okay
[05:10] <mpt> _bug 123 in ubuntu hoary_
[05:10] <kiko> SteveA, let's try and get this in tonight so malone shines next week?
[05:10] <mpt> mmmmm, brittle
[05:10] <kiko> mpt, how do I know what ubuntu hoary is?
[05:11] <kiko> distro or product?
[05:11] <mpt> you don't know whether it's a product or a distro
[05:11] <mpt> snap
[05:11] <kiko> okay, that'll be step 2
[05:11] <kiko> right
[05:11] <SteveA> kiko: depends how my database fixes and menus fixes go.  this is just polish, so it has to come at a lower priority than those.
[05:11] <mpt> kiko: so, you can't
[05:11] <SteveA> kiko: i'll se what i can do, though
[05:11] <kiko> SteveA, but those aren't going to land today, are they?
[05:11] <SteveA> sure they are
[05:11] <kiko> aieee
[05:11] <mpt> kiko: just link to the bug, and let Demystifying v2 sort out the workflow from there
[05:11] <SteveA> there's a small menus fix
[05:11] <kiko> mpt, okay.
[05:12] <SteveA> and a pretty small database infrastructure change
[05:12] <kiko> SteveA, I'll get you the patch in a few minutes
[05:12] <mpt> SteveA: Will the LaunchpadMenus spec need updating with new instructions, and if so will you have time to do so?
[05:12] <SteveA> i think landing your stuff won't take long, provided you have written tests
[05:12] <lifeless> night all
[05:12] <SteveA> mpt: i won't have time for that today.  maybe daf can help?  what new destructions?
[05:12] <jblack> sleep well.
[05:13] <mpt> SteveA: Only if you're making changes on how the menus are programmed
[05:13] <mpt> on -> to
[05:13] <kiko> bradb, can you write tests for the linkify thing?
[05:13] <kiko> i.e. do you have time to do this right about now
[05:13] <mpt> SteveA: and document the +debug-menu thing perhaps
[05:13] <kiko> I'll send you the patch if so
[05:13] <bradb> kiko: not right now, sorry, desparately trying to merge FBN
[05:14] <SteveA> mpt: no API changes at present.  just implementation fix from a bug daf reported.  maybe you or daf can document the +debug-menus thing?
[05:14] <bradb> kiko: if it's something i can do later, i can do it later
[05:15] <mpt> SteveA: ok
[05:17] <ddaa> That's it :)
[05:17] <ddaa> Hear! People of the launchpad!
[05:17] <ddaa> when "baz merge" gives you grief
[05:17] <ddaa> do "baz missing -s" for the target branch
[05:18] <ddaa> and then do stepwise "baz merge" at several points along the line
[05:18] <ddaa> particularly around merge points
[05:18] <ddaa> you can tell merge points using "baz merges REVISION" (note the s)
[05:18] <jblack> Ahhh. They've got a hole. 
[05:19] <SteveA> there really should not be an API that is 'baz merge' and 'baz merges'
[05:19] <ddaa> so baz merge can pick a different ancestor each time (it's not-quite-deterministic, unlike star-merge).
[05:19] <SteveA> that sucks so bad
[05:19] <SteveA> from a UI perspecvity
[05:19] <SteveA> perspective
[05:19] <ddaa> SteveA: yes it does, legacy UI cruft.
[05:19] <ddaa> baz merges predates baz merge, and it's a very little known command.
[05:21] <SteveA> does python ever fail for 'import thread' these days?
[05:21] <SteveA> jamesh: you'll know!
[05:21] <kiko> mpt!
[05:21] <kiko> I have a question for you
[05:21] <kiko> the linkify code I have currently does 
[05:21] <kiko> [www.foo.com]  for links to http://www.foo.com/baz/bar/boo
[05:21] <kiko> is that acceptable?
[05:21] <mpt> I saw that and thought it was odd
[05:21] <kiko> should I just ellipsize?
[05:22] <kiko> I want to avoid URLs blowing up my video
[05:22] <mpt> Isn't this covered by DisplayingParagraphsOfText?
[05:22] <SteveA> hmm, perhaps thread is missing on some micro platforms
[05:22] <kiko> mpt, if you want to help me, tell me exactly what I should do
[05:22] <SteveA> but screw that.  we depend on '
[05:22] <SteveA> thread'
[05:22] <mpt> kiko: ok, make linkifying run *before* DisplayingParagraphsOfText does
[05:23] <mpt> kiko: then the URL will be wrapped, but the link will still work.
[05:23] <SteveA> kiko: i think it should be [foo.com] 
[05:23] <mpt> because the link is based on the URL before it was wrapped.
[05:23] <SteveA> and [foo.co.uk] 
[05:24] <SteveA> mpt: putting <a> into DisplayingParagraphsOfText will break it
[05:24] <mpt> because it'll become &lt;a&gt;?
[05:24] <mpt> what fun
[05:24] <SteveA> the interaction of linkifying stuff with other stuff is not trivial
[05:24] <mpt> true
[05:24] <kiko> I was going to say just that
[05:24] <mpt> It seemed like the simplest, simplest spec to write
[05:24] <kiko> so the choices are -- link to hostname, or ellipsize the URL, or include the full link.
[05:24] <mpt> when I first started
[05:24] <SteveA> and i have DisplayingParagraphsOfText ready to merge, it looks like
[05:24] <jamesh> SteveA: I think threading is enabled for pretty much every Python build.  I wouldn't be surprised if --disable-thread is somewhat untested
[05:25] <kiko> mpt, you software engineer underestimator
[05:25] <mpt> I thought it was going to be about two paragraphs
[05:25] <mpt> ok
[05:25] <ddaa> thinking of it... this stepwise mesh merge is probably not to dissimilar to a poor-man cdv merge...
[05:25] <SteveA> let's do linkifying little by little
[05:26] <kiko> right
[05:26] <SteveA> we can start of with just converting text to a simple link
[05:26] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Fix patch-17-39-0.sql more gooder (patch-2037: stuart.bishop@canonical.com)
[05:26] <mpt> kiko: I don't like [foo.com]  much at all
[05:26] <SteveA> and deal with goats.cx problems for now
[05:26] <kiko> mpt, give me a better suggestion
[05:26] <kiko> SteveA, a simple link won't fix the problems I'm seeing in quite a few bugs and I'd love to land that too
[05:26] <kiko> I'll use common sense...
[05:27] <SteveA> kiko: i think we're at the stage where a spec would help explain things.
[05:27] <SteveA> needn't be big
[05:27] <SteveA> but there are enough interactions going on that we must capture the rationale
[05:27] <kiko> I can't do that SteveA, not today
[05:27] <mpt> kiko: Anyway, [foo.com]  won't help you when it comes to [llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch.co.uk] 
[05:27] <kiko> mpt, stop strawmanning
[05:27] <SteveA> then i think we can't land anything but the simplest link code
[05:27] <kiko> okay
[05:27] <SteveA> kiko: work out the very simplest possible thing
[05:27] <mpt> I'm not, that's a real domain
[05:28] <mpt> As I'm sure daf is aware, since it's Welsh
[05:28] <kiko> mpt, I know, but it's a minor issue we can surely live with
[05:28] <SteveA> yeah, i know about all the domains in .uk
[05:29] <SteveA> kiko: here's what i need to know
[05:29] <mpt> kiko: The very simplest possible thing is to linkify after DPoT
[05:29] <SteveA>  - what pages will you want to linkify things right now, in this first implementation ?
[05:29] <mpt> Actually, DPoT doesn't split anything anyway, does it?
[05:29] <kiko> SteveA, only bug pages for now
[05:29] <SteveA>  - will the text that gets linkified also be passing through other formatters? (DPoT ?)
[05:29] <mpt> only bug pages? then what's the problem?
[05:30] <mpt> just implement exactly what I specced in the bug
[05:30] <carlos> debonzi, https://launchpad.ubuntu.com/distros/ubuntu <-- I think we should sort that distrorelease list by version
[05:30] <SteveA> if so, why not just make DPoT do the work as an extra step, and make this available as DisplayingLinkifiedParagraphsOfText 
[05:30] <SteveA> there is no need to generalize
[05:31] <mpt> SteveA: agreed
[05:31] <SteveA> so, how does DPoT get accessed?  fmt:paragraph ?
[05:31] <SteveA> if so, fmt:paragraph_with_links
[05:31] <SteveA> and we leave it up to the code to do the right thing
[05:31] <debonzi> carlos, you are right.. I will add it to my TODO list.. thanks
[05:31] <SteveA> no chaining of formatters
[05:31] <carlos> debonzi, thank you ;-)
[05:31] <SteveA> no questions about whether the code is already escaped or not
[05:32] <SteveA> and, we have a chance of landing this today.
[05:32] <kiko> can somebody explain what you are suggesting?
[05:33] <kiko> in baby talk
[05:33] <SteveA> kiko: okay.  i will explain.
[05:33] <SteveA> 1. we have DisplayingParagraphsOfText almost ready to merge.
[05:33] <mpt> kiko: You could read the spec, it's in your queue anyway ;-)
[05:33] <SteveA> 2. DisplayingParagraphsOfText adds tal:content="structure sometext/fmt:paragraph" (or something very similar)
[05:34] <mpt> https://wiki.launchpad.canonical.com/DisplayingParagraphsOfText
[05:34] <SteveA> 3. we're going to be using this for displaying a bunch of stuff
[05:34] <mpt>  /fmt:text-to-html
[05:34] <kiko> so far so good
[05:34] <SteveA> 4. so, let's also have /fmt:text-to-html-linked
[05:34] <mpt> so it could include linkifying without being renamed anyway
[05:35] <SteveA>    rather than /fmt:linkify/fmt:text-to-html
[05:35] <carlos> mpt, daf https://launchpad.ubuntu.com/distros/ubuntu/hoary/+sources/gnome-panel has a bad link to +translations as part of the menu
[05:35] <SteveA> or anything more exotic
[05:35] <kiko> SteveA, does this work for nice_pre too?
[05:35] <kiko> or does this come after nice_pre?
[05:35] <carlos> mpt, daf it should be https://launchpad.ubuntu.com/distros/ubuntu/hoary/+sources/gnome-panel/+translations instead of https://launchpad.ubuntu.com/distros/ubuntu/hoary/+translations
[05:35] <SteveA> kiko: we can have nice-pre-linkified
[05:35] <daf> carlos: that should be fixed by my menus branch
[05:35] <kiko> okay
[05:35] <carlos> daf, ok
[05:35] <mpt> carlos: That's very much daf
[05:35] <SteveA> the point is, we don't want to chain fmt:this/fmt:that
[05:35] <kiko> BjornT?
[05:35] <kiko> SteveA, okay, accepted
[05:36] <SteveA> cool
[05:36] <daf> hmm, then, again, that's a source package
[05:36] <kiko> that way ensures escaping is done properly I see
[05:36] <daf> so perhaps it needs some more attention
[05:36] <BjornT> kiko: yes?
[05:36] <kiko> SteveA, that doesn't help me with the linktext though
[05:36] <SteveA> linktext?
[05:36] <kiko>   File "lib/canonical/launchpad/webapp/tales.py", line 476, in linkify
[05:36] <kiko>     bug = getUtility(IBugSet)[bug_number] 
[05:36] <kiko>   File "/home/kiko/devel/rocketfuel/launchpad/lib/canonical/launchpad/database/bugset.py", line 18, in __getitem__
[05:36] <kiko>     item = self.table.selectOne(self.table.q.id == id)
[05:36] <kiko> AttributeError: 'BugSet' object has no attribute 'table'
[05:36] <kiko> BjornT, kinda weird, isn't it?
[05:37] <SteveA> that looks well untested
[05:37] <SteveA> kiko: what do you mean 'linktext' ?
[05:37] <kiko> the text of the link, SteveA -- what is displayed to the end-user.
[05:37] <SteveA> also, i need to stop talking about this, and get on with other work soon.
[05:37] <mpt> kiko: Splitting long words is a separate problem that can be handled slowly
[05:37] <SteveA> kiko: what is the difficulty?
[05:38] <mpt> or carefully, I should say
[05:38] <mpt> It doesn't need to be in today's landing
[05:38] <kiko> it annoys me that a large number of bug summaries contain links and blow up my video
[05:38] <kiko> can I not land an interim fix that makes my life as a triager less painful?
[05:38] <kiko> many rosetta bugs do this for instance
[05:38] <SteveA> blow up your video?
[05:38] <kiko> (nor that it's rosetta's fault)
[05:38] <SteveA> do they contain links to launchpad?
[05:38] <SteveA> to localhost?
[05:39] <kiko> yes, scroll away into the netherland
[05:39] <kiko> links to launchpad.ubuntu.com/bla bla bla yes
[05:39] <mpt> It is Rosetta's fault, Rosetta's URLs are too long :-)
[05:39] <daf> horizontal scrolling is evil
[05:39] <BjornT> kiko: yes, that's bad... use .get(bug_number) instead. report a bug about it, and i'll have a look at it later
[05:39] <daf> can we not use font-family: monospace + explicit line breaks?
[05:39] <kiko> BjornT, okay.
[05:40] <daf> or CSS for the wrapping behaviour we want, if there is some
[05:40] <SteveA> okay, i'm going to work on database code.  kiko, mpt: work out what you want to do.  keep it extremely simple.  i'll check back in an hour to chat about it.
[05:40] <mpt> daf: there isn't, and there won't be widely available for the next ~7 years
[05:41] <daf> mpt: any significant drawback to monospace + <br>?
[05:41] <kiko> I'm going to use the hostname unless mpt gives me a solution in 5 minutes :-P
[05:41] <mpt> daf: not that I can think of
[05:41] <daf> hmm, I guess it might cause adjacent spaces to collapse
[05:42] <mpt> kiko, I shouldn't even be awake
[05:42] <kiko> lalallalaa
[05:42] <mpt> grrrrr
[05:42] <carlos> grrr kiko at this moment I wish tal had if/else clauses...
[05:43] <SteveA> carlos: it does.  in python.  do it in python ;-)
[05:43] <kiko> carlos, tal is one big fat wart in zope and I will mail the loser who designed it with your comments
[05:43] <carlos> SteveA, in python? how?
[05:43] <kiko> SteveA, the lack of else in tal is a serious shortcoming
[05:44] <carlos> SteveA, if we have content, show this html code, if we don't have content, show this other code....
[05:44] <SteveA> tal:condition="view/have_content" .... tal:condition="not: view/have_content"
[05:44] <mpt> carlos: What's wrong with "not: ..."?
[05:44] <SteveA> compute have_content in your view's class
[05:44] <carlos> kiko, I introduced an extra textarea with #1036 fix because the missing else :-(
[05:44] <kiko> mpt, duplicating HTML content
[05:45] <SteveA> use a macro
[05:45] <carlos> SteveA, I know, but that's exactly what an if/else does and it's more easy to detect errors with an if/else than with the foo and not foo
[05:45] <SteveA> put it in a separate view
[05:45] <kiko> SteveA, I find macros expensive 
[05:45] <kiko> like
[05:45] <kiko> VERY expensive
[05:45] <SteveA> eh?
[05:45] <kiko> if they were 5c macros I would agree
[05:45] <kiko> defining and using a macro makes you jump through hoops!
[05:45] <SteveA> macros in the same page tempate are simple
[05:45] <kiko> really?
[05:45] <SteveA> yes
[05:46] <daf> Steve pasted an example the other day
[05:46] <mpt> kiko: Would you prefer your e-mail client to show long URLs as [hostname]  as well?
[05:46] <kiko> mpt, I use a text-based email client, but yes
[05:46] <daf> https://chinstrap.ubuntu.com/~dsilvers/paste/fileMpALym.html
[05:46] <kiko> my god
[05:46] <mpt> kiko: as opposed to an audio-based one?
[05:46] <kiko> that is so cool
[05:46] <kiko> mpt, as opposed to a graphical client, you sleepless soon-to-be-barzilian-pure
[05:47] <SteveA> kiko: you've been damaged by zope2
[05:47] <kiko> I love flowers
[05:47] <mpt> kiko: The situation is exactly the same in a graphical one -- the window is still a particular size
[05:47] <mpt> kiko: I guess we just disagree on this, and you're the coder, so there's nothing I can do
[05:48] <kiko> mpt, in all truthfulness, I don't like [hostname]  very much either, but I hate it less than I hate horizontal scrolling
[05:48] <kiko> mpt, I'm accepting any interim solution you suggest
[05:49] <mpt> kiko: If an URL is wider than the available space, it's on a line by itself, and once you implement linkifying, the whole of it will be clickable, so you don't need to scroll anyway
[05:49] <mpt> (unless you're actually interested in the contents of the URL)
[05:50] <mpt> So just linkifying will improve the situation
[05:51] <dilys> New Malone bug 1253 filed on product Malone by Christian "kiko" Reis: The auto-summary code should only use the first paragraph of the description
[05:51] <dilys> https://launchpad.ubuntu.com/malone/bugs/1253
[05:52] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=SteveA/trivial]  import fascism, kill translationeffort, kill sshkey browser code, add __all__s to interfaces, other cleanings-up (patch-2038: daf@canonical.com)
[05:52] <daf> hurrah!
[05:52] <daf> *finally*
[05:52] <kiko> woooo!
[05:54] <bradb> oh god, i *beg* that not to mean that my merge request is going to fail again
[05:56] <daf> if it does, it'll probably because of conflicts
[05:57] <daf> (my changes were to do with complying with the fascist rather than enforcing the fascism)
[05:57] <bradb> yeah. /me does a quick merge to find out
[05:58] <kiko> is there such a thing as a quick merge?
[05:59] <bradb> "quick", like 10 minutes
[05:59] <bradb> :)
[05:59] <kiko> heh
[06:00] <SteveA> daf: what does the fascist output say now i wonder...  if it's sane enough, i'll merge the fascist
[06:00] <bradb> * Searching for best merge point .../home/pqm/thelove@canonical.com---bazaar--devo--1.5/src/baz/libarch/namespace.c:595:botched invariant
[06:00] <daf> I'm just checking that now
[06:00] <bradb>     !!version_end
[06:00] <bradb> baz: uncaught exception: -1:(exiting on botched invariant)
[06:00] <bradb>   please report this as a bug to bazaar@lists.canonical.com
[06:01] <mpt> bradb: you and everyone else
[06:01] <daf> SteveA: we still have about five browser code files importing the DB in order to use ObjectWidget/CustomWidget
[06:01] <carlos> kiko, I think firefox is still broken with textareas
[06:02] <ddaa> bradb: if that does not work, about 45 mins ago I explained a new merge trick I just found about.
[06:02] <carlos> kiko, We still have the bug (and I think that FINALLY, I got it fixed) I start hating textareas
[06:02] <ddaa> might help
[06:02] <kiko> carlos, somehow, I doubt it :-)
[06:03] <carlos> kiko-fud, https://chinstrap.ubuntu.com/~dsilvers/paste/file3RLcMa.html
[06:03] <carlos> kiko-fud, from the HTML standard
[06:03] <bradb> ********************************************************
[06:03] <bradb> *   2 conflicted items in this tree. Please            *
[06:03] <bradb> * resolve each conflict with "baz resolved 'filename'" *
[06:03] <bradb> ********************************************************
[06:03] <carlos> those textareas should be exactly the same, right?
[06:04] <carlos> kiko-fud, they are not, first one adds an extra new line
[06:04] <kiko-fud> carlos, they seem to be quite different. html inside textareas is not very permissive wrt to whitespace, I told you...
[06:04] <daf> binarypackagename, bounty, codeofconduct, distribution, product, project, sourcepackagename
[06:05] <kiko-fud> maybe s/html/implementation of html parsing/
[06:05] <daf> and the rest are either uses of BugFactory
[06:05] <daf> or instantiating content classes directly
[06:05] <carlos> kiko-fud, yeah, that's why I didn't fix it correctly first time, but anyway, the standard says:
[06:05] <SteveA> what about __all__ and import * ?
[06:05] <carlos> a line break immediately following a start tag must be ignored, as must a line break immediately before an end tag
[06:05] <kiko-fud> interesting
[06:06] <bradb> daf: 
[06:06] <bradb> [06:06] <bradb>     bug = Int(title = _('Bug ID'), required = True, readonly = True)
[06:06] <bradb>     message = Int(title = _('Message ID'), required = True, readonly = True)
[06:06] <bradb> >>>>>>> MERGE-SOURCE
[06:06] <bradb> did you throw those specs in there around the ='s?
[06:06] <bradb> spaces, even
[06:06] <daf> eww, no
[06:07] <kiko-fud> SteveA, sent patch
[06:07] <kiko-fud> that was NOT ME EITHER
[06:07] <daf> SteveA: just a second, I'll need to pull in the new fascist again
[06:07] <carlos> kiko-fud, https://chinstrap.ubuntu.com/~dsilvers/paste/fileMpALym.html
[06:07] <carlos> hmm
[06:07] <carlos> wront link
[06:08] <carlos> kiko-fud, http://people.ubuntu.com/~carlos/broken.html
[06:08] <carlos> kiko-fud, there you have, could you tell me what am I missing?
[06:09] <carlos> kiko-fud, the first new line is ignored as the spec says, but the second one is not
[06:10] <carlos> daf, kiko-fud please, could you confirm it's a bug so I can reopen the firefox's bug report?
[06:10] <daf> carlos: they look the same to me
[06:10] <carlos> daf, I get an extra new line with the first one
[06:10] <carlos> daf, after foo
[06:10] <daf> SteveA: There were 32 imports 'from *' without an __all__.
[06:10] <daf> SteveA: There were 24 imports of names not appearing in the __all__.
[06:11] <carlos> daf, you will see it if you select all text
[06:11] <daf> oh, an extra newline on the end?
[06:11] <daf> interesting
[06:11] <daf> yes, I see that
[06:12] <daf> SteveA: the majority of the former seem to be in browser/
[06:15] <carlos> daf, please, could you tell me if reading this: http://www.w3.org/TR/html4/appendix/notes.html#h-B.3.1
[06:15] <carlos> daf, you still think it's a bug?
[06:16] <daf> well, how many newlines do you have in the first box?
[06:17] <carlos> daf https://chinstrap.ubuntu.com/~dsilvers/paste/file3RLcMa.html
[06:18] <carlos> daf, first one is the one on the left, second one is the one on the right
[06:19] <daf> hmm
[06:20] <daf> that does indeed smell like a bug
[06:20] <daf> I suggest you send the source to the bug report
[06:20] <daf> and ask them if they can reproduce it
[06:20] <carlos> I'm doing it atm
[06:20] <carlos> thank you for your confirmation
[06:20] <daf> no worries
[06:23] <bradb> salgado: https://launchpad.ubuntu.com/malone/bugs/873 is a bug that seems to be caused by the fact that the reporter doesn't have a validated (and therefore, no preferred) email address. what do you think is the appropriate way to "resolve" a bug like this? is it "fixed"? "rejected"? do i leave it "new" even though he can't possibly receive a comment? anyone else have any advice on what to do to consider resolved these bugs that app
[06:25] <bradb> BjornT: am i expected to be able to file and comment on a bug via email right now?
[06:45] <bradb> lifeless: would it be unreasonable for pqm to send an email to confirm that it's received our merge request? i've sent two in the last couple hours, and have heard nothing.
[06:49] <daf> SteveA: no imports of * without an __all__ left
[06:49] <daf> SteveA: I'll merge this now
[06:50] <bradb> kiko-fud: should i mark you as having accepted: https://launchpad.ubuntu.com/malone/bugs/628 ?
[06:50] <SteveA> daf: awesome work
[06:51] <daf> SteveA: if only we could shift these remaining DB imports
[06:53] <kiko-fud> bradb, I'll do it, thanks
[06:53] <bradb-lunch> ok,t hanks
[06:53] <daf> SteveA: I suppose we can make import of * without __all__ raise an exception now, though
[06:53] <salgado> bradb, I think you should mark it fixed and explain the problem. even if the user doesn't get any notifications, the bug will be there and he'll be able to see it
[06:53] <SteveA> daf: i'll do that when i merge the fascist
[06:54] <bradb-lunch> salgado: ok, i'll do that
[06:54] <daf> bradb-lunch: when you get back, can you tell me what the story is with BugFactory?
[06:55] <salgado> daf, did carlos talked to you about the need of addLanguage() and removeLanguage() in IPerson?
[06:56] <daf> no
[06:56] <daf> want to talk about it now?
[06:56] <carlos> daf, I told you it
[06:56] <carlos> daf, and gave you a trace
[06:57] <carlos> daf, do you remember it?
[06:57] <daf> I remember that
[06:57] <carlos> daf, it's related to rosetta's preferences page
[06:57] <salgado> daf, so, you have a languages attribute in IPerson, which is MultipleJoin. if you want to use the addLanguage() and removeLanguage() facilities in a person object, you need to declare that in the IPerson interface
[06:57] <salgado> looks like there places using it already, but the methods are not in the interface
[06:57] <daf> hmm, so it's just a problem with the interface?
[06:57] <salgado> exactly
[06:57] <daf> that's odd
[06:58] <daf> it was working before
[06:58] <daf> I wonder how it broke
[06:58] <salgado> it'd be good to test that code too. ;)
[06:58] <daf> yes, you're right
[06:58] <salgado> it probably broke because you were using an unproxied person object
[06:58] <salgado> and now you're using a proxied one
[06:58] <daf> aha
[06:59] <daf> perhaps a switch from using IPerson() to ILaunchBag() caused it
[06:59] <daf> or something like that
[06:59] <salgado> that's my best guess
[07:00] <SteveA> hmm
[07:00] <salgado> but anyway, the code is not tested. :P
[07:00] <daf> right
[07:00] <SteveA> probably IPerson is giving back a "naked" person
[07:00] <SteveA> that is, the principal --> person adapter
[07:00] <daf> yep
[07:00] <daf> I suspect that somebody fixed a call to IPerson(request.principal) or something like that to use ILaunchBag instead
[07:00] <daf> and didn't notice when it broke
[07:01] <daf> I'll do a page test for it
[07:01] <SteveA> if so, then it's a problem.  the IPerson adapter must use getUtility
[07:02] <salgado> ah
[07:02] <salgado> the problem could also have been caused when I moved the adapter from principal to person to components/person.py and made it use getUtility()
[07:02] <salgado> it wasn't using getUtility() but not it is
[07:02] <daf> that sounds like a likely candidate
[07:03] <SteveA> ah, good
[07:03] <SteveA> then all is as it should be
[07:19] <carlos> daf, the only solution for #1036 is to handle trailing and leading new lines directly inside Rosetta so the user don't care about that, as you suggested
[07:19] <daf> given the browsers behave the way they do, yeah
[07:20] <carlos> see you tonight or tomorrow
[07:20] <carlos> daf, yeah
[07:20] <daf> see you
[07:22] <kiko> carlos, I'm going to talk to mrbkap today
[07:22] <carlos> kiko, ok, thanks, I added all information I have to bugzilla
[07:22] <kiko> thanks
[07:22] <carlos> that should be enough to debug it
[07:38] <kiko> daf, I have a question for you
[07:39] <kiko> https://chinstrap.ubuntu.com/~dsilvers/paste/fileMpALym.html
[07:39] <kiko> daf, can you explain how the tal:define for menus works here?
[07:41] <jordi> kiko: DO IT
[07:41] <kiko> jordi, every day, at 6am, I do
[07:42] <SteveA> kiko: <tal:block tal:define="menu context/menu:facet">  ?
[07:42] <kiko> yeah
[07:42] <kiko> SteveA, how does that interact with the menu used inside the macro
[07:42] <kiko> and the menu used when the macro is used
[07:42] <SteveA> so, this gets the facet menu that is approprate to the context
[07:42] <jordi> kiko: ypu should be in finland next week
[07:42] <jordi> I'm going to run lots there
[07:42] <SteveA> okay.  macros all get processed first.  they are essentially #includes
[07:42] <kiko> jordi, why didn't you invite me?
[07:43] <kiko> okay so far, SteveA 
[07:43] <SteveA> once you have macros sorted out, you have effectively a new page template
[07:43] <jordi> kiko: everyone is invited!
[07:43] <SteveA> so, then you read this template with macros expanded
[07:44] <kiko> SteveA, so I'm confused. what is the first tal:define for in that example?
[07:44] <kiko> the one around the define-macro
[07:45] <SteveA> that defines the name "menu" to be the facet menu.  you can iterate over the facet to get its links
[07:46] <bradb> daf: the story with BugFactory is that it should probably be moved into in the IBugSet interface, possibly creating two different methods: one that creates just the IBug, and the other that Just Works (creates the subscriptions, etc.)
[07:46] <SteveA> bradb: this is similar to the IPersonSet pattern
[07:46] <SteveA> talk to salgado
[07:46] <bradb> PQM WHY ARE YOU NOT WORKING
[07:48] <bradb> elmo: can you bounce pqm please? i've sent two merge requests over the last few hours and have heard nothing back. it appears to have hung.
[07:48] <SteveA> salgado: talk to brad about the person creation API
[07:49] <bradb> SteveA: it's not something i had planned to look at pre-1.0, i was just answering daf's question
[07:49] <ddaa> Keybuk: ping
[07:49] <SteveA> i want IBugSet and IPersonSet to be consistent in this regard.  This is a pattern i want to generally apply.
[07:49] <salgado> SteveA, the person creation API now is only a single method: IPersonSet.createPerson(). ;)
[07:50] <SteveA> salgado: and, does that do all the necessary things?
[07:50] <salgado> that's the only public API we have and it does everything
[07:50] <SteveA> there was a newPerson or new() or something, for creating a Person without the rest of the crap
[07:50] <salgado> we still have that, but it's not public. it's only used by the createPerson() method
[07:50] <kiko> daf, there's some crap called distrotool.py that needs to be moved to sets too
[07:51] <salgado> (although this is not merged yet. I'm waiting for pqm.)
[07:51] <daf> hmmm
[07:51] <elmo> bradb: killed
[07:51] <bradb> cheers
[07:51] <daf> kiko: I didn't look at it too closely
[07:51] <elmo> I had to force kill it, not sure what lock files might be left behind
[07:51] <kiko> daf, I'm trying to get debonzi to do it
[07:51] <bradb> salgado: ^^?
[07:51] <daf> elmo: can you install gettext on the productoin machines?
[07:52] <daf> kiko, bradb: I'm working on fixing up sets right now
[07:52] <kiko> daf, if you want to fix up distrotool.py to NO LONGER EXIST I'd be very appreciative
[07:52] <salgado> bradb, I send my merge request 5minutes ago. I don't think that could have caused pqm to hung
[07:53] <daf> kiko: I'll see what I can do once I've figured out what this bounty stuff is doing
[07:53] <bradb> salgado: no, i mean, are there any lock files hanging around that elmo should know about?
[07:53] <daf> bradb: is the BugSet stuff underway or just scheduled for future cleanup?
[07:53] <salgado> bradb, it depends on what test pqm hang
[07:53] <kiko> daf, just delete the bounty stuff kthxbye
[07:53] <daf> kiko: yessir
[07:53] <bradb> daf: future cleanup
[07:53] <kiko> who wrote that crud anyay?
[07:54] <daf> I don't think anybody uses it
[07:55] <bradb> daf: if you want to fix it, i'd recommend creating just the method that Just Works, so as not bait a prospective user of the API into using the method that Just Doesn't Work (i.e. the theoretically, only-creates-the-IBug method)
[07:55] <bradb> s/cally/cal/
[07:58] <bradb> if anyone knows of any lockfiles that may be left around because of kill -9'ing pqm, could i ask you to please pass that info onto elmo?
[08:00] <salgado> bradb, do you know in what test pqm was hang?
[08:00] <salgado> I mean, when it was killed
[08:00] <jblack> ddaa: ping
[08:00] <jblack> lifeless: ping
[08:01] <bradb> salgado: no
[08:01] <salgado> then it's hard to tell, because all scripts use lockfiles
[08:02] <bradb> salgado: can you just tell him what they are anyway?
[08:02] <bradb> the worst that would happen is that they aren't there, right?
[08:02] <salgado> anyway, all scripts should've put their lockfiles in /var/lock, and there's nothing in there
[08:03] <bradb> interesting
[08:03] <salgado> bradb, if you want to know what they are, you have to look into scripts/* and cronscripts/*
[08:03] <bradb> i don't want to know what they are, but the chinstrap admins probably do
[08:04] <salgado> now you can tell them. :)
[08:06] <bradb> i'll leave that to the guys who wrote them :)
[08:08] <sabdfl> daf, carlos: you around for another hour?
[08:09] <daf> sabdfl: carlos has already left
[08:09] <daf> sabdfl: I'm going out for dinner in about 30 minutes
[08:09] <sabdfl> ok :-(
[08:09] <sabdfl> it's almost pressie time
[08:09] <daf> oh, darn
[08:09] <sabdfl> it'll land tonight then, you'll get it first thing in the morning
[08:10] <daf> ok, cool
[08:15] <kiko> SteveA, I still don't understand the tal:define there
[08:15] <kiko> oh!
[08:16] <kiko> SteveA, does metal:define not cause the block inside of it to be ignored (as a #include would?)
[08:16] <SteveA> metal:define defines something to be included
[08:17] <SteveA> it marks a block of template, and gives it a name
[08:17] <kiko> aha
[08:17] <SteveA> metal:define-macro that is
[08:17] <SteveA> the tag name isn't important
[08:17] <kiko> it isn't?
[08:17] <SteveA> no
[08:17] <SteveA> just the attribute name
[08:17] <kiko> so <metal:define and <metal:use are fluff?
[08:17] <SteveA> yes
[08:17] <SteveA> there needs to be some element there
[08:17] <SteveA> and, if it is in the metal namespace
[08:17] <SteveA> it disappears
[08:17] <SteveA> from the output
[08:17] <kiko> I see
[08:18] <kiko> I see
[08:18] <kiko> so it /isn't/ like an #include
[08:18] <kiko> you misled me
[08:18] <kiko> I thought the macro only expanded when using metal:use-macro
[08:18] <kiko> now I understand
[08:18] <kiko> it's a bit odd though
[08:19] <SteveA> yeah
[08:19] <kiko> thanks
[08:19] <SteveA> it could be nested inside a tal:condition="nothing"
[08:19] <SteveA> to make the original disappear
[08:19] <kiko> that is SO WHAT I EXPECT FROM TAL
[08:19] <kiko> "need else? just use condition not:!"
[08:20] <kiko> "need to make a simple macro definition? just wrap it in condition nothing"! 
[08:20] <daf> better make sure you don't make any calls to any non-idempotent functions inside the macro definition, then
[08:20] <SteveA> why?
[08:20] <kiko> no post processing!
[08:21] <SteveA> i so want to rewrite TAL/TALES using nevow
[08:21] <SteveA> i was talking to the nevow guys about it at EP
[08:21] <SteveA> it would rock, and probably be faster, once optimised
[08:21] <kiko> that would rock the boat
[08:21] <daf> or do the calls  ger made at macro definition time?
[08:21] <SteveA> no calls get made when the macros are defined or used
[08:21] <SteveA> calls get made only when the template is rendered
[08:22] <daf> ha, nevow is another divmod project
[08:22] <daf> we'll be using all of their stuff before long
[08:23] <SteveA> nevow needs more work though
[08:23] <SteveA> it is still new, and various things are unfinished
[08:24] <SteveA> it will be cool when it's baked
[08:24] <SteveA> to mix metaphors a bit
[08:30] <kiko> SteveA, please don't forget linkify kthxbye
[08:31] <bradb> heh
[08:31] <bradb> daf: i'm getting errors that i think are fascism related:
[08:31] <bradb> zope.configuration.xmlconfig.ZopeXMLConfigurationError: File "/home/bradb/launchpad/site.zcml", line 11.4-11.35
[08:31] <bradb>     ZopeXMLConfigurationError: File "/home/bradb/launchpad/lib/canonical/configure.zcml", line 103.4-103.43
[08:31] <bradb>     ImportError: cannot import name IBugMessageSet
[08:31] <SteveA> <a href="/~elmo">kthxbye</a>
[08:32] <bradb> (when make run'ing)
[08:32] <SteveA> __all__ ?
[08:32] <bradb> i dunno, it didn't tell me
[08:33] <bradb> but since you told me, yes, that appears to have fixed it
[08:33] <bradb> thanks
[08:33] <daf> which file was that in?
[08:34] <jblack> ddaa : still ping.
[08:34] <bradb> daf: interfaces/bugmessage.py
[08:34] <SteveA> the fascist will tell you soon
[08:34] <daf> it was just an incomplete __all_ then?
[08:34] <bradb> it might have been a normal python error, to be honest
[08:34] <bradb> daf: yeah
[08:34] <daf> ok
[08:35] <bradb> in my test failure though (from pqm) it mentioned something about an "importd failure", which made me think fascist
[08:35] <daf> yeah, that will be due to me adding an __all__ so import * not importing it
[08:35] <daf> when you added it
[08:35] <bradb> yeah
[08:36] <daf> good to see FooSets getting added
[08:37] <bradb> er, importd == fascist? yeah, i'm on crack. anyway.
[08:37] <kiko> the fascist haxors yo mama
[08:37] <kiko> I'm submerging for a few hours, mail me if you need me
[08:37] <bradb> i will continue to take joy in python's ImportError message with an incomplete __all__
[08:38] <SteveA> note that if you had no __all__ at all
[08:38] <SteveA> it would have worked
[08:38] <SteveA> but the fascist would have forbidden it
[08:43] <Keybuk> ddaa: 'sup?
[08:48] <jblack> keybuk: I don't think he's here. I've been watching out for him for... almost an hour
[08:50] <Keybuk> he ping'd me about an hour ago
[08:50] <Keybuk> just before I popped off for lunch
[08:52] <dilys> New Malone bug 1255 filed on source package koffice by Sander van Loon: Karbon crashes when creating a new document
[08:52] <dilys> https://launchpad.ubuntu.com/malone/bugs/1255
[08:54] <dilys> New Malone bug 1256 filed on product The Launchpad by Matthias Urlichs: gpg key import does not ignore revoked UIDs
[08:54] <dilys> https://launchpad.ubuntu.com/malone/bugs/1256
[08:55] <ddaa> Keybuk: jblack: guys, I'm back for a few minutes
[08:55] <Keybuk> ddaa: you ping'd?
[08:55] <ddaa> Keybuk: yes, hold on
[08:55] <salgado> bradb, being the assignee of a bugtask won't give me the rights to mark it fixed?
[08:56] <bradb> salgado: it should, yeah. though assignee semantics for private bugs are, as yet, unclear.
[08:56] <bradb> (i.e. broken)
[08:57] <bradb> salgado: what bug are you looking at?
[08:57] <salgado> bradb, https://launchpad.ubuntu.com/products/malone/+bugs/926
[08:57] <ddaa> Keybuk: when there is an upstream rcs, and tarballs, but the package comes directly from the rcs, we must not enter the tarballs, right?
[08:57] <salgado> where do I see if it's private or not?
[08:57] <bradb> did you type that URL by hand?
[08:57] <bradb>  /+edit is the edit view
[08:58] <salgado> I can't see any link there pointing to the bug itself
[08:58] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  90% correct fix for #1036 (patch-2039: carlos.perello@canonical.com)
[08:58] <ddaa> Keybuk: otherwise sourcerer will incorrectly try to link the package to arelease tarball?
[08:58] <salgado> bradb, that was the url I got from bugmail
[08:58] <Keybuk> interesting question
[08:58] <Keybuk> I'd enter the tarball anyway
[08:58] <Keybuk> sourcerer should do the right thing
[08:58] <Keybuk> (but probably won't)
[08:59] <bradb> salgado: from the *bugmail*? surely you jest. :)
[08:59] <bradb> can i see that bugmail?
[09:00] <salgado> oh no. from the bugmail, of course, I got the url for the bug itself
[09:00] <salgado> then when I went to the task I wasn't logged in
[09:00] <ddaa> Keybuk: why "probably won't"?
[09:01] <salgado> then I logged in, reload the page hoping I would be able to edit the task
[09:01] <bradb> salgado: ah, so, if we exposed an edit link on the page you're looking at, would that help?
[09:02] <bradb> (in the meantime, you can just manually add /+edit onto the end of the URL)
[09:02] <salgado> bradb, I used to think I'd be redirected to the /+edit if I were logged in
[09:02] <salgado> was that true some time ago?
[09:03] <bradb> no
[09:03] <bradb> it's just that both pages used to be called +edit
[09:03] <Keybuk> ddaa: because I've never tested that it falls back from tarball to looking in CVS
[09:03] <Keybuk> and untested code is broken code
[09:03] <bradb> salgado: but, given the way things look, i can understand why you'd be confused. i would have been too.
[09:04] <ddaa> Keybuk: okay, but if you say you'd enter the tarball location anyway... you're authoritative in that matter.
[09:04] <salgado> bradb, have you realized already that in the bugtask listing, the "id" header is above the checkbox column instead of the id column?
[09:05] <ddaa> I'll have some more questions when I come back.
[09:05] <bradb> salgado: yeah, i merged the fix for that yesterday
[09:05] <Keybuk> ddaa: yup, enter it
[09:05] <salgado> great. :)
[09:05] <bradb> salgado: it appears to be specific to maintainers looking at listing of things they maintain
[09:06] <bradb> the column header that used to be above the checkbox was inadvertently removed, thus everything shifted one column over
[09:07] <salgado> I see.
[09:08] <salgado> btw, those statistics in that right portlet are pretty helpful. 
[09:08] <bradb> that's good to hear
[09:19] <bradb> anyone thought about google maps bling in launchpad?
[09:20] <bradb> might be kind of cool to see a satellite view of where the person lives after you've just filed a bug on their package :P
[09:21] <dilys> New Malone bug 1257 filed on product Bazaar by njt: export latest version
[09:21] <dilys> https://launchpad.ubuntu.com/malone/bugs/1257
[09:23] <dilys> New Malone bug 1258 filed on product Malone by Brad Bollenbach: Focus should land in the title field on the filebug screen
[09:23] <dilys> https://launchpad.ubuntu.com/malone/bugs/1258
[09:24] <salgado> bradb, so, I have bug X which is a duplicate of bug Z. but the tasks of X still show up as new. should I reject all of X's tasks?
[09:24] <salgado> or, even better, should this be done automatically when I mark a bug as a duplicate?
[09:24] <bradb> salgado: i'd leave it for now. we haven't yet decided on the best plan forward for that. at the least, it's clearly marked on that page that one is looking at a dup.
[09:25] <bradb> you've brought up something that will be important to think about after 1.0 though, IMHO
[09:26] <salgado> cool. I'll file a bug on that
[09:26] <bradb> great, thanks
[09:26] <bradb> heh
[09:28] <salgado> bradb, from the task page, how do I go to the bug one? (I need the bug id)
[09:29] <bradb> interesting question
[09:29] <bradb> you're looking at the task page
[09:29] <bradb> you need the bug id
[09:30] <bradb> ok, i probably am breaking some rules in telling you this, but the ID you see on that page is the bug id
[09:30] <bradb> what's interesting here is that it wasn't obvious to you that it was the bug id
[09:31] <salgado> because they used to be different
[09:31] <bradb> this may be an artifact of you being used to the days of two different IDs
[09:31] <bradb> indeed
[09:32] <bradb> salgado: the good news is that the "task id" has been completely banished from userland Malone
[09:32] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=salgado]  FormattingBugNotifications implementation. requires some minor additions to be fully spec-compliant. (patch-2040: brad.bollenbach@canonical.com)
[09:33] <salgado> bradb, I realized that. now we're using the context and the bug id
[09:33] <salgado> to get the right task
[09:34] <bradb> right
[09:34] <bradb> salgado: have i actually answered your question, btw? :)
[09:35] <bradb> fwiw, when i last checked, there was no actual link
[09:35] <bradb> but ISTR kiko might have done something about that. i'd have to verify.
[09:35] <salgado> bradb, you mean, an actual link to go to the bug page from the task one?
[09:35] <bradb> right
[09:38] <salgado> is there any way to go to the bugtask page (not manually hacking the url) without first going to the bug page?
[09:38] <bradb> salgado: no
[09:39] <bradb> salgado: do you have a couple minutes? why don't you tell me a bit about the workflow you're in right now.
[09:39] <salgado> because right after asking that question I realized that I had come from the bug page, and thus I could go back to see the bug id (at that time I was thinking that the id I was seeing was the task id)
[09:40] <bradb> out of curiousity, why did you need the bug id?
[09:41] <salgado> at this time I'm mainly doing some triaging. I look for foaf-related bugs reported either in the foaf or the launchpad products
[09:41] <salgado> I wanted the bug id to mark another bug as a duplicate
[09:42] <bradb> so, you were looking at the task of the dup-target, right?
[09:42] <bradb> er, n/m
[09:42] <bradb> i see then
[09:43] <salgado> exactly. I wanted to accept the bug that was first reported, so I went to the task page
[09:43] <salgado> then I realized there was a dupe and went to mark it as a dupe
[09:44] <bradb> right
[09:45] <salgado> in the meantime I forgot that I went to the bug page before going to the task
[09:46] <jblack> stub: ping
[09:46] <bradb> interesting
[09:47] <bradb> salgado: when you wanted to go back to the bug page, what did you try to do to go back?
[09:47] <bradb> (it'd have been better if i were in front of you watching you do this, but oh well :)
[09:48] <salgado> I looked for a link, then came here and asked
[09:48] <bradb> ok
[09:48] <salgado> then I realized how to do it, but waited to see your answer. ;)
[09:49] <salgado> bradb, the problem with dupes is that we don't have bug listing, like bugzilla
[09:50] <salgado> we have task listings. then the tasks of the dupe will show up in these lists
[09:50] <bradb> there's a bug open on that. we should be able to filter to not show tasks of dup bugs
[09:51] <salgado> ah, cool
[09:51] <bradb> but, there's a risk that that breaks when one of the bugs has just one task and it's on Foo and the other has just one task on it's on Bar
[09:51] <bradb> it /probably/ won't be noticeable at the beginning, but it's a bit up-in-the-air until we nail down the task-merging semantics of dup bugs
[10:01] <SteveA> has anyone been experiencing hangs when running the test suite on their own machine?
[10:04] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  add more __all__ statements, other minor tidyings-up (patch-2041: daf@canonical.com)
[10:08] <ddaa> Keybuk: so, other questions
[10:10] <jblack> ddaa: Back? 
[10:10] <ddaa> Some projects have no rcs, but do have downloadable tarballs but: 1. they may have no indication of version (the latest version of drac is always available as drac.tar.Z), or the only tarball available may not be the one used by the package (like eject).
[10:10] <SteveA> as gdb showed the process to be blocked on a lock of some kind
[10:11] <ddaa> Keybuk: in those cases I have just not input the ftp details as I think that would cause sourcerer to go wrong.
[10:11] <ddaa> jblack: I'm here.
[10:12] <jblack> Ok. 
[10:12] <ddaa> Keybuk: sounds reasonable?
[10:12] <jblack> You're either gonna love me, or you're gonna hate me. 
[10:12] <Keybuk> there's no way to input that into dyson anyway
[10:12] <jblack> I hope its the former. If just did a handful of commits. You may want to update. 
[10:12] <Keybuk> it wouldn't be able to create a ProductRelease entry if it can't get a version
[10:12] <ddaa> Keybuk: what do you mean? sure I can file the ftp details so it will download such tarballs.
[10:12] <Keybuk> dyson creates the database record for the product release
[10:13] <jblack> I also hit both or your trees, dumping cvsroots and descriptions into a bunch of files. 
[10:13] <Keybuk> it can't do that if it can't parse the tarball filename to get a version
[10:13] <ddaa> Keybuk: okay that sorts out drac and a most of festival data packages...
[10:13] <ddaa> but not eject, where the available tarballs have versions, just not the one used by debian...
[10:14] <ddaa> but...
[10:14] <ddaa> mh...
[10:14] <ddaa> Keybuk: I'd like to know more about this version matching thing, that can probably tell us important things about what is not worth bothering about.
[10:14] <ddaa> s/debian/ubuntu/
[10:15] <Keybuk> "version matching thing" ?
[10:15] <ddaa> dyson parse the tarball name to get a version
[10:15] <ddaa> I guess that is used when matching release tarballs to source packages, right?
[10:16] <Keybuk> huh?
[10:16] <Keybuk> nothing to do with that
[10:16] <ddaa> mh...
[10:17] <ddaa> I assumed that packages were associated to product releases
[10:17] <Keybuk> dyson creates ProductRelease records, places the associated tarball in the librarian, and creates a ProductReleaseFile record to link the two
[10:17] <Keybuk> one of the NOT NULL fields of ProductRelease is 'version'
[10:19] <ddaa> mh... I think this line of discussion is not going to lead us anywhere.
[10:20] <jblack> Well, if you guys are done, I could use some time, ddaa? 
[10:20] <ddaa> jblack: just ask
[10:20] <jblack> first, you may want to merge the import tree. 
[10:20] <jblack> I'll be pointing at specific things.
[10:21] <jblack> (btw, DUCK) 
[10:22] <ddaa> Keybuk: consider eject. breezy packages eject_2.0.13deb.orig.tar.gz, but the ftp repo only has eject-2.1.0.tar.gz. And there is no rcs. Would that be harfmul to enter that ftp data? Would that be useful?
[10:23] <Keybuk> yes
[10:23] <ddaa> jblack: okay, I'm eyeballing my uncommitted stuff, then I'll update.
[10:23] <ddaa> Keybuk: yes, harfmul? Or yes, useful?
[10:23] <Keybuk> useful
[10:23] <ddaa> and not harmful?
[10:23] <jblack> ddaa: Ok. I walked into your tree too, btw. I came across a load of descriptions, and put them into the appropriate files in your queue dir. 
[10:28] <ddaa> jblack: all that new data, is that some sort of automated collating?
[10:28] <jblack> No sir. Thats me missing work. 
[10:29] <ddaa> You mean, you've been essentially making info files instead of entering the data into launchpad?
[10:42] <bradb> anyone have the requisite computer science degree to tell me what i need to do to give a field focus (by default) in an autogenerated z3 form?
[10:45] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Simplify the people creation API a lot; now we have only IPersonSet.createPersonAndEmail() which will do everything that's needed. r=jamesh (patch-2042: guilherme.salgado@canonical.com)
[10:48] <SteveA> you'll want a custom widget, and pass in a custom arg "tabfocus" or something like that
[10:49] <bradb> i tried "tabindex" earlier
[10:49] <bradb> in ZCML, tabindex=1
[10:50] <bradb> it changed nothing in the rendered output
[10:50] <bradb> ah, but the extra="" property may be the ticket
[10:51] <bradb> extra="tabindex=1" did it
[10:53] <SteveA> that's the badget
[10:53] <SteveA> badger
[11:11] <SteveA> Kinnison: is archivepublisher/pool.py yours?
[11:17] <bradb> SteveA: got a minute for a quick question about making a custom SinglePopupWidget via the browser:widget directive?
[11:17] <SteveA> not really
[11:17] <SteveA> gotta go to sleep
[11:18] <bradb> ok :)
[11:19] <SteveA> bradb: have you had any hangs while running tests?
[11:19] <SteveA> i think i was getting one, and i think pqm's been getting them
[11:19] <SteveA> as an experiement, i've turned off a bunch of the locking in the sqlobject caches.
[11:19] <SteveA> it shouldn't matter for us anyway.
[11:19] <SteveA> not in RF yet.
[11:21] <bradb> i believe i've seen them in pqm (which is why i got elmo to bounce pqm earlier)
[11:22] <SteveA> i'll bounce the "remove locks" idea off stub tomorrow
[11:22] <SteveA> and see if he thinks it is as sane as i think it is
[11:51] <SteveA> the  new fascist will be landing shortly (i hope) (pqm permitting)
[11:52] <SteveA> don't just add the names requested to __all__.  think carefully about whether they should be there or not.
[11:52] <SteveA> for example, i need to fix up one case where Item is being imported from DBSchema
[11:52] <SteveA> for an isinstance test
[11:52] <SteveA> whereas, IItem should be used.  But, IItem does't yet exist.