[05:08] <mdke> hi there any launchpad types around right now?
[05:08] <mdke> my problem is the following
[05:08] <mdke> i have a number of email addresses registered under my lp account. One is set as my contact address, however my wiki subscriptions go to a different address, and I wish them to go to my contact address!
[05:15] <lifeless> mdke: mmm
[05:16] <lifeless> mdke: I think you should file a bug for that
[05:18] <mdke> okies
[05:21] <mdke> lifeless, ok filed as 1220
[05:22] <lifeless> thanks
[05:22] <lifeless> spiv, the guy that wrote the moin integration is on leave just now
[05:23] <lifeless> I don't know if anyone else will pick it up before he comes back or not
[05:24] <mdke> moin integration?
[05:25] <lifeless> mdke: the wiki <-> launchpad linkage
[05:26] <mdke> the auth linkage?
[05:27] <lifeless> yah
[05:27] <mdke> ah
[05:28] <mdke> it would be pretty cool to have the ability to register when on the wiki too
[05:29] <mdke> i hear a lot of people who can't find how to register to post on the wiki (admittedly due to a lack of instructions on the wiki page, but still)
[05:29] <lifeless> yes, I hear that that is on the todo list
[05:29] <mdke> oh great
[05:29] <lifeless> (better instructions and a link)
[05:30] <mdke> oh yes that definitely is
[01:06] <SteveA> sabdfl: no reason at all
[01:06] <sabdfl> :-)
[01:06] <sabdfl> daf: those two projects were ddtp-ubuntu and?
[01:07] <daf> sabdfl: drupal
[01:07] <sabdfl> daf: ddtp-ubuntu seems OK
[01:07] <sabdfl> there is only one productrelease
[01:07] <sabdfl> maybe the query i gave you was borked?
[01:08] <daf> could be
[01:08] <daf> or maybe a difference between staging and production?
[01:08] <sabdfl> i'm looking at production
[01:08] <sabdfl> staging could only have less data
[01:11] <daf> I have to go and talk to the estate agents for a bit
[01:15] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Bug 1204 - add +sourceadmin links to product page for buttsource team (patch-1998: morgan.collett@canonical.com)
[01:16] <daf> sabdfl: looked more closely at the staging data
[01:16] <daf> sabdfl: looks like drupal has 6 product series, with 1 potemplate on each
[01:16] <daf> 6 series is a lot, maybe they got confused
[01:16] <daf> same for ddtp-ubuntu
[01:17] <daf> 4 series
[01:17] <daf> right, back later
[01:17] <sabdfl> daf: i dont think that's the case
[01:17] <daf> doh!
[01:17] <daf> I was reading those columns the wrong way around
[01:17] <sabdfl> they are all the same series
[01:17] <sabdfl> so we are ok
[01:18] <daf> 6 po templates on drupal's product series 178
[01:18] <daf> 4 po templates on ddtp-ubuntu's series 3964
[01:19] <daf> (names 'main' and 'ubuntu' respectively)
[01:19] <sabdfl> so as long as the query didn't hide other problematic products, we should be ok
[01:20] <sabdfl> stub will get us a definitive answer shortly
[01:20] <sabdfl> i've fixed the issues bjornt raised, just running tests now
[01:20] <sabdfl> if it looks good, i'll land it shortly
[01:39] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=Steve]  translation groups browser code cleanup (patch-1999: daf@canonical.com)
[01:42] <stub> sabdfl: There are only two
[01:42] <stub>  ddtp-ubuntu | ubuntu
[01:42] <stub>  drupal      | main
[01:42] <stub> (product.name | productseries.name )
[01:49] <morgs> sabdfl, daf, stub: ddtp-ubuntu is mvo's product for translating ubuntu stuff not imported into LP yet...
[01:51] <morgs> We had a discussion about 2 weeks ago about how to mangle^Wstructure the product / series / release so that he could represent ubuntu -> breezy -> main and ubuntu -> breezy -> universe etc.
[01:51] <morgs> So if the structure is wrong, please suggest to mvo how it should be set up..
[02:04] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  use higher-level Librarian API in POFile DB code (patch-2000: daf@canonical.com)
[02:11] <lifeless> wooo
[02:11] <lifeless> daf gets patch 2L
[02:14] <SteveA> WARNING: patch log robert.collins@canonical.com/buildbot--devel--0--patch-169 has been deleted from tree /scratch/dists/launchpad.
[02:14] <SteveA> The best merge point may not be chosen
[02:14] <SteveA> lifeless: any idea what that's about?
[02:18] <lifeless> SteveA: yes, its considering that as a base for the merge, but it can tell that its not present - which is correct
[02:18] <lifeless> so its telling you about that so that if you get a weird merge, you know
[02:19] <SteveA> i see, i think
[02:19] <SteveA> i was confused seeing a message about buildbot for an operation on the launchpad tree
[02:20] <lifeless> we joined the trees to move the importd code across
[02:20] <lifeless> but its not a full merge which is why that warning is appearing
[02:20] <SteveA> okay, that makes sense
[02:20] <SteveA> magic crowbar merging
[02:20] <lifeless> yes
[02:29] <SteveA> BjornT: hello
[02:30] <SteveA> BjornT: i got a test failure on xx-upstream-bug-task-listing-submitted-by-me.txt, which i can't reproduce running that test in isolation. 
[02:30] <SteveA> the error was a re-ordering of results.
[02:30] <SteveA> i wonder if there's some query that should have an orderby that doesn't have on.
[02:31] <SteveA> i also get an error with 40-private-upstream-bug-not-visible-to-nonsubscriber-user.txt
[02:31] <BjornT> SteveA: ok, i'll take a look at it
[02:31] <SteveA> reproducable by running python test.py -f canonical.launchpad.ftests.test_pages
[02:34] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  add a menus debug page on +debug-menus. (patch-2001: steve.alexander@canonical.com)
[02:40] <daf> salgado: did what Steve said answer your question?
[02:40] <salgado> daf, yep. :)
[02:41] <daf> ok :)
[02:41] <daf> where's kiko today?
[02:41] <SteveA> daf: latest merge into RF will be useful information to diagnose menus problems.
[02:41] <daf> excellent!
[02:41] <SteveA> it is probably sufficient information for me to fix menus problems, on its own.
[02:41] <daf> is there a fix for the problem I found this morning?
[02:41] <SteveA> i'm working on that
[02:41] <SteveA> i need to break for lunch very shortly
[02:42] <daf> ok
[02:42] <daf> I need to go back out shortly
[02:43] <Keybuk> what's this one?
[02:43] <SteveA> hi scott
[02:43] <SteveA> this is where we're discussing things now
[02:43] <Keybuk> is launchpad-dev going?
[02:44] <SteveA> we'll see how it goes here for a week or so
[02:44] <SteveA> if it works well with just the one channel, we'll stick with that
[02:45] <jamesh> sabdfl: review sent
[02:47] <sabdfl> jamesh: thanks, you're a star, is it a train smash?
[02:48] <BjornT> SteveA: the tests pass for me, but i think i know what's wrong. in BugTask.search we need to make sure that id is always present in the orderBy parameter. i'll fix it.
[02:49] <BjornT> s/BugTask/BugTaskSet/
[02:49] <jamesh> sabdfl: there were a number of issues I noticed.  Probably not much more than I'd expect for a diff that size
[02:50] <sabdfl> daf: did stub come up with any surprises on the productseries / release / potemplate thing?
[02:50] <sabdfl> jamesh: ok, thanks, i'll try land it today
[02:52] <lifeless> sabdfl: btw, the CIA guy is starting at vmware the week after the baz sprint, hes to busy to come as hes moving house
[02:52] <daf> sabdfl: he said:
[02:52] <daf> 12:42:30 <stub> sabdfl: There are only two
[02:52] <daf> 12:42:32 <stub>  ddtp-ubuntu | ubuntu
[02:52] <daf> 12:42:32 <stub>  drupal      | main
[02:52] <daf> 12:42:46 <stub> (product.name | productseries.name )
[02:52] <daf> so, no suprises
[02:52] <daf> salgado: where's kiko?
[02:53] <lifeless> sabdfl: also, aaron bentley can't come, nor can John Meinel - work and presenting a phd respectively.
[02:53] <lifeless> sabdfl: I'd like to invite Matthieu Moy who is doing a lot of UI work for baz, and patch merging - is that ok.
[02:53] <daf> Matthieu seems to be doing a ton of stuff recently
[02:53] <SteveA> BjornT: great.  do you know if there was any warning indicating there would be a problem?
[02:53] <kiko> me
[02:53] <kiko> what's up?
[02:54] <SteveA> yo kiko, dude
[02:54] <daf> it's the kiko
[02:54] <lifeless> kicking it with kiko
[02:54] <kiko> omg it's the #launchpad gang
[02:54] <SteveA> i'm about to [trival]  in an improvement to the fascist to make it less ugly when complaining
[02:54] <daf> kiko: didja get my mail from yesterday?
[02:54] <jamesh> kiko: see the new pending-reviews page?
[02:56] <kiko> daf, I should have -- which one?
[02:56] <kiko> jamesh, yeah, looks neat!
[02:56] <daf> kiko: the pyflakes harness
[02:56] <kiko> jamesh, the "%d conflicts" text is wrapping oddly though
[02:57] <kiko> daf, ah, sure did -- we look pretty bad eh? :)
[02:57] <jamesh> kiko: just make your browser window a bit wider :)
[02:57] <daf> kiko: yup :)
[02:57] <SteveA> nbsp ?
[02:57] <daf> kiko: well, the import * ones are mostly ok, I think
[02:57] <jamesh> SteveA: yeah.  That would probably work
[02:57] <daf> kiko: but the undefined names are red flags
[02:58] <daf> kiko: and the 750-odd unused imports aren't too good
[02:58] <kiko> jamesh, I can't, it's overflowing into my desk :)
[02:58] <kiko> debonzi, ping?
[02:58] <debonzi> kiko, pong
[02:58] <daf> jamesh: or just put the number there, with "Status (conflicts)" in the header
[02:58] <daf> jamesh: and "merge (3)" in the body
[02:58] <kiko> debonzi, did you take care of the stuff I asked you about on friday?
[02:59] <SteveA> daf: import * is okay only when what you're importing from provides an __all__
[02:59] <daf> or make a separate column for conflicts
[02:59] <jamesh> daf: sounds reasonable
[02:59] <daf> SteveA: yes -- unfortunately, pyflakes doesn't distinguish yet
[02:59] <SteveA> daf: there's an approved merge from andrew that makes the fascist complain about that in our code
[02:59] <debonzi> kiko, nop yet... I intend to do that today
[02:59] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Bug 1203: add FTP release root details to +sourceadmin (patch-2002: morgan.collett@canonical.com)
[02:59] <kiko> debonzi, please do
[02:59] <daf> SteveA: yeah, I saw it
[02:59] <SteveA> daf: i'll merge that sometime soon
[02:59] <daf> great
[02:59] <SteveA> seeing as i'm just about to trivial-in a conflict to it
[02:59] <debonzi> kiko, yep
[02:59] <BjornT> SteveA: i don't think there are any warnings for these kind of problems. maybe there should be a warning if you order by only non-unique columns?
[02:59] <kiko> lifeless, are you around to hep me fix any issues with merging? :)
[02:59] <lifeless> kiko: sure
[03:00] <kiko> thanks
[03:00] <kiko> will try shortly
[03:00] <lifeless> kiko: though it is 11, I will be retiring soonish
[03:00] <SteveA> BjornT: can you file a bug on that and assign it to andrew?
[03:00] <SteveA> he can look into it when he gets back from vacation
[03:00] <BjornT> SteveA: sure
[03:00] <SteveA> thanks
[03:09] <lifeless> sabdfl: ping
[03:10] <sabdfl> lifeless: pong
[03:10] <lifeless> sabdfl: did you see my comments about attendees for brazil ?
[03:10] <lifeless> sabdfl: 17 minutes up in your scrollback
[03:11] <sabdfl> lifeless: is he involved with both baz and baz-ng?
[03:12] <dilys> New Malone bug 1227 filed on product The Launchpad by Bjorn Tillenius: Ordering by only non-unique columns should produce a warning.
[03:12] <dilys> https://launchpad.ubuntu.com/malone/bugs/1227
[03:12] <lifeless> yes, with a bias to the baz codebase
[03:12] <lifeless> active on the bzr list
[03:17] <lifeless> sabdfl: ^^^
[03:17] <sabdfl> lifeless: perfect
[03:17] <sabdfl> will need to get cracking on a visa, probably
[03:17] <sabdfl> where is he coming from?
[03:18] <lifeless> sabdfl: yup, I'll email him right this minute
[03:18] <sabdfl> cool
[03:18] <lifeless> france
[03:19] <lifeless> at least, thats his email domain - .fr
[03:20] <kiko> he won't need a visa then
[03:20] <kiko> he will need accomodation and transport sorted out, though
[03:22] <lifeless> email sent
[03:23] <kiko> mpt?
[03:23] <lifeless> kiko: can you talk with ddaa/jblack/keybuk if you have a merge problem
[03:23] <lifeless> 11:30 - sleep time
[03:23] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Remove DOAP from pagetitles (patch-2003)
[03:23] <kiko> lifeless, the problem is that merge trouble will be PQM-related
[03:23] <kiko> I've been waiting for 20m for a star-merge
[03:23] <mpt> kiko!
[03:23] <mpt> kiko, who's Juliana Godinho?
[03:23] <Keybuk> it's worth noting that if your merge problem is huge numbers of conflicts/problems, it's likely that mesh-merge broke -- sometimes "merge --star-merge" (which is what PQM still does, iirc) works
[03:24] <kiko> lifeless, can you at least double-check if my setup on your side looks okay?
[03:24] <kiko> mpt, no idea -- why?
[03:24] <mpt> kiko: She wants to be my Orkut friend and she's from Sao Paulo, so I assumed it was your doing
[03:25] <kiko> mpt, sabdfl, BjornT: I think if we are to keep the bugtask and bug pages separate (not go with the context-sensitive pages) then I think we should start using the Task word in the UI and using that in our documentation.
[03:25] <lifeless> kiko: its building a merge for stub at the moment
[03:25] <kiko> mpt, following that rationale I think it should be Task Notes or Task Whiteboard
[03:25] <kiko> it has nothing to do with status
[03:25] <lifeless> kiko: was 23:23 < dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Remove DOAP from pagetitles (patch-2003)
[03:25] <lifeless> meant to be yours ?
[03:25] <mpt> kiko: It's to do with status 80~90% of the time
[03:26] <mpt> well, perhaps that's a bit presumptuous of me
[03:26] <sabdfl> kiko: i'll make some further planned tweaks, then let's see if you're happier
[03:26] <mpt> but it'll be about that once keywords are implemented
[03:26] <kiko> lifeless, nope.
[03:26] <sabdfl> mpt: is she hot?
[03:26] <kiko> lifeless, I won't keep you -- just pray that PQM will work for me
[03:27] <lifeless> kiko: ok, night
[03:27] <kiko> mpt, what is presumptuous is thinking that people will associate "Status" with the current situation of the task.
[03:27] <mpt> sabdfl: yeah, but a bit young, even for me
[03:28] <kiko> saying Task Notes or Task Whiteboard helps also associate the information with the task
[03:28] <kiko> which is a good thing since the content there isn't posted anywhere
[03:28] <kiko> (and I think that's a pretty confusing thing)
[03:28] <mpt> what do you mean by "posted anywhere"?
[03:28] <lifeless> night all
[03:29] <kiko> mpt, emailed?
[03:29] <kiko> oh, it is actually
[03:29] <mpt> yes
[03:29] <kiko> mpt, your rename didn't change the mail notification for "explanation of status"
[03:29] <kiko> so now the label in the web UI and email differ
[03:29] <mpt> kiko: https://launchpad.ubuntu.com/malone/bugs/677
[03:29] <mpt> arg, I thought I changed all occurrences
[03:29] <mpt> maybe I was just looking in templates/
[03:30] <mpt> I'll fix that
[03:30] <kiko> mpt, read the description of that bug
[03:30] <kiko> mpt, that bug is arguing for a bug summary
[03:30] <kiko> which we already have!
[03:30] <mpt> er, no it's not ...
[03:31] <kiko> it /is/
[03:31] <mpt> "Fix has been backported from CVS and pending for 6.8.2-11; in the meantime, http://people.ubuntu.com/~daniels/radeon_drv.o fixes it" is no way a bug summary
[03:31] <kiko> Currently, if I were to look at a complicated X bug, I'd have to look through about a bajillion comments, some of which may or may not be relevant, to find what's currently going on.
[03:31] <kiko> -- danielst
[03:31] <mpt> It's talking about the *status* of the bug in a particular place
[03:32] <kiko> mpt, that's not the use case the reporter described in the bug description.
[03:32] <kiko> well
[03:32] <kiko> I see your point
[03:33] <kiko> but there are (unfortunately) two different things -- the status of the bug, which evolves over time, and the status of the task, which also evolves
[03:33] <mpt> A summary of the bug is "The cursor goes flickery on a secondary monitor with a Radeon driver."
[03:33] <kiko> by "status of the bug" I perhaps mean "diagnosis of the bug".
[03:33] <kiko> yes
[03:33] <kiko> right
[03:33] <kiko> and that in many cases evolves
[03:33] <kiko> it may have started out as
[03:33] <mpt> Yes, which is why it's editable :-)
[03:34] <kiko> ""The X pointer goes flickery"
[03:34] <mpt> though people used to other bug trackers won't do that as often as they should
[03:34] <kiko> right
[03:34] <kiko> right
[03:34] <kiko> at any rate, that bug is now double-fixed.
[03:35] <mpt> true enough
[03:36] <SteveA> hi bradb 
[03:36] <bradb> hey SteveA 
[03:36] <kiko> sabdfl, okay, but if we are to segregate the task and the bug completely, then we need to have a name to call the former, and Task is as good as any.
[03:39] <kiko> sabdfl, I'm going to land my branch of (partially experimental) malone changes; you let me know what you thought and we can tweak or revert parts
[03:45] <salgado> mpt, around?
[03:49] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  linkreport.py tweaks (patch-2004: stuart.bishop@canonical.com)
[03:56] <SteveA> daf: i've fixed the menus bug you reported.  i need to do a little rearranging of the tests before i commit it.
[03:56] <daf> ok
[03:57] <daf> just let me know when I can merge
[03:58] <mpt> salgado: barely
[04:04] <salgado> SteveA, how do I get the index of the item I'm iterating on, inside a tal:repeat?
[04:05] <salgado> mpt, nevermind, I already sorted out the problem I had
[04:05] <mpt> k
[04:06] <SteveA> salgado: for future reference, http://www.devshed.com/c/a/Zope/ZPT-Basics-part-3/1/
[04:07] <SteveA> repeat/thing_you_are_iterating_on/index
[04:07] <kiko> Kinnison, cprov: how's the buildd merging coming along?
[04:08] <Kinnison> kiko: I was going to catch up with cprov at 15:30 my time
[04:08] <cprov> kiko: 75% done
[04:08] <SteveA> http://www.owlfish.com/software/simpleTAL/tal-guide.html
[04:08] <Kinnison> kiko: but there's an answer for you in the meantime :-)
[04:08] <SteveA> simpleTAL does not fully comply with the TAL / TALES specification
[04:08] <kiko> bradb, sabdfl: weren't we going to nuke the /malone in /malone/bugs -- ?
[04:08] <SteveA> but, the reference for the 'repeat' variable is correct
[04:08] <cprov> kiko: I'm finishing gpg-ng review too
[04:08] <kiko> okay cool
[04:08] <bradb> kiko: i don't know.
[04:08] <salgado> SteveA, great. thank you ;)
[04:09] <kiko> sabdfl?
[04:09] <bradb> kiko: but if MaloneFrontPages has anything to say about it, then that may be the direction in which we're heading
[04:10] <bradb> and i was planning to work on that right after the FBN code response/merge is complete (hopefully this morning)
[04:10] <kiko>  sabdfl, is there not a way of constructing a link to a remote bug for a watch?!
[04:11] <SteveA> how do i remove a lock on a revision in my mirror on chinstrap?
[04:11] <Kinnison> SteveA: baz lock-revision -b sftp:/......
[04:12] <bradb> if not, it probably should
[04:14] <sabdfl> kiko: yes, there is, BugWatch.url (but it's in debbugssync, which just got reviewed and which i hope to land today)
[04:15] <bradb> SteveA: are canonical URLs "scriptable" at all? given an object for which there is a canonical URL, can i write an arbitrary little bit of code in some little black box somewhere to calculate the canonical URL in my own way (e.g. for external bug watches)?
[04:15] <sabdfl> bradb: canonical_url gives the url INSIDE LP
[04:15] <sabdfl> you;ll need something else to link to the bug outside
[04:15] <bradb> ah, ok
[04:16] <sabdfl> BugWatch.url is in debbugssync, landing today
[04:16] <bradb> makes sense
[04:16] <sabdfl> bradb, SteveA: is there a fix in RF for that bug ordering issue? i'm seeing it too
[04:16] <SteveA> bjorn is on it
[04:16] <SteveA> BjornT: ?
[04:17] <sabdfl> will it not show up on chinstrap? if so, i could land immediately
[04:17] <SteveA> sabdfl: feeling lucky?
[04:17] <SteveA> give it a try...
[04:17] <kiko> ah
[04:18] <BjornT> SteveA: i haven't started yet with it, but i'll do it now
[04:34] <sabdfl> Keybuk: have you landed hct-enable yet?
[04:34] <Keybuk> hasn't been approved yet
[04:34] <Keybuk> just spoke with jamesh about that, not 5 minutes ago, in fac t
[04:34] <Keybuk> apparently your debbugs branch had it merged in?
[04:35] <jamesh> sabdfl: your branch includes half the patches in Keybuk's branch.  I was thinking it would be better to get one merged in before reviewing the other, so I don't get you both fixing the same problems in different ways and creating conflicts
[04:43] <bradb> SteveA, kiko: does this mean the ML is public now too?
[04:43] <kiko> not yet AFAIK, but that was the intention.
[04:43] <bradb> interesting
[04:44] <bradb> and the wikis?
[04:44] <bradb> (er, at least the LP wiki?)
[04:44] <dilys> New Malone bug 1228 filed on product Sympa by Olivier Salan: Empty msgstr entries replaced with 24 white spaces
[04:44] <dilys> https://launchpad.ubuntu.com/malone/bugs/1228
[04:45] <kiko> bradb, the intention was the LP wiki moving into the new public wiki
[04:45] <bradb> whoa, cool
[04:45] <jamesh> the reviews mailing list archives are public (but not advertised)
[04:46] <bradb> was that intentiona? :)
[04:46] <bradb> intentional, even
[04:46] <kiko> not sure.
[04:47] <jamesh> probably not
[04:48] <sabdfl> SteveA: did you create an archive called  steve.alexander@canonical.com--z8 ?
[04:49] <sabdfl> Keybuk: yes, i merged it in because it was small, and i expected it to be landed last week
[04:49] <sabdfl> so i wanted to get a head start on resolving any conflicts
[04:50] <sabdfl> if i hand a branch off to you, please don't let it sit out there
[04:50] <Keybuk> I haven't been
[04:50] <sabdfl> i handed it off to you a week ago
[04:50] <Keybuk> yes, and I put it up for review immediately
[04:50] <Keybuk> and have been merging your changes from there
[04:51] <Keybuk> and resolving conflicts with rocketfuel
[04:51] <Keybuk> and I've nagged daily about getting branches, including that one, reviewed
[04:52] <Keybuk> I've even spoken to kiko and SteveA about the current review bottleneck
[04:52] <sabdfl> seems crazy that a small branch like that has not been reviewed yet
[04:52] <Keybuk> indeed
[04:53] <bradb> sabdfl: SteveA might not be around, but yes, he created that archive for, IIRC, his blazing fast workstation
[04:53] <bradb> something about it being tricky to work with one archive across two different machines
[04:53] <Keybuk> there seems to be a week backlog on reviews
[04:54] <sabdfl> who added the +sourceadmin link on the product page?
[04:54] <morgs> sabdfl: me, it's for Admin only
[04:54] <morgs> requested by ddaa
[04:54] <sabdfl> morgs: even so, i don't want to go scattering arbitrary action links into the pages themselves
[04:55] <morgs> OK, do you have any suggestions, or should I just revert?
[04:55] <Keybuk> so I think I've done everything I can do for that branch, short of flying out, holding a gun to a reviewer's head, and making them review it :p
[04:55] <sabdfl> morgs: i'll revert when landing debbugssync
[04:55] <morgs> OK
[04:56] <sabdfl> Keybuk: ok, thanks
[04:56] <sabdfl> next time, please say "these have sabdfl changes in them" i.p.o. the gun
[04:56] <Keybuk> it does actually say that on the PendingReviews page
[04:56] <Keybuk> I put it there in the hope it would speed it up a bit
[04:58] <Keybuk> ...now I'm getting distracting flashbacks of a scene from Swordfish
[04:59] <kiko> perhaps the worst movie featuring computers ever
[05:00] <Keybuk> it has Halle Berry in it, not wearing very much ... this makes me somewhat forgiving of its other faults
[05:00] <jamesh> sorry about missing the branch last week -- I was working on other things and didn't put in enough time on reviews
[05:00] <daf> kiko: so, do you think it's worth committing flaky.py?
[05:01] <kiko> daf, I do think so, yes -- and SteveA and stub will know how to better deal with making it a part of the process
[05:02] <daf> kiko: it has pyflakes as a dependency
[05:02] <kiko> that's true -- and unpackaged pyflakes at that.
[05:02] <kiko> we could include it, of course.. :)
[05:03] <daf> yup
[05:03] <daf> we could get the arch team to import it
[05:03] <daf> then just use their import in the LP config
[05:05] <kiko> sounds good
[05:05] <kiko> talk to jblack or ddaa about it :)
[05:07] <ddaa> daf: here
[05:08] <daf> ok
[05:08] <daf> can we get pyflakes imported into arch?
[05:08] <daf> if I give you the details
[05:08] <daf> it's in svn somewhere
[05:08] <ddaa> daf: something prevents you from filling in the details on launchpad?
[05:08] <daf> my own ignorance?
[05:09] <ddaa> daf: are you willing to learn?
[05:09] <daf> of course!
[05:09] <daf> I'm guessing I need to go to the registry
[05:11] <ddaa> Yes. You need to look for the product
[05:11] <ddaa> https://launchpad.ubuntu.com/products?text=pyflakes
[05:11] <daf> is browser/sshkey.py dead or what?
[05:11] <ddaa> you can also create a new product from the registry home page https://launchpad.ubuntu.com/doap
[05:12] <ddaa> On the product creation page, you fill in the name, summary, description and homepage.
[05:13] <daf> done
[05:13] <daf> https://launchpad.ubuntu.com/products/pyflakes
[05:14] <daf> what next?
[05:14] <ddaa> Then you create a series (Add Branch) for the mainline, and fill in the svn details.
[05:14] <ddaa> In the meantime, I review your product.
[05:14] <sabdfl> erk
[05:14] <sabdfl> how do i stop a pqm merge?
[05:15] <sabdfl> lifeless: ^?
[05:15] <ddaa> daf: good job, product approved as is.
[05:15] <sabdfl> could you remove the one I just submitted please?
[05:15] <Keybuk> he's in bed :-/
[05:15] <kiko> sabdfl, lifeless is asleep by now
[05:16] <daf> sabdfl: a workaround is to temporarily move your mirror on chinstrap out of the way
[05:16] <Keybuk> daf: ewww, but effective :p
[05:16] <daf> yep :)
[05:17] <daf> 'course, best not to try to mirror to it in the meantime
[05:19] <daf> ddaa: https://launchpad.ubuntu.com/products/pyflakes/+series/0.1
[05:20] <ddaa> daf: as I understand it, you need to create a main series, not a 0.1 series, since (1) the project releases from trunk (2) there are no overlapping releases of different releases
[05:20] <ddaa> Keybuk: correct?
[05:20] <ddaa> daf: I can fix it. Do not create another series.
[05:20] <ddaa> That will just cause clutter.
[05:20] <daf> ok
[05:20] <sabdfl> a better workaround is to try to mirror a fix before pqm merges from your branch :-)
[05:21] <ddaa> daf: bah... Keybuk's away...
[05:21] <daf> he was here a minute ago
[05:22] <ddaa> daf: I'm very confused by all this series crud that landed on our head last week. I'll need to wait for him to get here before proceeding.
[05:22] <daf> sure
[05:23] <ddaa> Though... what concerns me most, is that if I cannot understand how we should input things, how can we expect our users to do it right?
[05:23] <bradb> hear, hear
[05:28] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  add __all__ to browser/product and project (patch-2005)
[05:28] <ddaa> ho, dilys is here now..
[05:28] <daf> ddaa: this channel is now the primary Launchpad channel
[05:29] <daf> morgs: around?
[05:37] <ddaa> do we have some bulgarian-speaking staff/community around?
[05:40] <daf> jamesh: yeah, looks like the bug.py changes are irrelevant now
[05:40] <daf> jamesh: I've just committed a bunch more import cleanups to that branch
[05:46] <sabdfl> jamesh: this is an excellent review, thank you very much!
[05:51] <SteveA> sabdfl: yes, steve.alexander@canonical.com--z8 the canonical work archive for my workstation.  The workstation's name is "zeus8".
[05:51] <SteveA> Keybuk: I'll be doing a lot of reviews myself this week.
[05:52] <kiko> bradb, can you cook for me a query which tells me how many bugs have more than one bugtask open (so I can run that in production)?
[05:52] <kiko> s/open/filed/
[05:52] <bradb> kiko: sure, one sec
[05:52] <kiko> thanks
[05:55] <bradb> kiko-fud: select count(*) from bug where id in (select distinct bug from bugtask group by bug having count(*) > 1); appears to do the right thing
[06:00] <bradb> (p.s. by "open" i assumed that you meant a task with any status, but if you meant for it to be filtered further, e.g. New/Accepted/PendingUpload, etc. I can adjust it)
[06:02] <mpt> kiko, such a query won't mean much until we have multiple distributions actively using LP
[06:03] <morgs> daf: I'm back...
[06:04] <daf> morgs: hi!
[06:04] <daf> morgs: do you know anything about browser/sshkey.py?
[06:04] <morgs> daf: no...
[06:04] <morgs> sounds like a foaf thing?
[06:04] <daf> yeah, could be
[06:05] <daf> salgado-lunch: do you know anything about it?
[06:15] <SteveA> morgs: I reviewed your bug 1205 branch.  The branch needs some more work.
[06:19] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Made DatabaseImportFascist output clearer. (patch-2006: steve.alexander@canonical.com)
[06:20] <morgs> SteveA: thx
[06:33] <Keybuk> ddaa: back properly now, what's up?
[06:34] <ddaa> pyflakes releases from trunk and does not have overlapping releases on two series
[06:34] <ddaa> but daf did the obvious thing and created a 0.1 series
[06:35] <Keybuk> oik
[06:35] <Keybuk> uh, ok
[06:35] <Keybuk> I'd either move the CVS details from the artificial "main" series to 0.1
[06:35] <ddaa> Keybuk: should I: 1. tell daf don't do that 2. put the svn details for trunk in 0.1 3. create main and put the svn detail there (so we end up with a main without ftp and a branch w/o rcs 4. rename 0.1 to main
[06:35] <Keybuk> or do the opposite, remove the "0.1" series and move the details to the "main" series
[06:35] <Keybuk> the effect of both would be the same
[06:35] <ddaa> Okay...
[06:36] <Keybuk> and in the long game, it doesn't really matter, because when a person cares about pyflakes comes along, they can model it how they like
[06:36] <Keybuk> and both are equally valid points of view
[06:36] <ddaa> And break importd.
[06:37] <ddaa> Importd has a 50% chance of breaking when the job name changes, and it's currently [project-] product-series
[06:37] <ddaa> because it's running on two slaves and we have not even yet specced job migration.
[06:39] <Keybuk> we'll cross that bridge when we come to it
[06:39] <ddaa> Keybuk: I also have met a couple of interestingly evil cases wrt to release series.
[06:40] <ddaa> I need your advice on handling those.
[06:40] <Keybuk> sure
[06:42] <ddaa> dia, it appears to be a simple project, but they cvs repo is full of branches that look like that would be release branches (DIA_0_94_RELEASE, DIA_0_94_PRE2 DIA_0_94_DEVEL, DIA_0_94_DEV), but actually the ChangeLog for the 0_94 tag (actual release) appears to be on the MAIN branch.
[06:43] <Keybuk> heh, probably post-fact branching
[06:43] <ddaa> Probably SNAFU in my opinion.
[06:43] <Keybuk> given we can't even import CVS branches yet, I'd take the cotton wool tactic
[06:43] <SteveA> BjornT: approved your ordering fix.  one minor comment.
[06:44] <Keybuk> (putting some in your ears and going "LA LA LA" until the problem goes away)
[06:44] <ddaa> So I got confused and filled the ftp details on a 0.94 release, that actually looks like it has no legitimate existence (as it was released from MAIN).
[06:45] <BjornT> SteveA: thanks
[06:45] <ddaa> So, I'm not clear on whether I should move the ftp details to MAIN (which appears to be the closest thing to the tarball) and what should be the match since various pre-release tarballs for 0.94 (and there are many of them) are more closely related to various branches...
[06:45] <Keybuk> yeah, do that
[06:45] <ddaa> and if I move the ftp details to main, what should I do with the dummy 0.94 branch that remains?
[06:46] <ddaa> "and what should be the glob since various pre-release..."
[06:46] <Keybuk> nuke it
[06:46] <ddaa> given that the only way to delete series so far is to use pqsl
[06:47] <ddaa> so it does not look like it's very much something that's meant to be done
[06:47] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  add __all__ to browser/product and project (patch-2007: morgan.collett@canonical.com)
[06:47] <Keybuk> rename it to "1.0" and comment that it's "in potentia" :p
[06:48] <ddaa> Keybuk: so, your call is "just put ftp details in main with an inclusive glob, let the changesets to the pre-releases be whatever they want to be, and nuke the 0.94 series"...
[06:48] <Keybuk> yup
[06:48] <ddaa> Okay. Makes some sense.
[06:48] <Keybuk> in the case where the glob only matches one logical set of tarballs
[06:49] <ddaa> Define logical.
[06:49] <Keybuk> well, a set of tarballs that go together in the right order
[06:50] <Keybuk> ie *.tar.gz probably isn't logical, but blah-0.94.*.tar.gz probably is
[06:52] <ddaa> well... I only put globs of the form "blah-*.tar.gz" in main
[06:52] <ddaa> a glob like "blah-0.94*.tar.gz" (note that I omit the dot after 94 to match things like 0.94-pre2) would belong in a 0.94 series in my understanding.
[06:52] <ddaa> (also to match things like 0.94.tar.gz and 0.94.1.tar.gz)
[06:52] <ddaa> Keybuk: do we agree?
[06:52] <Keybuk> I'd be careful with that
[06:53] <Keybuk> because 0.94-pre2 probably sorts *after* 0.94 :p
[06:53] <ddaa> Oh, yes, I forgot to ask you your definition of "order"...
[06:53] <Keybuk> currently we use whatever order the FTP/HTTP site does
[06:53] <Keybuk> because that's usually asciibetical anyway, except that some places actually do work hard to present it in the right order
[06:54] <Keybuk> in other words, there's no sort() in dyson
[06:54] <ddaa> HTTP?
[06:54] <ddaa> I though it were doing only ftp.
[06:54] <Keybuk> dyson can traverse HTTP indexes
[06:54] <ddaa> What kind of indexes?
[06:54] <Keybuk> (but not yet usefully traverse "download.html" type pages)
[06:54] <ddaa> I mean, how does it know what it can traverse?
[06:55] <Keybuk> releaseroot=http://bazaar.canonical.com/releases/src/
[06:55] <Keybuk> releaseglob=bazaar_*.tar.gz
[06:55] <Keybuk> would work
[06:55] <ddaa> okay, how does it know what it _cannot_ traverse?
[06:55] <Keybuk> it will traverse down to any lower URL which ends with a /
[06:56] <Keybuk> so, you could give it http://bazaar.canonical.com/releases/
[06:56] <Keybuk> and it'd see that debs/ rpms/ and src/ were all "directories" under that URL
[06:56] <Keybuk> and traverse them
[06:56] <Keybuk> in src/ it would only see files (nothing ends in "/") so would only download those that matched the glob
[06:57] <ddaa> okay... makes sense
[06:58] <Keybuk> it doesn't yet work with html pages and stuff, simply because we want to try and avoid downloading the entire web ;)
[06:58] <daf> aww, why not?
[06:58] <Keybuk> (by html, I mean download.html or pretty pages; and not the html-style indexes)
[06:59] <ddaa> actually, dia appears to be in the right order
[06:59] <ddaa> but how should we handle cases like: ftp://ftp.gnu.org/gnu/automake/
[07:00] <Keybuk> automake is one of those cases where there should be _no_ MAIN series
[07:00] <Keybuk> there's a 1.4, 1.6, 1.7, 1.8, 1.9, etc. series
[07:00] <ddaa> Yes, there's a main series for the cvs MAIN
[07:00] <Keybuk> there really, really shouldn't be :)
[07:00] <Keybuk> automake cvs MAIN isn't that interesting
[07:00] <Keybuk> just like libtool MAIN isn't interesting
[07:00] <Keybuk> ... well, in the sense that nothing is released off it
[07:01] <ddaa> is it interesting in providing a root for imports of other branches?
[07:01] <ddaa> http://arch.ubuntu.com/automake@bazaar.ubuntu.com/
[07:01] <sabdfl> Keybuk: still interesting for people to branch off
[07:01] <sabdfl> most coders will want the trunk
[07:01] <Keybuk> sabdfl: yes, just mean interesting for a discussion about ftp releases
[07:01] <Keybuk> actually, iirc, automake merge _to_ head and not from it
[07:01] <ddaa> right, so main is still interesting, it just must not have ftp details.
[07:01] <Keybuk> but I may be wrong, I haven't really done much with it for a year or so
[07:02] <Keybuk> right
[07:02] <ddaa> But my question was about ordering of tarballs.
[07:03] <Keybuk> that particular example would need some massaging ;)
[07:03] <ddaa> How that that affect data input on launchpad?
[07:04] <Keybuk> input as if that worked
[07:04] <ddaa> I like this answer.
[07:05] <ddaa> One last evil case and I'm done for today.
[07:05] <Keybuk> (if you want the real answer, that's what the "version style" field is all about -- but there's no point trying to define the possible values for that until we've actually found out what they are)
[07:06] <Keybuk> there are as many methods of release management as there are releases ;)
[07:09] <ddaa> Keybuk: currently breezy packages cyrus-imapd-2.1, eventually it will package 2.2
[07:09] <ddaa> The cvs server does _not_ have release branches.
[07:09] <ddaa> however, if you examine the ftp repo
[07:09] <ddaa> ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/
[07:09] <Keybuk> ok, so they have a single-minded development model
[07:10] <ddaa> you see that there are overlapping 2.1 and 2.2 releases that require different series to be imported correctly.
[07:10] <daf> ddaa: what state is pyflakes in now?
[07:10] <Keybuk> how do they manage this overlapping effect without releasing 2.1 from a branch?
[07:11] <ddaa> daf: I will rename your 0.1 series to main. Please fill in the svn (in "edit source") and ftp (in "edit series details") details for the series.
[07:11] <ddaa> Keybuk: I do not know. They probably do something stupid like tarball-based version-tracking...
[07:11] <Keybuk> cute
[07:12] <Keybuk> probably the 2.1 changes aren't in CVS anywhere
[07:12] <ddaa> yeah, my guess too
[07:12] <Keybuk> you'd need a 2.1 series for them
[07:12] <ddaa> so, a main w/o ftp details, and 2.1 series w/o cvs details?
[07:12] <Keybuk> yeah, seems reasonable to me
[07:13] <ddaa> that goes in too-hard? or completed? I understand that such incomplete series will cause a report from launchpad.
[07:13] <Keybuk> why would it be incomplete?
[07:13] <Keybuk> if it had FTP details, it's a "useful" series
[07:13] <ddaa> because one series would have cvs (main) and the other would have ftp (2.1).
[07:13] <Keybuk> that's an accurate model of upstream though, from what you tell me
[07:14] <ddaa> Sure.
[07:14] <ddaa> The question relates to our own process of managing import data.
[07:14] <Keybuk> do you read this "report from launchpad" ?
[07:14] <ddaa> I do not even know where it is. lifeless referred to it previously, so I assume it exists or will exist.
[07:15] <ddaa> okay.
[07:15] <ddaa> bonus question
[07:16] <ddaa> How can we expect our users to understand this model and follow these guidelines. That's a complex and non-obvious set of rules.
[07:16] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: fix ordering problem when searching for bugtasks. [r=stevea]  (patch-2008: bjorn.tillenius@canonical.com)
[07:16] <Keybuk> ah, but the users will be the upstream
[07:16] <Keybuk> or, at least, someone in a distro who works closely with upstream
[07:16] <Keybuk> so they'll understand the model they use
[07:16] <Keybuk> and will input the data in their own way
[07:17] <ddaa> that means they will likely know what they do. Not that it will be input correctly for our model.
[07:17] <Keybuk> our problem isn't actually inputting the data, it's figuring out how to model it
[07:17] <Keybuk> we don't have a model
[07:17] <Keybuk> we're not forcing them to put the details in any particular way
[07:17] <Keybuk> launchpad in fact lets them put them in how they want
[07:17] <Keybuk> which is good
[07:17] <ddaa> well, so pyflakes could just have a main branch with svn and a release branch with 0.1, that would not hurt, would it?
[07:18] <Keybuk> exactly
[07:18] <Keybuk> it's entirely harmless
[07:18] <ddaa> mostly? ;)
[07:18] <Keybuk> the only reason I'd say _we_ shouldn't do that is that it's more typing ;)
[07:18] <Keybuk> and more for the upstream to undo later
[07:19] <ddaa> I can tell you that we are entirely willing to do it that way if it means less fucking around to what to input.
[07:19] <ddaa> * to know what to input
[07:20] <Keybuk> we need to just keep the lower branches looking nice
[07:20] <Keybuk> so when upstream come along later, they can start some serious pruning and gardening and get the topiary they were looking for
[07:21] <ddaa> So, the only important constraints is that the ftp glob of a series must match only tarballs that form a logical sequence, and must be in a productseries whose name is vaguely relevent. Aside from that, the rcs details can be entirely shuffled around?
[07:21] <Keybuk> yup
[07:21] <ddaa> like have MAIN in 0.1 and an hypothetical release_0_1 branch in main?
[07:22] <ddaa> (not meaning to do that, just testing for edge cases)
[07:22] <Keybuk> I think 75% of upstreams will probably just have a single branch of development
[07:22] <Keybuk> they might keep renaming it
[07:22] <Keybuk> or they might leave it at MAIN
[07:23] <Keybuk> those 25% that don't, are also the kind of control freaks who'll gleefully create lots of information in launchpad
[07:23] <Keybuk> all we need do is put enough data in to make it immediately useful
[07:23] <Keybuk> and then our users will do the rest for us
[07:23] <ddaa> I know some control freaks who would hate to create information in anything they have not invented themselves :)
[07:24] <Keybuk> then the Ubuntu or Debian guys would fill it in, etc.
[07:24] <ddaa> btw, you did not answer my question
[07:25] <Keybuk> sorry, what was your question?
[07:25] <ddaa> ddaa: like have MAIN in 0.1 and an hypothetical release_0_1 branch in main?
[07:25] <daf> ddaa: ok, I've put the SVN details in
[07:25] <Keybuk> I don't understand the question?
[07:25] <ddaa> Aside from that, the rcs details can be entirely shuffled around? like have MAIN in 0.1 and an hypothetical release_0_1 branch in main?
[07:26] <daf> ddaa: there is no FTP as far as I know
[07:27] <Keybuk> sure
[07:27] <ddaa> daf: is there a download page, autogenerated HTTP index pages are good.
[07:28] <ddaa> daf: my understanding of ftp details just increased by an order of magnitude since I asked you for ftp details.
[07:28] <daf> ddaa: I don't think so, no
[07:28] <daf> ddaa: only a link to the latest release on the homepage
[07:29] <ddaa> daf: that is what you are looking for: http://divmod.org/static/projects/pyflakes/
[07:29] <daf> aha
[07:29] <daf> I'm sure it 404'd me when I tried that before
[07:37] <ddaa> daf: autotest import running
[07:37] <daf> cool
[07:37] <ddaa> bah...
[07:38] <ddaa> too many links... I'm going to play janitor for a bit
[07:38] <ddaa> I really need to find the time to fix that bug.
[07:38] <ddaa> lifeless seems to think that rm'ing tmpdirs when you create them by the thousand is some sort of luxury...
[07:40] <Keybuk> descent importd-audit% baz commit -s "add some info for ddaa"
[07:40] <Keybuk> No commitable locations for importd-audit@canonical.com are registered
[07:40] <Keybuk> importd-audit@canonical.com/audit--0: not a valid archive name or url.
[07:40] <Keybuk> ... 
[07:40] <Keybuk> any ideas?
[07:40] <ddaa> unregistered archive
[07:40] <Keybuk> descent importd-audit% baz whereis-archive importd-audit@canonical.com
[07:40] <Keybuk> sftp://chinstrap.ubuntu.com/home/warthogs/archives/importd-audit@canonical.com
[07:40] <Keybuk> nope
[07:41] <ddaa> ha...
[07:41] <ddaa> "No commitable locations for importd-audit@canonical.com are registered"
[07:41] <daf> what does "baz tree-id" say?
[07:41] <kiko-fud> bradb-bbl, thanks
[07:41] <Keybuk> descent importd-audit% baz tree-id
[07:41] <Keybuk> importd-audit@canonical.com/audit--0--patch-29
[07:41] <daf> ewww
[07:41] <ddaa> Keybuk: you need to remove the read-only "hint" in the ~/.arch-parms/archive/importd-audit@canonical.com file
[07:42] <Keybuk> cat: /home/scott/.arch-parms/archive/importd-audit@canonical.com: No such file or directory
[07:42] <ddaa> bah... /archives/
[07:42] <ddaa> don't be such a pedant :)
[07:42] <kiko-fud> lol
[07:42] <Keybuk> ah, "archives"
[07:42] <Keybuk> that wasn't deliberate pedantry, I haven't had time to learn the new locations stuff yet
[07:42] <daf> looks like there's a category/branch missing from the tree's version
[07:43] <Keybuk> ok, that seemed to work
[07:43] <Keybuk> thanks
[07:43] <ddaa> daf: the branch-id component of the name has always been optional
[07:43] <daf> or the c-b-v restrictions got changed and nobody told me
[07:43] <daf> oh
[07:43] <daf> huh
[07:43] <daf> how confusing
[07:43] <daf> how does it know which branch to commit to?
[07:43] <ddaa> but it's discouraged to omit it, because user tools tend not to support that well
[07:44] <ddaa> because it only commits revisions
[07:44] <ddaa> however, the ambiguity is annoying is some cases, e.g. archive-mirror limiting
[07:44] <daf> nyurg
[07:45] <ddaa> some incidental and peripheral evil of the namespace
[07:45] <ddaa> a bit like version-0 and versionfix...
[07:45] <ddaa> things that looked like good ideas at the time
[07:45] <salgado> daf, I think all code from browser/sshkey.py was moved into browser/person.py and whoever removed the last bits forgot to remove the file
[07:47] <daf> salgado: ok, shall I nuke it then?
[07:47] <salgado> daf, please
[07:48] <kiko> nuke it and don't care bout regrets
[08:16] <kiko> salgado, what about bug 1220?
[08:18] <kiko> debonzi, and after you're finished, https://launchpad.ubuntu.com/malone/bugs/1212
[08:20] <salgado> kiko, my best guess is that the wiki is not using a person's preferred email
[08:20] <kiko> sounds like that to me as well
[08:21] <kiko> daf, I see pt, pt_BR and pt_PT listed at https://launchpad.ubuntu.com/products/gnomebaker/unknown/+pots/gnomebaker
[08:21] <kiko> daf, is that because you haven't landed that fix in production yet?
[08:22] <daf> no
[08:23] <daf> it's because PO files for those language codes exist
[08:23] <daf> we don't have the code to merge them yet
[08:23] <kiko> how do we fix that?
[08:23] <daf> this is similar to the people merge problem
[08:23] <kiko> we should do that asap to avoid translations being wasted
[08:23] <kiko> daf, even hiding them is better than leaving them as-is, you know
[08:24] <daf> well, we don't want to lose data for our users
[08:24] <daf> maybe hiding them would be workable
[08:24] <daf> I need to sit down and think what the PO file merge algorithm would look like
[08:24] <kiko> it's not data which is very useful though
[08:24] <kiko> daf, how many of these do we have?
[08:25] <kiko> I don't think pomerge is as important as peoplemerge, which is why I'm saying that hiding may be the better solution
[08:26] <daf> I don't know how many we have
[08:26] <daf> I'll check
[08:32] <daf> 546
[08:35] <kiko> daf, how many of them have significant numbers of translations?
[08:35] <kiko> :-(
[08:38] <daf> hmm, not sure how to count that
[08:51] <kiko> me neither
[08:54] <kiko> Keybuk, ping?
[09:05] <dilys> Merge to thelove@canonical.com/dists--bazaar--1.5: new build (patch-29)
[09:06] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.5: Error message formatting (patch-22: Matthieu.Moy@imag.fr)
[09:10] <kiko> SteveA, are you onto bug 1193 too?
[09:12] <bradb> SteveA: i wanted to bring the DocWrapper from: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/358228 in LP. 1. can i? 2. if so, what legal-fu needs to be done? 3. if 1 and 2, does it belong in helpers.py?
[09:35] <dilys> Merge to thelove@canonical.com/dists--bazaar--1.5: new build (patch-30)
[09:36] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.5: Fixed a "panic" in lock-revision -b (patch-23: Matthieu.Moy@imag.fr)
[09:37] <Keybuk> kiko: sup?
[09:38] <kiko> Keybuk, hctapi is using a dead class
[09:38] <Keybuk> which one?
[09:38] <kiko> SourcePackageReleaseInDistroRelease
[09:38] <kiko> can you nuke all that cruft rs=kiko
[09:38] <Keybuk> why is that dead?
[09:38] <Keybuk> given it's declared in that module
[09:38] <kiko> hmmm
[09:38] <kiko> am I totally confused?
[09:38] <Keybuk> it would seem so
[09:39] <kiko> ah
[09:39] <Keybuk> it's defined at the top of hctapi, basically just as a "typeful" way of holding both a SourcePackageRelease and DistroRelease at once
[09:39] <kiko> I see
[09:39] <kiko> I see
[09:40] <kiko> okay
[09:40] <kiko> Keybuk, then really you need to fix up _pathlookup.py to use it
[09:40] <Keybuk> what's _pathlookup.py ?
[09:40] <kiko> something BjornT has hacked on recently
[09:41] <Keybuk> me neither
[09:41] <Keybuk> nothing to do with me
[09:41] <Keybuk> looks like BjornT took my code and used it for something in malone
[09:42] <Keybuk> and I can't see how that'd work either, it's missing major chunks
[09:43] <Keybuk> (like, for instance, the definition of that class)
[09:43] <kiko> no _pathlookup.py is not malone-specific
[09:44] <Keybuk> what else uses it?
[09:44] <kiko> I see, I see
[09:44] <kiko> I didn't know anything about it.
[09:45] <Keybuk> I knew Bjorn wanted to use similar stuff to the HCT URL scheme for Malone's e-mail interface
[09:45] <Keybuk> but I didn't realise he'd already stolen the code and merged it
[09:45] <Keybuk> and the reviewer for that needs shooting, because it just won't work <g>
[09:46] <Keybuk> if we want a system-wide "path" scheme for referring to an object in the database, it's really something we should spec
[09:46] <Keybuk> rather than just stick in ad-hoc
[09:46] <Keybuk> as otherwise things might be missed
[09:47] <Keybuk> like in HCT it's no good just having a SourcePackageRelease, we need to know the reference DistroRelease because otherwise we can't lookup what ProductSeries it's associated with (keyed on SourcePackageName & DistroRelease)
[09:47] <Keybuk> (which is the reason that little class exists at the top)
[09:50] <bradb> kiko: did you see those DocWrapper questions i asked SteveA? in essence, i'm wondering if anyone will mind if i bring in a class from a Python cookbook recipe, which solves the problem of wrapping multiple paragraphs of text (textwrap.wrap and .fill expect their arg to be a single paragraph, and producably suitably weird return values if you thought you could hand it a multi-paragraph string to be wrapped.)
[09:51] <kiko> Keybuk, I see your point. agh.
[09:52] <kiko> bradb, what's it licensed with?
[09:52] <kiko> Keybuk, I'll email BjornT :-(
[09:52] <bradb> kiko: no idea. http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/358228 doesn't give me any obvious indication.
[09:53] <bradb> though http://aspn.activestate.com/ASPN/Cookbook/ says "We invite you to contribute code, comments, and ratings for recipes in these Cookbooks. All contributions are reviewed by our Cookbook editors, ensuring a consistent level of quality. The recipes are freely available for review and use."
[09:53] <bradb> so maybe it's enough to give a URL to the recipe i stole?
[09:55] <kiko> should be
[09:55] <kiko> you need to point this out to your reviewer, AAR
[09:56] <bradb> yes, i'll note it
[09:57] <Keybuk> that being said, I'm all for a common path scheme to refer to any given object in the database and path scheme to get from one place to another; with a common library to do just that
[09:57] <Keybuk> but it's probably so far down my interest and todo list, that it's compost ;)
[10:01] <ddaa> Keybuk: re dpkg import
[10:01] <Keybuk> yes? hello
[10:01] <bradb> kiko: can bugs that expose implementation details be left non-private from now on then?
[10:02] <ddaa> The cleanup is currently blocked on stub requesting a script to clean the db crud related to the dpkg@zubuntu.com
[10:02] <bradb> (e.g. that refer to class names, filenames, etc.)
[10:02] <ddaa> ... dpkg@bazaar.ubuntu.com archive.
[10:02] <Keybuk> right
[10:02] <ddaa> That is branch, archnamespace, revisions, etc.
[10:04] <ddaa> I wanted to let you know. I'm probably not going to work on that specific issue anytime soon as there are more pressing things requesting my attentions (new imports, pending merges, svn import fixes).
[10:05] <Keybuk> sure
[10:07] <ddaa> daf: pyflakes now on http://arch.ubuntu.com/pyflakes@bazaar.ubuntu.com
[10:07] <dilys> New Malone bug 1229 filed on product The Launchpad by Brad Bollenbach: ISourcePackageSet was being used in database/distrorelease.py but not imported
[10:07] <dilys> https://launchpad.ubuntu.com/malone/bugs/1229
[10:09] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=kiko]  improvements to PO export mail suggested by Kiko (patch-2009: daf@canonical.com)
[10:10] <kiko> bradb, no clue, but that bug was reported by daf to the ML last week
[10:10] <bradb> ah, no wonder i couldn't find it ;)
[10:13] <SteveA> so
[10:13] <ddaa> Keybuk: what kind of glob should I used to match bpalogin-2.0.2.tar.gz but _not_ bpalogin-2.0-linux.tar.gz (that is a binary distribution)?
[10:13] <ddaa> The corresponding source tarball is bpalogin-2.0-unix-src.tar.gz
[10:13] <Keybuk> bpalogin-2.0.*.tar.gz ? :p
[10:13] <ddaa> bzzzt
[10:14] <ddaa> there's no 2.0.1 tarball there :)
[10:14] <SteveA> kiko: 1193 should be fixed when i merge the latest menu-fu
[10:14] <Keybuk> *shrug*
[10:14] <Keybuk> pick one that seems sensible to you
[10:14] <SteveA> bradb: talk to me
[10:14] <Keybuk> even it means making multiple series
[10:15] <Keybuk> or just pick what seems to be their current scheme
[10:15] <SteveA> BjornT: thanks for the review.  i'll go and merge.
[10:15] <bradb> SteveA: there's a problem with textwrap.wrap and .fill: they assume there argument to be a single paragraph.
[10:15] <ddaa> They have no "current" naming scheme, the last release dates back to 2003...
[10:15] <Keybuk> sweet
[10:15] <ddaa> and that's the 2.0.2 one
[10:15] <bradb> SteveA: so, if you pass a multi-paragraph string, and expect it to Do The Right Thing, you'll be surprised in unpleasant ways.
[10:15] <Keybuk> my suggestion seems fine
[10:15] <ddaa> I think I'm just going to make series for 2.0.2...
[10:15] <SteveA> bradb: is this for use in emails?
[10:16] <Keybuk> 2.0.2 is the current one
[10:16] <Keybuk> so we don't really care about anything before that
[10:16] <ddaa> the naming scheme so far appears to be totally inconsistent
[10:16] <bradb> SteveA: that's one use case, yeah. i don't know offhand if there might be others.
[10:16] <Keybuk> bpalogin-2.0.*.tar.gz  would work
[10:16] <Keybuk> and catch .3 if it ever appears
[10:16] <SteveA> bradb: let's keep the realm of imagination out of the discussion for now ;-)
[10:16] <ddaa> Keybuk: okay, sounds reasonable.
[10:16] <bradb> SteveA: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/358228 is a recipe to fix that problem. it introduces a DocWrapper class.
[10:17] <bradb> it's a small class that Just Works
[10:17] <Keybuk> if a maintainer or upstream care about history, they can import that later
[10:17] <bradb> SteveA: so, can we use this DocWrapper class?
[10:17] <SteveA> bradb: i'll take a look
[10:17] <jordi> hmm. where's carlos
[10:17] <ddaa> Keybuk: I'm pretty sure that nobody loves this thing. It's just a tool to work around Telstra stupidity.
[10:18] <Keybuk> indeed, it strikes me as one that nobody's ever likely to care anything about
[10:18] <SteveA> jordi: i haven't seen carlos today
[10:18] <ddaa> Keybuk: but there's likely to be a new release soon, as there will be a telstra network upgrade that may break the tool...
[10:18] <Keybuk> urgh, it's one of Anibal's packages ... RUN AWAY!
[10:19] <ddaa> My mission is to bodly go in the wildest, most crufty corner of the tarball realm.
[10:19] <ddaa> So running away is not an option.
[10:19] <Keybuk> strange
[10:19] <SteveA> bradb: the code is under the python licence.
[10:20] <Keybuk> I always thought you looked somewhat like I imagined Rincewind to look like
[10:20] <Keybuk> complete with the half-smoked rollup
[10:20] <SteveA> bradb: so, yes, we can use it.  i need you to do some special things though.  are you ready for it?
[10:20] <bradb> SteveA: ready
[10:21] <jordi> SteveA: ok
[10:21] <jordi> SteveA: mdz has a pic to show you, taken yesterday at a restaurant :)
[10:21] <SteveA> 1. it needs to go in its own module, because it isn't "owned" by canonical.
[10:21] <ddaa> Keybuk: I guess that's not a compliment... that does not appear to be a most heroic character http://www.ie.lspace.org/books/whos-who/rincewind.html
[10:21] <SteveA> jordi: good lord, not more eggs!
[10:21] <Keybuk> not his character, just the general look
[10:21] <Keybuk> he runs away a lot
[10:22] <bradb> SteveA: roger that
[10:22] <SteveA> bradb: stub has some ideas about where such things should go, but I suggest we stick it in lib/contrib, and (eventually) move BeautifulSoup there as well, as it doesn't seem to have a decent place to live.
[10:23] <bradb> SteveA: e.g. lib/contrib/docwrapper.py?
[10:23] <jordi> SteveA: lol
[10:23] <SteveA> 2. its module needs to say where it came from, including that it is under the python license (i think python uses US spelling), and crediting the author.
[10:24] <jordi> SteveA: dude the EGG MAN was on the menu. WITH A PICTURE
[10:24] <SteveA> 3. the code looks pretty simple, but it depends on a complex api.  i'd like you to add a doctest to it.
[10:24] <SteveA> jordi: awesome.  did they serve walrus too?
[10:25] <jordi> SteveA: I'm positive about it, but we asked for eel instead.
[10:25] <SteveA> jordi, mdz and a walrus walk into a restaurant.
[10:26] <SteveA> jordi and mdz order an egg each.  the walrus orders three.
[10:26] <SteveA> the waiter tells them all to get out.
[10:26] <SteveA> "sorry, we don't server walrus!"
[10:26] <SteveA> bradb: what do you think?
[10:26] <kiko> I think you have "server" imprinted in your brain
[10:26] <SteveA> bradb: not about the lame joke -- about the plan for using the code?
[10:27] <SteveA> what was it in south africa?  waitron?
[10:27] <jordi> SteveA: lol
[10:27] <bradb> SteveA: sounds reasonable. btw, how did you know it was under the python license?
[10:27] <kiko> waitron
[10:27] <kiko> right
[10:27] <SteveA> bradb: you ask all those awkward questions ;-0
[10:27] <bradb> i ask the questions that others are AFRAID TO ASK
[10:27] <bradb> er
[10:27] <SteveA> bradb: http://aspn.activestate.com/ASPN/Cookbook/Python
[10:27] <SteveA> look at the foot of the page
[10:27] <bradb> ah
[10:28] <SteveA>  "Except where otherwise noted, recipes in the Python Cookbook are published under the Python license ."
[10:28] <kiko> does monkeypatching imply a derivative work, I wonder
[10:28] <SteveA> kiko: yes, it does
[10:29] <SteveA> why?
[10:29] <ddaa> SteveA: Not clear, that can be seen as a feature of the client code.
[10:30] <ddaa> as long as third party is not allowed to be client of the monkey-patched code.
[10:30] <SteveA> ddaa: that would be for you and an army of lawyers to decide.  me, i keep it simple.  if it looks derived, then it probably is.
[10:30] <ddaa> lib-patching-lib, bad. App-patching-lib might be okay.
[10:31] <ddaa> SteveA: good rule of thumb. "If you feel the need to ask if it's dead, then it probably stinks".
[10:31] <SteveA> duncan booth was giving that as a rule of thumb for sending wine back in a restaurant
[10:32] <SteveA> if you think it possibly is bad, then is it
[10:32] <ddaa> sounds like he's an annoying patron :)
[10:32] <SteveA> he's trying to train himself out of the british habit of accepting any old crap in a restaurant
[10:33] <SteveA> you are fortunate to be french, and have standards in these things
[10:33] <ddaa> I have to admit, wine really have to taste cork for me to return it.
[10:33] <ddaa> I should probably be more picky.
[10:34] <SteveA> daf: on the schooltool list:
[10:34] <SteveA> Hi everyone, i need to translate schooltool to catalan language before september (i want install it in my high school), but the rosetta tool don't work !! when we can translate with rosetta? or what if i translate directly from the po files?
[10:36] <ddaa> failure to enforce own rule :)
[10:36] <dilys> Merge to thelove@canonical.com/dists--bazaar--1.5: new build (patch-31)
[10:37] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.5: Better formatting for output messages (patch-24: Matthieu.Moy@imag.fr)
[10:51] <daf> ddaa: awesome!
[10:51] <daf> SteveA: can we find out what problems they're having?
[10:52] <daf> kiko: right, we have pyflakes in arch
[10:53] <kiko> daf, next step, convince SteveA to get it into our config :-)
[10:53] <daf> yup
[10:53] <SteveA> daf: i forward you the message
[10:54] <daf> thanks
[10:54] <SteveA> daf: send me an email about pyflakes telling me everything i need to know about what you've looked at so far.  i'll queue it up on my todo list.
[10:54] <daf> SteveA: ok
[10:57] <SteveA> bradb: note that some of the incidental code from that cookbook example sux0rs
[10:57] <SteveA>        try:
[10:57] <SteveA>             FILE = open(args[0] , 'rU')
[10:57] <SteveA>             text = FILE.read()
[10:57] <SteveA>         finally:
[10:57] <SteveA>             FILE.close()
[10:57] <SteveA> so, if open() raises, then the finally will error out too
[10:57] <SteveA> all the more reason to have a good test :-)
[10:58] <bradb> yeah, i wrote textformatting.txt just now
[10:58] <SteveA> bradb: unless someone wants to review it for you tonight, stick it in my review queue and i'll look at it tomorrow
[10:59] <bradb> this is stuff i'm doing in response to salgado's review of my FormattingBugNotifications branch.
[10:59] <bradb> presumably he'll be the one to review this, or would you prefer to review it?
[11:00] <SteveA> we can get the contrib stuff in separately, if you like
[11:00] <SteveA> if not, i'm fine with salgado doing it
[11:02] <bradb> ok, since i've already been working on it on the FBN branch, and the FBN branch depends on it, i think i'll get salgado to have a look at it when i'm done with the other changes
[11:03] <SteveA> ok
[11:06] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: r=BjornT Latest menus code.  Fixes various bugs, and introduces absolute url targets. (patch-2010: steve.alexander@canonical.com)
[11:07] <SteveA> yay!
[11:07] <daf> hurrah!
[11:10] <kiko> daf, did you fix bug 1146 with your sourcepackage landing?
[11:10] <daf> ooh
[11:10] <daf> yes, I did
[11:11] <kiko> cool
[11:11] <kiko> close it!
[11:11] <bradb> salgado: around?
[11:14] <salgado> bradb, yep
[11:17] <bradb> salgado: i was wondering: i'm thinking removing the ILaunchBag usage from BugMessageFactory is going to require a bit of thought on how to be able to access the bug and owner (this is factory code automagically called by Z3's form machinery, so it's not as simple as me changing a callsite, because there isn't one). is it possible for me to skip that task, but make as my next task a little branch to remove *all* Malone usage of the I
[11:18] <kiko> daf, does bug 1155 still apply?
[11:18] <kiko> never saw any traction there..
[11:18] <salgado> bradb, can't you simply move BugMessageFactory to browser code, and make it call IBugMessageSet.new()?
[11:19] <daf> kiko: dunno
[11:19] <daf> kiko: Carlos is master of stats bugs, and rewrote the importer recently, so he may be more up to speed on it than I am
[11:20] <bradb> salgado: er, yeah, i guess i could create a view for this class to "create" a callsite for it an fix it in that way.
[11:20] <bradb> not a big deal. /me fixes it
[11:21] <salgado> bradb, I thought you wouldn't even need a view. can't you use factory="canonical.launchpad.browser.BugMessageFactory"?
[11:23] <bradb> salgado: if i put this *Factory under browser/ it would be the first instance that we'd have every done that in LP, AFAICS
[11:23] <bradb> i think our standard is that the content creation stuff lives under database/, but please correct me if i'm wrong
[11:24] <salgado> but the creation will not be in the browser code. it will still be in database code
[11:25] <bradb> i got the impression that the Right Way to fix this was: 1. replace the factory with a method on IBugMessageSet, 2. create a BugMessageAddView. 3. (at a guess...) override its .create method to call that set explicitly, with the user and the bug gotten from the ILaunchBag
[11:25] <salgado> I think it's weird having a factory pointing to browser code, but I can't see other way of doing that (unless you create a view class)
[11:26] <bradb> salgado: is a FooFactory something that creates Foos?
[11:27] <salgado> I guess so
[11:28] <bradb> salgado: if Foo is a content object in LP, does a thing that creates Foos belong under browser/?
[11:29] <salgado> bradb, no. that's why I asked you to create IFooSet.new() (which will live in database/)
[11:29] <bradb> we agree on that
[11:29] <bradb> do you still think it's a good idea to move the Factory itself into browser code (regardless of the implementation details of what it does to create a Foo?)
[11:30] <bradb> or do you think it's better to use a view?
[11:33] <salgado> you'll have to write less lines of code if you use a factory="browser/...", and that's why I suggested doing it. but if we have a policy against that then you should probably create a view
[11:34] <salgado> the code of the view or the factory will be almost the same.
[11:35] <bradb> yes, you're right, it will be. given that it's under browser/, i think i'll take the view approach, unless you object
[11:36] <salgado> it's up to you. I'm ok with either way
[11:36] <bradb> cool, thanks
[11:42] <daf> what the problem with having the factory in the database code?
[11:43] <salgado> daf, in this case, the factory was using ILaunchBag.user
[11:43] <daf> ok, why is that bad?
[11:44] <bradb> because it's database code. database code should be pretty dumb.
[11:44] <bradb> if its behaviour changes based on some ILaunchBag thing, it's harder to maintain
[11:45] <daf> hmm
[11:45] <daf> why doesn't the user get passed into the factory?
[11:45] <bradb> at the time i changed it, the ILaunchBag was on its way to sorting out world peace
[11:46] <bradb> but now i see the error in my ways, and that no db code should rely on it
[11:46] <bradb> in any case, the *Factory stuff is nasty as well. it really wants to be a method of the appropriate *Set.
[11:46] <bradb> i'm tempted to do a whole branch dedicated just to that
[11:47] <daf> mm, FooSet.new seems to be a good pattern
[11:47] <bradb> we seem to be inconsistent in how we do that currently.
[11:48] <bradb> .new, .createFoo, .newFoo, etc.
[11:51] <kiko> daf, so, I wanted to get to the bottom of SourcePackage and BinaryPackage traversal tomorrow too
[11:51] <kiko> daf, I believe that I'll have my code RF-merged tomorrow morning at which point I'd like to proceed to fix bug 1127
[11:51] <kiko> daf, can we sit down and get some traction on that together?
[11:51] <daf> by traversal, are we talking about canonical URLs?
[11:52] <kiko> yeah
[11:52] <daf> ok, SP should be fixed
[11:52] <daf> BP should be easy
[11:53] <daf> hmm, 1127 is blocked on 1147?
[11:53] <daf> I'm not sure I grok that one
[11:53] <kiko> well
[11:53] <kiko> it's bug 1147 actually :)
[11:53] <daf> ok
[11:54] <daf> I stumbled across this the other day
[11:54] <kiko> well
[11:54] <kiko> the issue is this
[11:54] <daf> (see my "Dude, Where's My Source Package?" mail)
[11:54] <kiko> I can't produce a link to what the bug task is associated with
[11:54] <kiko> (I know)
[11:54] <kiko> a bugtask can be filed on a distro, a source package name in a distro or a distro package name in a distro 
[11:55] <kiko> it would be nice to get somewhere meaningful given those items
[11:55] <daf> er
[11:55] <daf> you repeated yourself there
[11:55] <kiko> sorry
[11:55] <kiko> s/distro package/binary package/
[11:55] <kiko> there is currently no way to hop from a task to its target
[11:55] <kiko> that's bad.
[11:56] <daf> aye
[11:56] <daf> suckage
[11:56] <kiko> I have some code that does some of that
[11:56] <kiko> but the real fixes depend on some soyuz internals hacking
[11:56] <kiko> don't you link to source and binary packages?
[11:57] <daf> Rosetta links to source packages
[11:57] <daf> we don't have no truck with binary packages (yet)
[11:57] <kiko> I see.
[11:57] <kiko> what do you have to identify a source package?
[11:57] <daf> distro release + sp name
[11:57] <kiko> how did you conjure that link?
[11:58] <kiko> you need a named source package in a distro release
[11:58] <daf> from canonical.launchpad.database import SourcePackageSet
[11:58] <daf> sp_set = SourcePackageSet(distrorelease=self.context.distrorelease)
[11:58] <kiko> heeeeeedeous
[11:58] <daf> sp = sp_set[self.context.sourcepackagename] 
[11:58] <daf> yes
[11:58] <daf> something like that anyway
[11:58] <daf> uuugly
[11:58] <kiko> oooogly
[11:58] <daf> so, I want a getSourcePackage(name) on IDistroRelease
[11:58] <kiko> k
[11:58] <kiko> right
[11:59] <kiko> I want that on IDistro 
[11:59] <daf> hmm
[11:59] <daf> how does that work?
[11:59] <kiko> don't ask me
[11:59] <kiko> I just want it
[11:59] <daf> what would it return?
[11:59] <kiko> :-)
[11:59] <kiko> well
[11:59] <kiko> there could be a page representing an SP in a distro
[11:59] <kiko> if there isn't there should be
[11:59] <kiko> because it's so cool to do
[12:00] <daf> don't you need some release context there?
[12:00] <daf> it could return a list of source packages
[12:00] <daf> one for each distrorelease that has it
[12:00] <kiko> yeah
[12:00] <kiko> or perhaps prominently display the latest package in the current release
[12:00] <kiko> which is 99% correct
[12:00] <daf> ok
[12:00] <daf> I'll take your work for it :)
[12:01] <daf> you could easily do distro.getCurrentRelease().getSourcePackage(name)
[12:01] <kiko> yeah
[12:01] <kiko> that could work
[12:01] <daf> and presumably likewise for binary packages
[12:01] <daf> hmm
[12:02] <kiko> binary packages are a bit more complicated IIRC
[12:02] <daf> then again, binary packages need an architecture, right?
[12:02] <kiko> yeah
[12:02] <daf> it might be appropriate to throw some SubSet objects in
[12:02] <daf> this is data that is cross-sectional
[12:02] <daf> it goes across our data hierarchy
[12:03] <daf> rather than down it
[12:03] <kiko> hmmm
[12:03] <kiko> well
[12:03] <kiko> do you mean a magic binary package? :-)
[12:03] <daf> ha
[12:03] <daf> no :)
[12:04] <daf> this is an object that knows about a distrorelease and a binary package name
[12:04] <daf> and can tell you about all the binary packages that match those
[12:04] <kiko> think about what a source package is :-)