[12:28] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Override plone.css radiobutton silliness (bug 2586) (patch-2616: mpt@canonical.com)
[01:12] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Fix https://launchpad.net/products/launchpad/+bug/2662 (PersonAccountToMergeVocabulary() contains the person that is logged in) (patch-2617: guilherme.salgado@canonical.com)
[01:29] <dilys> Merge to thelove@canonical.com/dists--bazaar--1.5: new build (patch-81)
[01:30] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.5: [Fixes #78]  Add some message before prompting for signature [aldrik.kleber@tiscali.fr--public (patch 0-4)]  (patch-65: aldrik.kleber@tiscali.fr, Matthieu.Moy@imag.fr)
[01:36] <lifeless> stub: ola
[01:36] <lifeless> stub: can you point me at the scripts you have written that use baz ?
[01:36] <kiko-fud> heya stub 
[02:10] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Fix https://launchpad.net/products/launchpad/+bug/2663 (Confusing text mislead user to think both account passwords are required when merging accounts) (patch-2618: guilherme.salgado@canonical.com)
[02:56] <stub> lifeless: The Makefile.staging in dists--devel--0. Also 'rocketmeld.py' in the utilities directory of launchpad
[02:56] <mpool> morning stub
[02:56] <lifeless> stub: I ask, cause I need to bzrify them
[02:56] <lifeless> stub: unless you would like too :)
[02:57] <mpool> is this the right channel for foodix reports?
[02:58] <stub> lifeless: Don't worry about rocketmeld.py. The staging Makefile would be trivial (it just does a checkout).
[02:58] <lifeless> stub: ok.
[02:58] <mpool> i have ended up with 1:6.2.1+cvs.20050722-7 installed, but it's not present in the archive
[02:58] <mpool> i might have got that from the non-foodix copy of breezy
[03:30] <lifeless> Kinnison: ^^^ mpools lines ^^^
[03:42] <kiko-fud> mpool, you're using dogfoodix, then?
[03:44] <lifeless> stub: are you around ?
[03:44] <lifeless> bah
[03:44] <lifeless> SteveA: are YOU around ?
[03:44] <kiko-fud> I am
[03:45] <kiko-fud> but SteveA isn't for sure
[03:45] <lifeless> thanks
[03:45] <mpool> kiko-fud: yes i am
[03:45] <kiko-fud> mpool, does it require much bravery?
[03:45] <mpool> uh, should it?
[03:45] <mpool> i don't feel very brave
[03:46] <mpool> i just do as i'm told
[03:52] <stub> lifeless: yo
[03:52] <lifeless> stub: unping
[03:52] <lifeless> I wanted the other stub
[03:53] <stub> unpong
[06:05] <mpool> feh
[06:40] <dilys> Merge to rocketfuel@canonical.com/launchpad--production--1.36: Cherry pick patch 2612 into production 1.36 (patch-4: rocketfuel@canonical.com, guilherme.salgado@canonical.com)
[07:56] <BjornT> good morning
[07:56] <jamesh> lifeless: ping?
[08:01] <lifeless> jamesh: pong
[08:03] <jamesh> lifeless: w.r.t. your comment on my bug-74 branch, if I switch to "abbreviated_textdir" on the content class, do I have r=lifeless?
[08:03] <lifeless> oh yes
[08:03] <lifeless> btw, you know that pendingreviews is failing tests ?
[08:03] <jamesh> yeah
[08:04] <jamesh> I need to do some more extensive changes to handle branches-with-the-revision-number-set, but didn't fix up the problems in the bzr version (will fix it soon)
[08:07] <lifeless> ok
[08:07] <lifeless> I plan to rollout pqm-bzr this week
[08:08] <jamesh> the test suite error looks a bit weird because the __eq__ method is catching AttributeError
[08:09] <lifeless> yes
[08:10] <lifeless> it was obvious what the issue is :0
[08:43] <stub> jamesh, lifeless: So about this gpg tool thingy. Daniel wants gina running on production, like, tomorrow and I would prefer to run this thing before that.
[08:49] <stub> 17:29:09) stub: jamesh: yes. People need to be able to create and edit their own hackergotchi (there was an email on this which I can't locate)
[08:49] <stub> (17:29:54) stub: jamesh: Did the GPG web-o-trust stuff land, and if so what should I run on staging?
[08:49] <stub> (17:32:58) James Henstridge: stub: there are two scripts -- the first of which needs access to the gpg strongly connected set and list of trusted keys
[08:49] <stub> (17:33:16) James Henstridge: the second is responsible for updating the database, and uses the output of the first script
[08:49] <stub> (17:33:40) James Henstridge: stub: lifeless would know what data to use for the first one
[08:49] <stub> (17:34:18) stub: ok. so the first script needs to only be run once anywhere and we can use the output on staging, and if we are happy with the result, production
[08:49] <stub> (17:34:47) James Henstridge: yeah
[08:50] <jamesh> lifeless: whereabouts would I get the strongly connected set data to do a run of the script?
[08:50] <jamesh> (and which keyrings do we treat as trusted?
[08:51] <lifeless> jamesh: search me
[08:51] <lifeless> trusted, ubuntu-keyring, debian-keyring
[08:51] <jamesh> ubuntu-keyring has two keys in it on my system
[08:52] <jamesh> "Ubuntu Archive Automatic Signing Key" and "Ubuntu CD Image Automatic Signing Key"
[08:52] <lifeless> mm
[08:53] <lifeless> apt-cache search keyring perhaps
[08:58] <jamesh> lifeless: are we able to get a dump from our local keyserver?
[08:58] <stub> Can we just use one of our own keyrings? 
[08:58] <lifeless> jamesh: I imagine so
[08:58] <jamesh> these are some of the PGP bits I'm not versed in
[08:58] <lifeless> jamesh: but I have not been involved with the keyserver foo
[09:02] <stub> So it sounds like a tool has been written without thought on how it is supposed to be run :-/
[09:04] <lifeless> stub: lots of though
[09:04] <lifeless> stub: we know what format the things we get will be in , and for 2/3 of them we knew where to get them
[09:04] <fabbione> jamesh: a dump of a keyserver is approx 4GB...
[09:05] <lifeless> fabbione: we just want the strongly connected set
[09:05] <fabbione> just abuse the server.. it's better for the few keys you need compared to the 2.5M in there
[09:05] <stub>  But this tool is supposed to *calculate* that
[09:05] <lifeless> stub: no, its not.
[09:05] <fabbione> lifeless: just start from my or your key and grab them.. they are about 22K iirc
[09:06] <lifeless> stub: its supposed to use the debian + ubuntu 'trusted keys', plus relationships spidering out from there within the SCC, to establish with some degree of confidence that user A and user B are the same person
[09:06] <lifeless> stub: if we wanted the SCC alone, we would not have written code.
[09:06] <stub> I call that calculating a trusted set of keys. 
[09:07] <fabbione> lifeless: anyway to get a full dump, you need to stop the keyserver
[09:07] <lifeless> stub: a trusted set of keys is not the strongly connected set.
[09:07] <jamesh> stub: it starts with a trusted set of keys, and ends up with a trusted set of (key, uid) pairs
[09:07] <lifeless> stub: the SCC/SCS is a different beast to what we are calculating.
[09:07] <stub> Indeed. I never said SCC or SCS. I don't even know what those abbreviations stand for.
[09:08] <jamesh> stub: the starting conditions are "keys owned by people we trust to make good signing decisions", and the second is "(key, uid) pairs we are confident are correct"
[09:08] <lifeless> stub: well, I'll stop this thread, except to note it started when I said 'we need the scc, and you said 'its meant ot calculate that''
[09:08] <jamesh> strongly connected set == a set of nodes that can all reach each other via the directed edges between the nodes
[09:09] <jamesh> "the" strongly connected set would be the big one in the PGP web of trust
[09:10] <lifeless> we're interested the one around debian/ubuntu though, which is the same one IIRC
[09:10] <stub> Anyway. I still need to know how to run this tool. So far all I'm hearing is that it is not ready yet, because a part of the chain is missing.
[09:10] <stub> As it doesn't build its own keyring, someone needs to build one for it. And I doubt the 4GB full dump is appropriate.
[09:11] <lifeless> jamesh: are you looking for a scc at the moment ?
[09:11] <jamesh> lifeless: I haven't started yet.  Should I try Fabbione's idea?
[09:12] <lifeless> jamesh: there are precanned ones, I suggest goodle
[09:12] <stub> How can we trust a precanned one? 
[09:12] <lifeless> by the signatures in the debian and ubuntu keyrins
[09:12] <lifeless> *keyrings*
[09:16] <stub> So we trust a precanned SCC if it has been signed by a key in the debian or ubuntu keyrings? 
[09:17] <stub> That would indicate it has been manually uploaded and signed, which would be out of date. So crawling our own keyserver would be the better approach.
[09:18] <lifeless> stub: its not *that* dynamic a thing
[09:18] <lifeless> but, if you want to, http://www.dtype.org/keyanalyze/code/
[09:20] <stub> Oh - do we actually *need* to trust that the SCC we use is acurate, or does our code verify if each key in the keyring is trusted enough for our purposes?
[09:20] <lifeless> the latter
[09:20] <lifeless> the only keys we *actually trust* are the ubuntu and debian ones.
[09:21] <lifeless> at least, as I understand it from when I was working on it.
[09:21] <lifeless> jamesh should be able to confirm
[09:21] <lifeless> trusting random people who happen to have had their key signed and signed someone elses would be rather dumb.
[09:22] <jamesh> lifeless: yeah.  only the keys on keyrings passed with --trust have their ownertrust value set.
[09:22] <jamesh> gpg does the rest
[09:22] <stub> And I assume that the code actually *does* need the keyring prebuilt and there is no magic option to the GPG library we are using to pull down unknown keys from the keyserver?
[09:23] <lifeless> stub: it will pull unknown keys automatically
[09:23] <lifeless> but that is relatively slow
[09:23] <lifeless> its preferred to have as much pre-seeded as possible
[09:23] <stub> So all we need is any one of our keys and we can run it. 
[09:23] <lifeless> (because each key we add needs another trustdb rebuild and that is not incremental)
[09:24] <stub> yech.
[09:24] <lifeless> stub: install the debian-keyrin and ubuntu-keyring packages, or extract the keyrings from them
[09:24] <lifeless> stub: then you have the bare minimum
[09:24] <lifeless> let me see about an ubunut accurate list
[09:27] <stub> I still havn't the foggiest idea what actually needs to be run. Anyone care to tell me what the scripts are called? Is it 'scripts/find-email-clusters.py' ?
[09:27] <stub> ok - that looks like it.
[09:28] <jamesh> stub: yeah.  you'd run "find-email-clusters.py --trust trusted-keyring.gpg scc.gpg"
[09:29] <stub> jamesh: scripts and cronscripts should have 'import _pythonpath' as the first import because I'm too lazy to set PYTHONPATH explicitly
[09:29] <jamesh> you can specify multiple trusted keyrings by repeating the --trust option, and multiple untrusted keyrings as positional args
[09:30] <stub> So where can I find the ubuntu and debian keyrings?
[09:30] <jamesh> "apt-get install debian-keyring ubuntu-keyring"
[09:30] <jamesh> and they'll be in /usr/share/keyrings/
[09:31] <stub> No apt get here - I don't have root ;)
[09:32] <stub> nope.
[09:32] <stub> bah
[09:33] <sabdfl> morning all
[09:33] <lifeless> gmorning
[09:33] <jamesh> stub: http://ftp.debian.org/debian/pool/main/d/debian-keyring/debian-keyring_2005.05.28.tar.gz should be it
[09:33] <lifeless> stub: jamesh: ubuntu keyring needs elmo to export it. I suggest trialling it without it for now
[09:34] <stub> I just need to extract the debian keyring locally and upload it since it doesn't seem to exist on the machines I have access to
[09:34] <stub> This should have all been hardcoded in the script :-/
[09:35] <jamesh> stub: the tarball I gave the URL to should have it
[09:35] <jamesh> (I think)
[09:35] <stub> jamesh: How do we trust it?
[09:36] <jamesh> stub: check the signature in the dsc file
[09:36] <lifeless> the keyrings md5 sum is signed by elmo
[09:36] <jamesh> stub: alternatively, pull it from the Ubuntu repository
[09:36] <stub> jamesh: That involves doing it all locally again ;)
[09:36] <lifeless> The rsync area on keyring.debian.org is the canonical location for
[09:36] <lifeless> keyrings and it is what the Debian installer program (dinstall) uses.
[09:36] <lifeless> If your key is available from there, it will be seen by dinstall.  The
[09:36] <lifeless> tarball and Debian package are provided for user convenience and are
[09:36] <lifeless> not necessarily in sync with keyring.debian.org.
[09:36] <lifeless> That file contains the keyrings, signed copy of keyring md5sums and
[09:36] <lifeless> this README.  The keyring md5sums will be signed by James Troup.
[09:37] <ddaa> lifeless: please review importd-archivelocation today
[09:37] <lifeless> ddaa: yes
[09:37] <ddaa> it's a prerequisite for niemeyer starting fixing import for branchdatastorage
[09:37] <lifeless> ack
[09:37] <lifeless> I dont do it, you block, we all suck.
[09:37] <ddaa> not yet quite blocked on it
[09:40] <stub> Once we have run this, who can check that it has done what it is supposed to?
[09:46] <stub> jamesh, lifeless: ^^^
[09:51] <stub> It is bombing: https://chinstrap.ubuntu.com/~dsilvers/paste/file3NPAqW.html
[09:56] <jamesh> stub: did you pass a non-trusted keyring?
[09:56] <stub> It did the samething when I did
[09:56] <fabbione> lifeless: for a fast import you can disable the --check-trustdb option
[09:57] <fabbione> lifeless: and run it manually at the end of the import
[09:57] <jamesh> stub: ah. try replacing ~ with $HOME, maybe?
[09:57] <jamesh> fabbione: we already do that
[09:58] <stub> eh? I thought bash did that for me ;-/
[09:58] <jamesh> I'm guessing
[10:00] <stub> Hmm... seems to be running now.
[10:01] <stub> bombed out again. it is doing *something* though before it bombs.
[10:07] <stub> Still running this time...
[10:11] <stub> Should I be running this with '-v' ?
[10:13] <stub> jamesh: I believe parser.error('the error') is the badly documented yet preferred method of raising an error on bad command line arguments
[10:23] <SteveA> hi
[10:23] <SteveA> lifeless: did you want something?
[10:29] <lifeless> SteveA: advice on some evil python stuff
[10:29] <lifeless> that I was unsure about doing
[10:31] <stub> I have 3790 lines of output from the find-clusters.py script. Does that sound correct?
[10:39] <stub> I think I'm going to have to give up on this until someone-who-knows can help running this stuff on staging and confirming that it works and run gina without it (which is a shame, because we have been blocking gina since brazil for this :-( )
[10:44] <sivang> Good Morning all
[10:45] <jamesh> stub: it should be groups of email addresses separated by blank lines
[10:45] <stub> jamesh: it is. but should I have 10 or 1,000,000?
[10:46] <jamesh> stub: would depend on how many keys you looked at.  Was this just the debian keyring?
[10:47] <stub> jamesh: I ran it with the debian keyring as the trusted keyring, and a copy of the debian keyring as the strngly connected set.
[10:48] <jamesh> stub: then that sounds like about the right amount of data
[10:48] <jamesh> a quick check shows ~ 3500 unique uids in that keyring, all of which would be considered valid if you trust all those keys
[10:49] <stub> jamesh: but what about all the other keys that we infer trust for?
[10:49] <jamesh> stub: if you ran it without any other keys, then there is no other keys to infer trust for.
[10:50] <stub> There is a whole keyserver to interrogate. 4GB of keys.
[10:50] <stub> (17:23:13) Robert Collins (lifeless): stub: it will pull unknown keys automatically
[10:54] <jamesh> I think he was talking about http://www.dtype.org/keyanalyze/code/
[10:55] <stub> argh. So I've wasted the last hour or so, because my original impression was correct and the code isn't yet useful to us.
[11:02] <SteveA> stub: so, my merge didn't go through last night.  i'm going to try again, but i don't want to conflict with your browser messages stuff.
[11:04] <SteveA> ddaa: we should talk about the python import, and 32k
[11:05] <ddaa> eeeer, yes honey?
[11:06] <SteveA> i don't think a importing a sticky sweet python will help anyone
[11:06] <ddaa> do you mean it should be less sticky?
[11:06] <ddaa> (whatever that means)
[11:06] <SteveA> honey is sticky regardless.
[11:07] <ddaa> let's avoid absurd jokes...
[11:07] <ddaa> SteveA: so, what with the goddamn python import?
[11:08] <SteveA> so, you checked out apache and other tools, that they can handle 32k subdirectories
[11:08] <SteveA> you need to decide with lifeless about whether it needs to be available on the supermirror
[11:08] <SteveA> then, we need to decide on what size partition on what machines to request
[11:08] <ddaa> Yes.
[11:09] <carlos> hi
[11:09] <SteveA> hello carlos
[11:09] <carlos> SteveA, I'm with the gas installation, they are taking much more time than I expected
[11:09] <SteveA> okay
[11:09] <SteveA> carlos: please see the email from Timo Jyrinki 
[11:09] <carlos> ok
[11:09] <SteveA> on rosetta-users
[11:09] <ddaa> I did not check very thoroughly, but the toolchain is only using stuff that's so standard it should have no problem with large number of subdirs.
[11:11] <ddaa> One bit that might be worth checking though is the backup tool, but it's outside of my control.
[11:11] <ddaa> if anything else break, I'll happily offer large amounts of beer to annoyed parties
[11:12] <SteveA> if the backup tool doesn't work, we'll just need to work without backups until we get a proper bzr backend
[11:12] <SteveA> or use different, less frequent backups "by hand"
[11:14] <ddaa> So, you want me to send clarifications about publishing requirements and disk space requirements?
[11:14] <ddaa> to you and elmo?
[11:15] <ddaa> Anything else?
[11:18] <SteveA> i think that's all.  and where you want the partition's mountpoint to be
[11:19] <SteveA> exactly what machines it needs to be on
[11:19] <carlos> stub, is staging being updated every day?
[11:19] <stub> yes
[11:20] <ddaa> SteveA: okay, I'll get clear requirements from lifeless (writing email now).
[11:21] <SteveA> stub: i'm merging my LaunchpadBrowserRequest thing with pqm now
[11:22] <stub> SteveA: ok
[11:22] <ddaa> SteveA: is that the thing we talked about yesterday?
[11:22] <SteveA> ddaa: it makes things easy for the traversal code you need to write, yes
[11:23] <ddaa> I'm starting to block on it (I can still work on pending sql pach work for a day or so)
[11:25] <SteveA> ddaa: so, once pqm has done its stuff, i'll switch to your branch, and send you a patch that does the things you need
[11:25] <ddaa> Lovely.
[11:41] <ddaa> stub: SQL trivia
[11:41] <carlos> SteveA, I really need the review for my language pack branch
[11:41] <carlos> SteveA, would that be possible?
[11:41] <SteveA> sure
[11:42] <SteveA> is it ready on the pending reviews page?
[11:43] <carlos> yeah
[11:43] <ddaa> I have a Branch table, with a foreign key started_at to RevisionNumber. And RevisionNumber has a foreign key branch to the Branch table. How do I add a constraint so that branch.started_at.branch == branch?
[11:44] <SteveA> carlos.perello@c.c--2004/launchpad--language-pack-export--1
[11:44] <carlos> SteveA, yeah
[11:46] <ddaa> (where started_at can be NULL)
[11:47] <stub> ddaa: Generally you don't
[11:48] <ddaa> stub: I guess you could use a procedural constraint. How do you generally draw the line here?
[11:49] <stub> ddaa: I think it depends on how many different components of our systems need to update those tables. 
[11:49] <ddaa> mh
[11:50] <ddaa> RevisionNumber would only be updated by Taxi. But Branch.started_at could be updated by any number of components, including the web UI.
[11:50] <stub> ddaa: We can do it with a trigger, but I doubt the extra complexity is worth it if we can be fairly sure the code that updates those tables do the right thing.
[11:51] <ddaa> Bah... I guess I could add an assert in the database class.
[11:52] <ddaa> stub: thanks
[11:55] <SteveA> carlos: have you checked out the database stuff in that branch with stub?
[11:57] <stub> ddaa: I think we can do it with a foreign key constraint. If you paste what you have I can update it. It involves making RevisionNumber(branch, id) UNIQUE and declaring a FOREIGN KEY (id, started_ad) REFERNECES RevisionNumber(branch, id) on Branch
[12:00] <ddaa> stub: you rock
[12:00] <carlos> hmm
[12:00] <carlos> SteveA, I don't remember it....
[12:02] <carlos> SteveA, stub, do we need to check the additions to the security file?
[12:03] <carlos> didn't know that...
[12:03] <SteveA> they look like the minimum you need
[12:03] <ddaa> stub: here's what the patch currently looks like
[12:03] <ddaa> https://chinstrap.ubuntu.com/~dsilvers/paste/fileHhw8IB.html
[12:03] <ddaa> no garantee it's even valid sql at this point :)
[12:05] <ddaa> I'm not sure the extra UNIQUE constraint is really necessary as RevisionNumber.id is already unique (being a primary key), but maybe postgres requires it.
[12:06] <stub> ddaa: The extra UNIQUE on the two columns is required to allow a foreign key reference to those two columns
[12:08] <ddaa> there's a TODO in the patch at the place where I think the constraint shoud be added (but you own that anyway...)
[12:15] <Kinnison> Who here knows about the GPG interface in launchpad?
[12:18] <jamesh> can someone check to see if pqm has hung?
[12:19] <jamesh> Kinnison: UI or IGPGHandler stuff?
[12:19] <Kinnison> jamesh: the latter
[12:21] <Kinnison> I think I can get the Person record reasonably easily
[12:21] <Kinnison> but I need to know how to extract the key using the launchpad infrastructure
[12:22] <Kinnison> I need the literal key data for the gpg verification stuff for package uploads
[12:23] <jamesh> Kinnison: getUtility(IGPGHandler).retrieveKey(keyid) seems to work for short IDs as well as fingerprints
[12:23] <jamesh> doing an import if necessary
[12:23] <stub> ddaa: You are deleting the contents of Branch, but there are rows in ManifestEntry that reference stuff in there.
[12:24] <stub> erm... c/Branch/Revision
[12:24] <jamesh> Kinnison: of course, if you have the Launchpad person, you should have full fingerprints for the user's keys
[12:24] <Kinnison> jamesh: I have a 64 bit keyid, that's *IT*
[12:25] <jamesh> Kinnison: is this keys not registered in Launchpad then?
[12:26] <Kinnison> jamesh: it might be in launchpad, I don't know yet
[12:26] <Kinnison> jamesh: I've just been presented with a clearsigned text file
[12:26] <Kinnison> jamesh: I can get the keyid from that
[12:26] <Kinnison> jamesh: from there, I have to find everything else out, including whether or not the file was tampered with
[12:27] <ddaa> stub: I'm pretty sure I checked out with Keybuk about that...
[12:28] <ddaa> making a full update would be a big pain :(
[12:28] <jamesh> Kinnison: okay.  There are two interfaces here: the IGPGHandler stuff will let you retrieve the key (from the keyserver), and can do so by the short ID
[12:28] <ddaa> stub: I have to go to lunch now, back in about 45 mins
[12:28] <jamesh> Kinnison: the IGPGKeySet interface lets you see keys the Launchpad database knows about
[12:29] <Kinnison> jamesh: will the IGPGHandler literally give me the key as a string?
[12:30] <jamesh> Kinnison: it gives you an object representing the key, so you can get its fingerprint, uids, etc
[12:30] <stub> ddaa: There are only 4 manifestentries on production
[12:30] <Kinnison> jamesh: I want, quite literally, the keydata
[12:31] <Kinnison> jamesh: *OR* I want to know the full path to the keyring that the IGPGHandler has just imported a key into
[12:31] <Kinnison> jamesh: which of those two can be supplied?
[12:32] <jamesh> Kinnison: the keyring would be $GNUPGHOME/pubring.gpg
[12:32] <Kinnison> jamesh: thanks.
[12:33] <Kinnison> jamesh: and that's configured, simply by doing blah=getUtility(IGPGHandler) ?
[12:33] <Kinnison> jamesh: or do I have to do something to set stuff up before I can rely on $GNUPGHOME/pubring.gpg being present?
[12:33] <jamesh> Kinnison: are you sure the IGPGHandler.verifySignature() method wouldn't be appropriate?
[12:34] <Kinnison> The import stuff has a very very very specific wrapper around the gpgv implementation
[12:34] <Kinnison> at this point in the game, I don't want to not use it
[12:34] <Kinnison> elmo trusts the handler I have, it's important not to lose that level of trust to begin with
[12:35] <Kinnison> Or are you telling me that I can simply ask the IGPGHandler to verify a bit of clearsigned content and it will not only tell me whether or not it is valid, but who signed it etc, without first being primed with the key?
[12:36] <jamesh> let me do a quick check
[12:38] <SteveA> carlos: reviewed
[12:38] <jamesh> Kinnison: gpg = getUtility(IGPGHandler); sig = gpg.verifySignature(clearsigned_data)
[12:38] <jamesh> Kinnison: sig.fingerprint is the fingerprint, sig.plain_data is the associated data
[12:39] <Kinnison> jamesh: even without feeding it keys first?
[12:39] <jamesh> Kinnison: the gpg config is set to auto-key-retrieve
[12:39] <Kinnison> right
[12:40] <Kinnison> and then I can do getUtility(IGPGKey).selectBy(fingerprint=sig.fingerprint)
[12:40] <Kinnison> yes?
[12:40] <jamesh> yep
[12:40] <jamesh> well, IGPGKeySet
[12:40] <jamesh> and getByFingerprint()
[12:41] <jamesh> if you get a key record, you can then get the person object
[12:41] <Kinnison> cool, ta
[12:42] <SteveA> ddaa: ping
[12:42] <Kinnison> jamesh: and if it's unable to get the key?
[12:42] <Kinnison> jamesh: or if the data is damaged?
[12:43] <jamesh> Kinnison: the key record?
[12:43] <jamesh> Kinnison: if IGPGKeySet.getByFingerprint() returns None, then the key has not been registered in launchpad
[12:43] <Kinnison> jamesh: consider a clearsign by a key never uploaded to the keyserver
[12:43] <Kinnison> jamesh: such that the gpg instance can't fetch it
[12:44] <jamesh> Kinnison: then the signature verification would fail
[12:44] <jamesh> Kinnison: but all keys registered in the Launchpad database come from the keyserver network
[12:44] <jamesh> (the registration process asks you for the key fingerprint, and then retrieves the key from the keyserver)
[12:46] <Kinnison> jamesh: aye, but we have to consider uploads from people who are not registered and fail gracefully
[12:46] <Kinnison> jamesh: so what happens if the verification fails? do I get "None" back? a reason, or an exception raised?
[12:46] <jamesh> Kinnison: that would be a policy decision.
[12:47] <jamesh> Kinnison: yep.  If the verification fails, verifySignature() returns None
[12:47] <Kinnison> urgh
[12:47] <Kinnison> no reason?
[12:47] <carlos> SteveA, thanks
[12:47] <jamesh> nope
[12:47] <Kinnison> not good enough then
[12:48] <SteveA> lifeless: ping
[12:48] <Kinnison> where is the implementation of IGPGHandler?
[12:48] <SteveA> ctags
[12:48] <jamesh> lib/canonical/launchpad/utilities/gpghandler.py
[12:48] <Kinnison> jamesh: ta
[12:48] <jamesh> the other half is pyme :)
[12:48] <SteveA> idtools ;-)
[12:50] <SteveA> looks like pqm        398  0.0  0.0   2280   860 ?        S    10:53   0:00 nc -l -p 2401 -e /home/pqm/arch/queue/workdir/rocketfuel@canonical.com/rocketfuel@canonical.com---launchpad--devel--0/launchpad/sourcecode/cscvs/,,repoCatalog/CVSROOT/server
[12:51] <SteveA> lifeless, ddaa: looks like some cscvs stuff is hanging pqm
[12:52] <kiko-zzz> Kinnison, do you require sign-only keys to work?
[12:53] <Kinnison> kiko: given that the key has to be in launchpad for verification and identification, I'll be happy with whatever makes it into launchpad
[12:53] <Kinnison> I'd like for signing-only to work
[12:53] <kiko> Kinnison, yeah, bug 1972 would be great to fix
[12:53] <Ubugtu> Malone bug #1972: Problem validating sign-only GPG key Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Celso Providelo, Status: Accepted http://launchpad.net/malone/bugs/1972
[12:53] <kiko> jamesh, would you be able to help us debug 1972?
[12:53] <carlos> wow
[12:53] <Kinnison> kiko: It may be essential for the distro team
[12:53] <carlos> who develop Ubugtu?
[12:54] <kiko> jamesh, it requires some gpgme research, I think
[12:54] <kiko> carlos, Seveaz 
[12:54] <carlos> cool
[12:54] <jamesh> kiko: I added a comment a few hours ago.  Does it sound like a possible reason?
[12:55] <kiko> let me check
[01:02] <kiko> jamesh, that's an analysis of the second part of the problem
[01:02] <kiko> jamesh, I'm going to file a new bug on it
[01:02] <kiko> jamesh, I'm asking more about the fact that sign-only keys don't work
[01:04] <jamesh> kiko: that they don't work for op_encrypt(), or that we offer no method to register such keys?
[01:07] <kiko> jamesh, I think the latter is intractable :-) so it's the former.
[01:15] <kiko> err sorry
[01:15] <kiko> the opposite, jamesh 
[01:19] <carlos> kiko, didn't you asked me to change the validation function from helpers to potmsgset a couple of weeks ago?
[01:22] <ddaa> stub: SteveA: back
[01:22] <jamesh> kiko: okay.  First thing we need to do is expose subkey information on IPymeKey instances.  That'll give us can_encrypt, can_sign, etc attributes for each subkey
[01:23] <jamesh> kiko: if a key has no encrypting subkeys, then we'll need to fall back to a separate "signing key" registration scheme like what Kinnison described in the bug
[01:24] <ddaa> stub: manifestentry.changeset is always NULL
[01:25] <jamesh> kiko: we'd probably want to note the fact that a key has only been registered for signing in the gpgkey table (an extra bool column should do)
[01:25] <ddaa> therefore I can safely delete all changeset/revision records
[01:25] <stub> ok
[01:26] <jamesh> kiko: actually, we won't necessarily have to expose all the subkey information -- we can just have a key-level can_sign, can_encrypt, etc attributes
[01:26] <jamesh> calculate those once
[01:26] <SteveA> jamesh: lifeless has reset pqm.  stub, elmo and znarl also know how to do this and have rights to do so, for future reference
[01:27] <kiko> carlos, I did, yes.
[01:27] <kiko> carlos, and AIUI you did it!
[01:27] <carlos> I know
[01:27] <carlos> but the language pack branch lacks that change
[01:27] <carlos> and last merge with rocketfuel was last week...
[01:28] <carlos> so I wonder if I have an unmerged branch...
[01:28] <kiko> jamesh, but how are we going to validate the key if we can't encrypt? only by using a scheme such as Kinnison suggested.
[01:28] <kiko> ah
[01:28] <kiko> that's what you're saying.
[01:28] <kiko> jamesh, that sounds perfect
[01:29] <kiko> jamesh, could you cook up a patch? as soon as that's landed we can work on registering sign-only keys
[01:30] <jamesh> kiko: sure.
[01:30] <jamesh> kiko: do you want subkey information available, or just the summary can_sign,can_encrypt,etc attributes?
[01:30] <jamesh> or both?
[01:34] <kiko> jamesh, hmmm. I don't think I need the subkey for anything -- I just need to be able to encrypt or sign content depending on the capability of the subkeys -- so just the summaries are fine. Kinnison, do you need specific subkey information?
[01:34] <jamesh> kiko: we won't be able to encrypt or sign the message to the owner of a sign-only key (unless we are signing with a "launchpad" key)
[01:35] <jamesh> kiko: we can only verify the signatures made with that key
[01:36] <carlos> stub, hi, around?
[01:36] <stub> yes
[01:37] <carlos> stub, about my request to change the rawimportstatus field
[01:37] <carlos> stub, why do you think we need to reset the rawfile field?
[01:37] <kiko> jamesh, err, yeah, what you said 
[01:39] <carlos> stub, the constraint is that you cannot have rawfile as null if rawimportstatus is 1
[01:39] <carlos> sorry
[01:39] <carlos> stub, the constraint is that you cannot have rawfile as null if rawimportstatus is > 1
[01:39] <Kinnison> ddaa: If I replay a patch from the middle of a branch into rocketfuel, will that cause issues later when I merge that branch in?
[01:40] <stub> carlos: The CHECK constraint is "pofile_rawimportstatus_valid" CHECK (rawfile IS NULL AND rawimportstatus <> 2 OR rawfile IS NOT NULL)
[01:40] <kiko> Kinnison, you need to sync-tree afterwards
[01:41] <Kinnison> kiko: why on earth would I need to sync-tree? I don't want to prevent it from merging patches from earlier on the branch
[01:41] <carlos> stub, yeah, more or less is the same
[01:41] <carlos> stub, it's less restrictive than what I said
[01:41] <Kinnison> kiko: I have a self-contained patch for adding reason information for a failure on signature verification to IGPGHandler 
[01:41] <stub> carlos: I can't remember what the original request was
[01:41] <Kinnison> kiko: It's on my uploader branch, which obviously contains stuff not yet ready for merging
[01:41] <carlos> stub, but the way we develop the code, rawfile will not be NULL unless rawimportstatus is == 1
[01:42] <carlos> stub, set rawimportstatus =2
[01:42] <Kinnison> lifeless: ping?
[01:42] <carlos> stub, when it's 4 or 1 and rawfile is not null
[01:43] <stub> eh?
[01:43] <Kinnison> stub: thanks for that approval
[01:43] <carlos> stub:
[01:43] <stub> carlos: UPDATE POFile SET rawimportstatus=2 WHERE rawimportstatus in (1,4) and rawfile is not null?
[01:43] <carlos> UPDATE POTemplate set rawimportstatus=2 WHERE rawimportstatus=4;
[01:43] <carlos> UPDATE POFile set rawimportstatus=2 WHERE rawimportstatus=4;
[01:44] <carlos> stub, yeah, that's more complete
[01:44] <stub> stop confusing me!
[01:44] <carlos> stub, I just pasted you the request I did
[01:44] <carlos> ok
[01:44] <carlos> I need this: 
[01:44] <carlos> UPDATE POFile SET rawimportstatus=2 WHERE rawimportstatus in (1,4) and rawfile is not null;
[01:44] <carlos> UPDATE POTemplate SET rawimportstatus=2 WHERE rawimportstatus in (1,4) and rawfile is not null;
[01:46] <stub> ok ;)
[01:46] <stub> carlos: done
[01:46] <carlos> stub, thanks!
[01:48] <ddaa> kiko: the sync-tree thing is only for replay --reverse
[01:49] <ddaa> and I'm not sure about the specific situation there's a problem with that
[01:50] <ddaa> Kinnison: the main issue you'll have is that star-merge, update, etc. determine which revision of a branch a tree is up to date to by looking at the latest patchlog for that branch present in the tree.
[01:50] <Kinnison> I *guess* I could just star-merge my branch
[01:50] <Kinnison> since everything on it is fairly self-contained
[01:51] <ddaa> IOW if you try to star-merge that branch into rocketfuel, or any branch that merged rocketfuel after that, it will not do the right thing.
[01:51] <Kinnison> If I can get a review for https://chinstrap.ubuntu.com/~dsilvers/paste/fileJoJOjK.html then I can do that
[01:51] <Kinnison> anyone? It's very small
[01:51] <Kinnison> ddaa: I guessed it might make star-merge hiccough
[01:51] <Kinnison> ddaa: so I'll not replay, but instead merge as normal
[01:51] <Kinnison> thusly I need that gpg patch reviewing
[01:51] <Kinnison> jamesh: any chance you can cast your eye over: https://chinstrap.ubuntu.com/~dsilvers/paste/fileJoJOjK.html ?
[01:51] <ddaa> Kinnison: that's one of the things that mesh-merge meant to fix
[01:52] <Kinnison> ddaa: I can appreciate that
[01:52] <jamesh> Kinnison: that's going to cause problems with multithreaded apps
[01:52] <jamesh> (like Launchpad)
[01:53] <Kinnison> jamesh: aah, I figured each thread would have its own IGPGHandler instance
[01:53] <jamesh> Kinnison: nope.  There's just one of each utility
[01:53] <Kinnison> bugger
[01:53] <einheit> the launchbag is special though
[01:53] <einheit> as it puts its state in a thread local
[01:54] <Kinnison> jamesh: in lua, it'd be easy, I'd just "return nil, reason"
[01:54] <Kinnison> jamesh: but in python, that'll cause tuple joy
[01:55] <jamesh> Kinnison: one way would be to turn verifySignature() into verifySignatureEx(), which returned the error message, and make verifySignature() a wrapper around that
[01:55] <jamesh> (that's not a very good method name though)
[01:55] <SteveA_> ddaa: is the python import now unblocked?
[01:55] <Kinnison> jamesh: It would do for now though, wouldn't it?
[01:55] <SteveA_> ensureSignature?
[01:55] <SteveA_> which would raise
[01:56] <ddaa> SteveA: now that the requirements are clarified, i'll proceed with putting the stuff in place and coordinating with jblack and elmo.
[01:56] <Kinnison> so make verifySignature() wrap _verifySignature() and ensureSignature() which wraps and raises?
[01:56] <ddaa> so, if anything it's blocked on me ATM
[01:56] <SteveA_> ddaa: okay.  please keep me and lifeless up to date about how it is going
[01:56] <Kinnison> SteveA_: or, make verifySignature() wrap ensureSignature() and swallow the exception?
[01:57] <jamesh> Kinnison: that's what I was suggesting -- make the old function a wrapper around the new function
[01:57] <Kinnison> jamesh: okay
[01:58] <Kinnison> jamesh: I'm gonna do that now, one sec
[01:59] <lifeless> ddaa: importd-archivelocationconflicts
[01:59] <ddaa> Iguessyouaremissingaspaceinthere
[02:00] <lifeless> ddaa: and appears to have random cruft in it
[02:00] <lifeless> ddaa: search for buildd/debian.py in https://chinstrap.ubuntu.com/~jamesh/pending-reviews/david.allouche@canonical.com--2004/launchpad--importd-archivelocation--1/filtered-diff
[02:01] <ddaa> weird
[02:01] <lifeless> conflict related
[02:01] <lifeless> but there is too much noise for me to tell who did what
[02:01] <ddaa> I'll fix that
[02:01] <ddaa> right now
[02:01] <lifeless> thanks
[02:03] <lifeless> ok, I cannot finish this tonight, thats for sure, but its looking positive
[02:03] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  small refactor of the request type used in launchpad, to make certain traversal tricks more straightforward. (patch-2619: steve.alexander@canonical.com)
[02:04] <matsubara> good morning!
[02:04] <SteveA_> hi matsubara 
[02:04] <ddaa> lifeless: that's okay, I got python import stuff to do, and some launchpad stuff once SteveA_ sent me a patch. I will not be idle.
[02:04] <SteveA_> ddaa: my change that you need has landed in RF
[02:05] <ddaa> SteveA_: and my pony?
[02:05] <ddaa> SteveA_: I mean, thanks :)
[02:06] <ddaa> hello niemeyer
[02:06] <jamesh> kiko: while I'm at it, would it be helpful if GPGHandler.encryptContent() explicitly raised an exception if can_encrypt==False?
[02:06] <niemeyer> Hiho!
[02:06] <ddaa> ddaa.fork()
[02:06] <SteveA_> ddaa: please remind me of the branch i should get to work on a patch for your urls and traversal
[02:06] <niemeyer> ddaa: Gubby is quite interesting.. I am curious to try it :)
[02:06] <ddaa> -ENOTIMPLEMENTED
[02:06] <ddaa> rats!
[02:07] <SteveA_> (i'm at home rather than in the office, with the heating engineer taking the boiler apart)
[02:07] <ddaa> SteveA: david.allouche@canonical.com--2004/launchpad--sprint--0
[02:07] <SteveA_> ok
[02:07] <jamesh> kiko: (it already raises an exception in op_encrypt(), but this would make it obvious that the reason is a signing-only key)
[02:07] <SteveA_> hi salgado 
[02:07] <ddaa> niemeyer: http://ddaa.net/blog/gobby-first-look
[02:08] <ddaa> some essay about collaborative text editing
[02:09] <salgado> hi SteveA 
[02:09] <Kinnison> jamesh: https://chinstrap.ubuntu.com/~dsilvers/paste/fileQrfq6P.html
[02:09] <ddaa> lifeless: okay, I found the problem, the -1 branch comes from launchpad--production--1.35, instead of rocketfuel, my confusing
[02:10] <kiko> jamesh, yes, it would
[02:11] <niemeyer> ddaa: "When a user loads a document, the whole document appears with the background colour of that user"
[02:11] <niemeyer> ddaa: Interesting, that was the first issue I noticed as well :)
[02:12] <ddaa> fixing that is high on their todo list
[02:13] <kiko> hey salgado 
[02:13] <kiko> no review for me then
[02:14] <jamesh> Kinnison: first problem: put the exception in interfaces/gpghandler.py rather than utilities/gpghandler.py
[02:15] <mpt> hey kiko, no review for me either? :-)
[02:15] <kiko> mpt, I'll do it this morning, I was lost inside teammembership bugs
[02:15] <mpt> thanks
[02:15] <kiko> one of them is very big though
[02:16] <kiko> mpt, can you guide salgado into doing the right thing wrt shipit searching?
[02:16] <jamesh> Kinnison: other than that, it looks good.
[02:16] <mpt> yep, I'll have a look
[02:20] <niemeyer> ddaa: Do you store your own baz configs somewhere or should I just take the rocketfuel one and replace the launchpad branch with your branch?
[02:21] <ddaa> mh
[02:21] <ddaa> the latter should be good
[02:21] <ddaa> (if it's not, it's a bug)
[02:21] <ddaa> only importd integration testing requires special stuff
[02:25] <kiko> salgado, I will send you an updated patch with tests in a bit
[02:25] <kiko> salgado, will you review it?
[02:26] <ddaa> niemeyer: btw, do you know about "baz switch"?
[02:26] <niemeyer> ddaa: Yep
[02:26] <kiko> baz switch is the devil's work!
[02:27] <niemeyer> ddaa: Considering I have a revlib, why would it help me?
[02:27] <ddaa> kiko: then I think we have establish that the devil is lactose-intolerant :)
[02:28] <ddaa> niemeyer: its easier to switch launchpad, that keeps all your unversioned files and does not touch the nested trees
[02:29] <niemeyer> ddaa: Ah, understood. Wouldn't help me right now, given that the trees I'm downloading are pristine.
[02:30] <ddaa> are a rule, I prefer to use a single launchpad setup and switch trees around, I get easily confued otherwise (e.g. editing files in the wrong tree)
[02:30] <ddaa> but YMMV
[02:30] <kiko> if I keep a single tree I can't work
[02:32] <kiko> hey azeem 
[02:34] <ddaa> lifeless: mirorring importd-archivelocation--2 right now, without the unrelated stuff
[02:35] <azeem> hey
[02:35] <salgado> kiko, sure (sorry for the delay)
[02:41] <Kinnison> jamesh: okies, I'll put the exception there and merge, thanks dude
[02:42] <Kinnison> jamesh: although that means it'll be canonical.launchpad.interfaces.GPGVerificationError -- is that what you wanted?
[02:46] <niemeyer> Hummm..
[02:46] <niemeyer>     cur.execute(sql) # Will die on a bad patch.
[02:46] <niemeyer> psycopg.ProgrammingError: ERROR:  column "owner" contains null values
[02:46] <kiko> DIE
[02:46] <niemeyer> Yes, it's dead.. :)
[02:47] <ddaa> mh?
[02:47] <ddaa> is that something I need to worry about?
[02:48] <Kinnison> jamesh: sorry, if you said anything, I missed it. gnome-terminal went arse-over-tit
[02:48] <niemeyer> ddaa: Only if you want to..
[02:48] <ddaa> then I won't
[02:52] <Kinnison> hey keybuk
[02:52] <Keybuk> heyhey
[02:52] <Kinnison> SteveA: Do you agree with jamesh that the GPGVerificationError should be in canonical.launchpad.interfaces.gpghandler rather than canonical.launchpad.utilities.gpghandler ?
[02:52] <SteveA_> yes i do
[02:52] <Kinnison> okay, I'll do that
[02:52] <Kinnison> thanks
[02:52] <Kinnison> it seemed odd to me
[02:53] <SteveA_> anyone implementing the interface needs to be able to use the error
[02:53] <SteveA_> so the interface depends on the error class
[02:53] <Kinnison> right
[03:00] <niemeyer> ddaa: Branch sprint--0 is up and running..
[03:00] <ddaa> running?
[03:01] <ddaa> you mean belly-crawling, right?
[03:01] <cprov> SteveA: hi, do you have some time today for review "dapper-open" related changes ? 
[03:01] <niemeyer> ddaa: Heheh :)
[03:06] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: set language and text direction in translation forms.  Fixes bug #74, r=lifeless (patch-2620: james.henstridge@canonical.com)
[03:07] <SteveA_> cprov: yes, i will have
[03:10] <cprov> SteveA_: great, please, let me know when you are able to do it: 3 branches,  2nd pass builddUI, nominatedarchindep (small code and check spec language) and gzip-buildlog
[03:10] <cprov> SteveA_: thanks in advance.
[03:10] <Kinnison> SteveA_: I'm only punting cprov on stuff needed for dapper-open now, so it'd be nice if the review team were aware that anything cprov or I ask for is likely to be critical
[03:11] <SteveA_> Kinnison: okay
[03:11] <Kinnison> Also, mark will be landing a huge package UI overhaul at some point
[03:11] <Kinnison> that's kinda important too
[03:36] <cprov> stub: ping 
[03:36] <stub> cprov: pong
[03:36] <cprov> stub: didn't you approve my nominatedarchindep DB patch sometime last week ?
[03:36] <stub> yes
[03:37] <cprov> stub: PendingReviews says the opposite, may I repair it ? 
[03:37] <stub> yes please ;)
[03:37] <cprov> stub: will do, thank you ;)
[03:44] <Kinnison> I take it that GPGKey.owner == the literal owner, rather than some db object owner?
[03:45] <jamesh> cprov: did you mean to add the branches I just removed back to PendingReviews? :)
[03:45] <jamesh> Kinnison: it would be the database person who claimed the key
[03:46] <jamesh> Kinnison: (who would have proved their ownership by decrypting a mail sent to them)
[03:46] <Kinnison> cool, so it's exactly who I want
[03:46] <stub> Kinnison: As far as I'm aware, yes. Feel free to stick in a comment clarifying and confirming this
[03:46] <Kinnison> stub: if I have time
[03:46] <cprov> jamesh: sorry ? did you had the locks .. was using editmoin .. let's check
[03:48] <gneuman> SteveA
[03:50] <cprov> jamesh: ohh, sorry, I did the mess, will you repair or should I ?
[03:51] <bradb> BjornT: hey dude, just so you know: it doesn't look like anyone responded to your review request for PBR yet. I wasn't too anxious to nag anyone for it last week either, because I was plenty busy with my own patches, unfortunately.
[03:52] <jamesh> cprov: no problem.  I just redid the edit
[03:52] <cprov> jamesh: right, I apologize myself .. 
[04:00] <kiko> so before each standalone pagetest runs do we reset the database?
[04:05] <janimo> jblack, ping
[04:06] <SteveA_> bug 2946
[04:06] <Ubugtu> Malone bug #2946: System error when renaming a product to the same name of a existing product. Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: neuman, Status: New http://launchpad.net/malone/bugs/2946
[04:06] <SteveA_> bug 2908
[04:06] <Ubugtu> Malone bug #2908: Trying to insert or change a poll option with same name causes crash! Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/2908
[04:06] <SteveA_> Seveas: this rocks, man
[04:06] <kiko> matsubara, didn't you fix the second bug there, 2908?
[04:06] <gneuman> kiko
[04:06] <SteveA_> i'm talking with gneuman about them
[04:06] <gneuman> yep
[04:07] <carlos> stub, did you updated production already with latest code?
[04:07] <stub> carlos: yes
[04:07] <carlos> stub, ok, thank you
[04:07] <matsubara> nope, gneuman is fixing it
[04:07] <kiko> okay
[04:14] <BjornT> bradb: yeah, i saw that you were busy, landing a patch which conflicted with mine ;)
[04:17] <bradb> It is interesting to note though that, in the absense of nagging, the patch didn't get reviewed.
[04:17] <kiko> absence.
[04:17] <bradb> that too
[04:17] <bradb> my spell checker is set to fr right now, so every word's a spelling mistake :P
[04:23] <kiko> is there a trick with pagetests when it refuses to match on what you supply?
[04:23] <bradb> sometimes
[04:24] <kiko> it's hard to understand why it fails -- the mental model suggested is violated severely upon failure
[04:24] <sabdfl> salgado: ok, it's time for our first ubuntu vote
[04:24] <sabdfl> it's a vote for ubuntu-dev
[04:24] <sabdfl> how do i set it up?
[04:25] <salgado> sabdfl, in people/ubuntu-dev/+polls there should be a link to create a new poll
[04:28] <SteveA_> kiko: there's a fundamental problem in doctest
[04:28] <SteveA_> kiko: that is, there is totally separate code that does the checking and presents the output
[04:28] <kiko> SteveA_, tell me more about it -- I might just give up here.
[04:29] <kiko> I see.
[04:29] <SteveA_> kiko: so, if there are any discrepencies between the algorithms of each
[04:29] <SteveA_> you get problems
[04:29] <SteveA_> because part 1 fails the test, and part 2 gives you perfect output for example
[04:29] <SteveA_> the solution: make the same code paths do both jobs
[04:30] <kiko> SteveA_, or have a single codepath? :)
[04:30] <SteveA_> yeah
[04:31] <kiko> ok
[04:31] <kiko> meanwhile what should I do with a test that should succeed but fails?
[04:31] <stub> Kinnison: What happens if we don't run Gina today or this week?
[04:32] <Kinnison> If a gina run is not complete by Monday, we can't open dapper
[04:32] <SteveA_> kiko: send me the details for analysis, perhaps...
[04:32] <kiko> SteveA_, okay, good idea. I'll commit with these sections omitted and then send you the full file.
[04:32] <SteveA_> okay
[04:32] <kiko> SteveA_, think you can comment on my top-failures report now?
[04:32] <SteveA_> the last time we did this, it was really weird
[04:33] <SteveA_> because i couldn't reproduce it, and then later you couldn't either
[04:33] <SteveA_> kiko: did you mail it to the list?
[04:33] <stub> Kinnison: And that would be bad? (I'm not on the distro team remember - I'm not sure what the actual fallout is)
[04:33] <kiko> SteveA_, I thought I did -- it was a reply to your email
[04:33] <SteveA_> okay.  i can't get mail just at the moment
[04:33] <SteveA_> will be doing so shortly
[04:34] <Kinnison> stub: Very simply, the distro team are idle until dapper is open
[04:34] <Kinnison> stub: Do you block the entire team
[04:34] <Kinnison> s/Do/So/
[04:34] <stub> ok ;-)
[04:36] <kiko> SteveA_, yeah, but this time it's a stabler error
[04:37] <kiko> SteveA_, is the database reset every time you run a standalone pagetest?
[04:38] <SteveA_> it should be
[04:38] <SteveA_> if not, it's a bug
[04:38] <kiko> it is
[04:38] <SteveA_> although, all the standalone tests are in one story, i think
[04:38] <SteveA_> which is not ideal
[04:38] <SteveA_> althoughalthough i'm not sure
[04:42] <kiko> salgado, sent patches.
[04:43] <zyga> mpt: hi
[04:43] <kiko> cprov, can you grant me access to bug 1457 please?
[04:43] <Ubugtu> Error: I cannot access this bug
[04:47] <mpt> hi zyga
[04:47] <kiko> bradb, bug 3059
[04:47] <Ubugtu> Malone bug #3059: I am unable to view bug 1457 because targetname is not available to pagetitle. Fix req. for: malone (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/3059
[04:47] <mpt> wow, baz diff took 40 minutes
[04:47] <zyga> mpt: I was asking carlos about the possibility of chanigng layout of translation pages
[04:47] <mpt> zyga: in what way?
[04:48] <zyga> mpt: the idea is: move all the stuff from side columns into a box at the top of the page
[04:48] <mpt> sounds good so far
[04:48] <zyga> mpt: use full horizontal space available for translations
[04:48] <zyga> mpt: put msgid in one column
[04:48] <jamesh> mpt: hard linking the tree should speed that up (but can cause problems if you aren't using fl-cow)
[04:48] <zyga> mpt: put msgstr as a textarea in another column
[04:48] <mpt> jamesh: what's fl-cow?
[04:48] <jamesh> hard linking just the patch logs would probably speed things up without needing fl-cow though
[04:48] <zyga> this solves problems with longish msgid when it's hard to scroll back and forth to read both things
[04:49] <bradb> kiko: Thanks, I'll take the bug. I'll try to fix it today.
[04:49] <jamesh> mpt: a little shared library that implements "copy on write" links
[04:49] <mpt> zyga: where would the suggestions and translations from elsewhere go?
[04:49] <zyga> mpt: put suggestions beneath both items and provide a button that replaces current textarea content with suggestion
[04:49] <kiko> bradb, it stops me from doing part of my work :)
[04:49] <jamesh> mpt: so if a particular file has two file names, and you try to open it for editing, it breaks the link and copies the contents first
[04:49] <zyga> mpt: require confirmation if textarea has been modified
[04:49] <zyga> mpt: done :)
[04:50] <bradb> kiko: I can do it after I land the sortorder widget patch.
[04:50] <kiko> cool
[04:50] <kiko> bradb, any clue why it happens?
[04:50] <cprov> kiko: done, for 145[78] , check it out. 
[04:50] <kiko> thanks
[04:50] <cprov> kiko: no probs
[04:50] <mpt> zyga: what do you mean "beneath both items"? As in, spanning both columns?
[04:51] <zyga> mpt: exactly, yes
[04:51] <zyga> mpt: in ugly-table-speak that's
[04:51] <bradb> kiko: not entirely, but maybe
[04:51] <kiko> it's weird
<td colspan="2">suggestions and such</td></tr>
[04:51] <kiko> bradb, I've unsubscribed
[04:51] <bradb> kiko: might just be incorrect ZCML configuration. our ZCML config is currently, necessarily, fairly complicated for privacy
[04:51] <kiko> bradb, to make sure you can reproduce the issue
[04:52] <mpt> zyga: That would be a bit weird. But I agree, there should be more horizontal space and less vertical space for each item. I have a branch waiting for review that fixes that a little bit, and I'm hoping to work on it some more today
[04:53] <zyga> mpt: is there any way to test experimental branches of rosetta?
[04:54] <mpt> zyga: Not unless you're a Launchpad developer
[04:54] <zyga> mpt: too bad
[04:54] <mpt> or rather, not unless you're an *extremely patient* Launchpad developer
[04:54] <zyga> :D
[04:57] <zyga> mpt: I'm generally suggesting something that will be more less similar to kbabel/gtranslator that allow translators to focus on one message
[04:58] <sabdfl> oh, jesus, salgado!
[04:58] <sabdfl>     <h1 tal:content="context/proposition" />
[04:58] <sabdfl> VERY IMPRESSIVE PROPOSITION TEXT WE'VE GOT THERE :-)
[04:58] <sabdfl> https://launchpad.net/people/ubuntu-dev/+poll/tb-nomination-mjg59-2005
[04:58] <sabdfl> i'll fix the page and the portlets
[05:02] <ddaa> stub: ping
[05:02] <stub> ddaa: pong
[05:02] <ddaa> regarding your XXX
[05:03] <ddaa> you say: "We are getting NULL names!", I did not find anything in the production db that would cause null names to occur
[05:03] <sabdfl> salgado: where is the sampledata url to find a proposition?
[05:03] <stub> ddaa: We do on the sample data. If we don't have to worry about production, the XXX can go and the constraint reenabled.
[05:04] <salgado> sabdfl, ooops. I guess me and mpt haven't thought there would be a proposition that big. :)
[05:04] <ddaa> you say: "Confirm this is OK!" (setting manifestentry.changeset to NULL and removing some foreign key constraints). On the production data, no update is needed as the changeset-foreignkey constraint are not exercised.
[05:05] <salgado> sabdfl, I don't understand your question. you want to find a proposition?
[05:05] <stub> ddaa: We have to drop the constraint, or we can't drop the columns that the constraint references.
[05:05] <ddaa> But I do not understand why you are dropping the manifestentry_branch_fk constraint. I guess that's because of the table renaming, so I can recreate that constraint after the table is changed.
[05:05] <sabdfl> salgado: yes, i am changing the page, and want to be able to view sampledata
[05:06] <ddaa> stub: right, but you do "update manifestentry set changeset=NULL" that's noop on the current data. I'd be adept at putting an "assert" sort of thing here to be sure we can drop changeset.branch without invalidating anything.
[05:07] <sabdfl> salgado: don't touch those pages, please, or we will conflict
[05:07] <stub> ddaa: ok. I only tested it against the sample data.
[05:07] <salgado> sabdfl, oh, you want to know for what teams we have polls? if so, they're all registered for the name17 team
[05:07] <kiko> sabdfl, gneuman already has patches on testing those pages..
[05:07] <salgado> http://localhost:8086/people/name17/+polls
[05:07] <mpt> salgado: Don't blame me for this, https://wiki.launchpad.canonical.com/BasicVoting#head-d7a83410dc7aa45df274ce536fe3c374cc370159 shows quite clearly that the proposition text is in normal font while the poll name is a heading
[05:07] <ddaa> stub: okay, I imagine in this area, theory is significantly different from reality. I'll be fixing the sampledata somehow in my branch today.
[05:07] <kiko> mpt, share the blame, you should have QA'd the result.
[05:08] <sabdfl> guys, this UI is terrible. here are some comments
[05:08] <mpt> true, I never looked at it
[05:08] <kiko> sabdfl, via email?
[05:08] <ddaa> niemeyer will help me with fixing anything causes hct go bonkers
[05:08] <sabdfl>  - the proposition is a long piece of text. the title is a header. use them that way
[05:08] <sabdfl> kiko: no, here, and now, you guys can turn them into email
[05:08] <sabdfl> and don't touch those pages till my changes land please
[05:08] <sabdfl> i'm rearranging the layout of the PT and don't want conflicts EVERYWHERE
[05:09] <ddaa> stub: thanks for your prompt help, I hope we can get niemeyer unblocked by tonight :)
[05:09] <stub> ddaa: revoking the manifestentry_branch_fk constraint might have been a mistake. Comment it out, and if it runs, keep it that way.
[05:10] <ddaa> stub: ack
[05:10] <sabdfl> so, the terminology of "options" is poor
[05:10] <sabdfl> what's a name, then a "short name"?
[05:11] <sabdfl> why is the "show all options" item a separate page? why not just have that on the core page?
[05:11] <sabdfl> why is there no ability to edit the poll and proposition?
[05:11] <sabdfl> at least, before voting starts
[05:11] <kiko> there actually is a poll/+edit
[05:11] <kiko> it's currently untested and broken, which is why gneuman had written tests
[05:12] <stub> Kinnison: would it be fair to run {warty,hoary,breezy} once a week and {*-updates,*-security} daily?
[05:13] <salgado> the "Show all options" should be labeled "Edit options", as the options are already listed in the main page. my fault
[05:13] <Kinnison> once we've released breezy, you only want to run warty,hoary,breezy once
[05:13] <Kinnison> since they don't change
[05:13] <sabdfl> salgado: except that they are BADLY listed
[05:14] <Kinnison> and just take *AGES*
[05:14] <sabdfl> only the name is listed
[05:14] <sabdfl> the option should have a name and title
[05:14] <Kinnison> We want to run -updates and -security regularly. Perhaps even once per hour
[05:14] <sabdfl> for heavens sake, everything else uses that convention, why does this not?
[05:14] <Kinnison> or we may only want to run them on-demand
[05:14] <Kinnison> best to ask pitti and elmo about that
[05:14] <sabdfl> why is the proposition in the details portlet?
[05:14] <sabdfl> why does the details portlet not have the date ending of the vote?
[05:15] <salgado> because it hasn't opened yet
[05:15] <sabdfl> that's dumb - somebody looking at it needs to know when it opens, and when it closes
[05:17] <salgado> I did that because in the list of polls for a team, the mockup only display the close dates of polls that are already open
[05:17] <sabdfl> that's equally dumb
[05:17] <sabdfl> guys, don't get too fancy with sometimes displaying one bit, sometimes another bit of information
[05:17] <sabdfl> keep it simple
[05:19] <sabdfl> kiko: /+edit is indeed borken
[05:19] <sabdfl> so, i take it there is no page test
 there actually is a poll/+edit
 it's currently untested and broken, which is why gneuman had written tests
[05:19] <sabdfl> mpt: did you read the above?
[05:19] <kiko> I was in the process of merging these tests now, but I've given up
[05:20] <sabdfl> will the POLL even work?
[05:20] <salgado> yes, I do have a lot of tests for that
[05:22] <mpt> sabdfl: yes, I need to add the closing date to not-yet-open polls, and then go through the rest of the pages to make them match the spec
[05:23] <mpt> I hadn't looked at them yet, and should have
[05:24] <sabdfl> mpt: ok. don't look at them till my stuff lands, ok? or look at them, make notes, but don't change till it lands
[05:24] <sabdfl> thanks
[05:24] <mpt> sure, I won't get to it today anyway
[05:26] <sabdfl> salgado: which poll can i actually vote on in the sampledata to see those pages?
[05:28] <salgado> sabdfl, you should be able to vote on any open poll from http://localhost:8086/people/name17/+polls
[05:28] <salgado> (logged in as yourself)
[05:29] <sabdfl> salgado: err.. i don't know my sampledata login!
[05:29] <sabdfl> what's the password?
[05:29] <salgado> sabdfl, test
[05:29] <sabdfl> mark@hbd.com?
[05:29] <salgado> yep
[05:32] <sabdfl> salgado, mpt: all of the dancing around with showing the date of opening and closing differently depending on whether or not it is already open or clsed is CLASSIC waste of effort
[05:32] <sabdfl> i'm sorry guys, i'm being harsh, but we don't have time for that
[05:32] <sabdfl> there is so much to do, this should be straight:
[05:32] <sabdfl> Opens: date
[05:33] <sabdfl> Closes: date
[05:33] <sabdfl> DONE
[05:33] <sabdfl> instead we have 20 lines of TAL, which turns out to be broken for the initial case
[05:33] <sabdfl> please don't do that any more
[05:36] <sabdfl> mpt, salgado: please ack
[05:37] <salgado> sabdfl, sure. I very much prefer keeping it like you suggested, but I was following the spec
[05:37] <sabdfl> thanks. mpt?
[05:37] <mpt> sabdfl: yes, as I said above, that needs fixing
[05:38] <salgado> stub, what's "Oscar the grouch"?
[05:38] <sabdfl> mpt: no, the part i am asking you not to repeat is the <if open> closes in: </if open> <if closed>closed on: </of closed> nonsense
[05:38] <sabdfl> i know you like to do that stuff
[05:38] <sabdfl> but we don't have the time now
[05:39] <sabdfl> we are STILL trying to get a 1.0 out that is clean and consistent
[05:39] <stub> salgado: What you are suggesting, except other datamaintenance stuff can be plugged in. See OscarTheGrouch on the wiki
[05:39] <sabdfl> it takes hours and hours to get that polish right
[05:39] <sabdfl> we do not need it for 1.0
[05:39] <sabdfl> period
[05:40] <salgado> stub, should I add it as a use case there?
[05:41] <stub> salgado: I've  linked the spec to that bug and another one. If you have time to update the wiki page, sure. But the linkage is good enough for now.
[05:41] <salgado> stub, cool. thank you
[05:42] <mpt> sabdfl: That kind of stuff takes about 0.5% of my time, so not doing it isn't going to make a noticable difference (compared with, say, rf-on-bzr), but sure, I don't mind not doing it
[05:42] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  remove unnecessary and awkward text from proposed membership page (bug 3022), and clean up the form layout (patch-2621: mpt@canonical.com)
[05:47] <kiko> thanks jamesh 
[05:57] <sabdfl> mpt: ok, thank you
[06:01] <jordi> carlos: ping?
[06:01] <jordi> carlos: I don't seem to be able to upload that gnomebaker sr.po that was posted to rosetta-users
[06:02] <jordi> I seem to get a timeout
[06:08] <SteveA> stub: any concerns with gina runs causing request timeouts?
[06:09] <stub> SteveA: I can't remember how well behaved it is
[06:09] <SteveA> what tables does it update the most often?
[06:10] <stub> Hmmm.... looks like it will cause problems.
[06:11] <stub> I don't know what tables it updates
[06:11] <SteveA> so, not apparent from the security.cfg settings?
[06:12] <carlos> jordi, how big is it?
[06:12] <stub> nope.
[06:12] <ddaa> Keybuk: ping
[06:12] <Keybuk> ddaa: 'sup?
[06:13] <stub> Lookking at this, I think I need to kill it and make it commit much more often before trying another run tomorrow.
[06:13] <Kinnison> stub: gina can be told how often to commit
[06:15] <stub> Kinnison: Only by increasing the spam it produces because it is tied into the countdown option. I think I did that but thought it had been fixed.
[06:16] <Kinnison> how do I get it?
[06:16] <stub> Subsribe to the relevant topics in the launchpad-error-reports mailing list.
[06:17] <ddaa> Keybuk: There an issue with ManifestEntry
[06:17] <ddaa> it was using a foreign key constraint to Revision(id, branch)
[06:17] <ddaa> but now Revisions no longer have branches
[06:17] <ddaa> The same issue applies to ArchConfigEntry, BTW
[06:18] <Diablo-D3> hey
[06:18] <ddaa> Keybuk: any idea how to restore the constraint?
[06:18] <Kinnison> stub: who owns that list?
[06:18] <Diablo-D3> can I file bugs on launchpad using malone?
[06:18] <stub> I do
[06:18] <jordi> carlos: 20k
[06:18] <carlos> jordi, it makes no sense...
[06:18] <Kinnison> Diablo-D3: yes, visit https://launchpad.net/products/launchpad/+bugs
[06:18] <carlos> SteveA, stub ?
[06:18] <Keybuk> ddaa: is this change part of the landing of your namespace changes?
[06:18] <SteveA> hello carlos
[06:18] <Kinnison> stub: can you approve my subscription?
[06:19] <Keybuk> or was this just some random change someone made?
[06:19] <ddaa> Keybuk: that's part of the branchdatastorage mess, yes
[06:19] <jordi> carlos: worked now
[06:19] <carlos> SteveA, jordi got a timeout uploading a 20K file 
[06:19] <SteveA> just now?
[06:19] <jordi> carlos: I got it 4 times in a row
[06:19] <SteveA> perhaps gina is to blame
[06:19] <jordi> SteveA: 20 mins ago
[06:19] <stub> Gina is now dead
[06:19] <ddaa> Keybuk: the reasoning behind that is that revision can now be shared between branches, what a branch owns is a RevisionNumber
[06:19] <SteveA> jordi: try again
[06:19] <Keybuk> ddaa: if it's part of your "make the Arch* all look like baz-ng" changes; don't worry about it, because those bits of ManifestEntry have changed totally for the baz-ng version
[06:19] <stub> As of just a few minutes ago
[06:20] <jordi> carlos: what's the url for sr@Latin in launchpad?
[06:20] <Keybuk> when we land the baz-ng version of HCT, the problem will go away
[06:20] <ddaa> Keybuk: thanks, I shall promptly forget the issue
[06:20] <Diablo-D3> hrm
[06:20] <Kinnison> Diablo-D3: what problem are you having?
[06:20] <ddaa> Keybuk: what have we just been talking about by the way???
[06:20] <Diablo-D3> how do tag a bug as a feature request?
[06:20] <Keybuk> that's still waiting on lifeless to decide how to add bzrlib to launchpad
[06:20] <Keybuk> (as it's in a baz-ng branch, not a baz one)
[06:20] <jordi> carlos: ie, https://launchpad.net/products/gnomebaker/+series/main/+pots/gnomebaker/sr/+upload, but for a sr@Latn file
[06:21] <Diablo-D3> Kinnison: hey, you're everywhere!
[06:21] <ddaa> Keybuk: the problem also is that the sampledata is affected
[06:21] <carlos> jordi, we don't have yet a way to handle them directly, you will need to upload it as a tarball and I think you will need to upload also the .pot file or the tarball will be discarded (it's a limitation in our system, need to add full support for pofiles with variants in the name=
[06:21] <ddaa> Keybuk: so your test suite likely is affected
[06:21] <ddaa> so we need to know how to fix it, well, niemeyer needs to know :)
[06:21] <Keybuk> like I said, probably won't effect the bzr-ng version :p
[06:21] <Keybuk> that uses Branch + RevisionNumber
[06:22] <ddaa> RevisionNumber is transient
[06:22] <ddaa> and branch is fk'ed by revisionnumber
[06:22] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  expose can_{encrypt,sign,certify,authenticate} attributes on IPymeKey (patch-2622: james.henstridge@canonical.com)
[06:22] <jordi> carlos: oh. So how does rosetta handle a language with two encodings?
[06:22] <Keybuk> define "transient" ?
[06:22] <jordi> carlos: just upoading the "sr" file is not enough I assume?
[06:22] <Keybuk> RevisionNumber is a table that refers to a particular revision, right?
[06:22] <ddaa> i.e. I want to de able to delete all the revision numbers of a branch when updating it if I find that the branch was replaced with something with a completely different history
[06:22] <Keybuk> so when combined with Branch, it refers to a particular revision in a particular branch
[06:23] <Keybuk> do I mean Revision?
[06:23] <Keybuk> and not RevisionNumber?
[06:23] <Keybuk> I haven't the code on this machine, it's on the desktop
[06:23] <carlos> jordi, no, if you upload the sr@Latn.po inside a tarball using the .pot upload form, it will be imported to sr@Latn's po file
[06:23] <carlos> jordi, but we don't show it in our UI
[06:23] <Keybuk> it keys the one that's the uuid, not the "revno"
[06:23] <jordi> nod
[06:23] <ddaa> Revision is more reliable. But it's not really something you can checkout...
[06:23] <Keybuk> why not?
[06:24] <ddaa> the one with the uuid is Revision
[06:24] <ddaa> because you checkout a revision from a Branch
[06:24] <Keybuk> ok, so it pairs a Revision and Branch
[06:24] <jordi> carlos: I'm fetching a pot file
[06:24] <Keybuk> I knew it was something like that <g>
[06:24] <ddaa> What you _can_ checkout is RevisionNumber, but it's not reliable.
[06:25] <Keybuk> why can't I check out a Branch/Revision pair?
[06:25] <Keybuk> Revision has the uuid, and Branch has the accessor for the URL
[06:25] <ddaa> Because you have no guarantee that the branch that used to contain that revision contains it now.
[06:25] <Keybuk> that's what the contstraint is for
[06:25] <Keybuk> (there's an equivalent constraint in the new table)
[06:25] <ddaa> The constraint is trouble for me.
[06:25] <Keybuk> that's your problem :p
[06:26] <ddaa> No, that's our problem.
[06:26] <Keybuk> you can't break existing Manifests
[06:26] <Keybuk> you can update them to refer to the new details, but you can't take away the history that was there
[06:26] <ddaa> There's nothing in existing manifests that references a changeset (aka. revision in the new schema)
[06:26] <Keybuk> "sorry, you can no longer checkout foo 1.0" is not a viable answer
[06:26] <Keybuk> huh?  all of them do
[06:26] <Keybuk> the sampledata is just screwy
[06:26] <ddaa> Keybuk: if you want to checkout a given uuid you need to ask the supermirror to save them for you.
[06:26] <Keybuk> all ManifestEntry currently reference both branch+changeset
[06:27] <ddaa> not in the production database
[06:27] <Keybuk> there's no Manifests in the production database
[06:27] <Keybuk> (at least there shouldn't be)
[06:27] <Keybuk> because we've not imported anything into the production syste,
[06:27] <ddaa> there is some netapplet stuff
[06:27] <Keybuk> that's bogus sampledata that shouldn't be there
[06:27] <ddaa> so we have a problem
[06:28] <ddaa> my constraint is
[06:28] <SteveA> carlos, jordi: did it work?
[06:28] <Keybuk> launchpad_hct=> select count(*) from manifestentry where branch is not null and changeset is null;
[06:28] <Keybuk>      0
[06:28] <Keybuk> launchpad_hct=> select count(*) from manifestentry where branch is not null and changeset is not null;
[06:28] <Keybuk>   5139
[06:29] <ddaa> "When taxiing a third party branch, the branch (url) may have been replaced by something with completely different history, so I need to be able to remove all the revisionnumbers"
[06:29] <Keybuk> no, you need to just create new Branch records
[06:29] <Keybuk> DELETE is verboten
[06:29] <Keybuk> if the URL contains a different branch, it's a different Branch
[06:29] <jordi> SteveA: the upload? I'm waiting for my token
[06:29] <Keybuk> the supermirror should contain both branches, one for historic interest, the other for current interest
[06:30] <jordi> I need a pot file to upload po files
[06:30] <ddaa> I cannot create a new branch record. A branch record for an outside branch is something that is registered by the user in launchpad.
[06:30] <Keybuk> if there is a Manifest depending on information in that Branch, they can't delete it
[06:30] <jordi> ah, here it is
[06:30] <Keybuk> because there may be developers doing work based on it
[06:30] <ddaa> Keybuk: I think understand what you want, but it's NOT the data model we defined in London.
[06:30] <Keybuk> then your data model is wrong, and we'll need to fix it
[06:30] <Keybuk> sadly I wasn't there that week
[06:31] <Keybuk> HCT is the principal and primary user of Branch/Revision records
[06:31] <ddaa> currently yes
[06:31] <Keybuk> we wouldn't even have them in the database if HCT wasn't using them
[06:31] <ddaa> when the sprint stuff is landed, branches and revision will be used by launchpad webapp
[06:31] <Keybuk> only because of HCT
[06:32] <ddaa> for display purpose and to generate all sorts of interesting stats
[06:32] <Keybuk> you cannot delete historic data that 
[06:32] <Keybuk> is in use
[06:32] <ddaa> The user can.
[06:32] <Keybuk> it must be preserved
[06:32] <Keybuk> sure, they can on their machine
[06:32] <Keybuk> but in our system, it must be preserved
[06:32] <ddaa> It must certainly be preserved.
[06:32] <Keybuk> if it's referenced by a Manifest, it's in a source package or tarball that's in the wild
[06:33] <Keybuk> so you can't drop it from the database
[06:33] <Keybuk> or the super-mirror, for that matter
[06:33] <ddaa> Agreed.
[06:33] <ddaa> I suppose so.
[06:33] <Keybuk> so if you find a different branch history at the URL to last time, you should treat it as a different branch and just add new records
[06:34] <Keybuk> you can alter the URL for the branch to point to something like /+historic/joebloggs/DATE or something
[06:34] <Keybuk> (old branch, that is)
[06:34] <ddaa> Keybuk: do you understand what is my problem?
[06:34] <Keybuk> yes
[06:34] <Keybuk> I think so, anyway
[06:34] <ddaa> So, the situation is that niemeyer is blocked on the schema being stabilised.
[06:34] <Keybuk> we pull from a third-party branch, at a given URL
[06:34] <ddaa> And I'm hard pressed for doing python imports.
[06:34] <Keybuk> and today we discover the branch there has nothing to do with what was there (and recorded in the db) yesterday
[06:35] <Keybuk> is that about right?
[06:35] <ddaa> Right.
[06:35] <Keybuk> so when that happens, I suggest that we rename the URL for the old Branch (still keeping it on the supermirror) and import the new branch as a new branch
[06:35] <Keybuk> that way we have both the historic user's branch on the mirror, and the current state
[06:35] <ddaa> So I'd like you to discuss the issue with lifeless, I'll publish the current state of by db work in a matter of minutes, and come with a resolution.
[06:36] <Keybuk> which actually is a cool service, when the user discovers they rsync'd over the top of the wrong branch and lost it, they can reclaim it from our mirror
[06:36] <ddaa> That would be nice.
[06:36] <Keybuk> and then you won't break the ME constraint, because the old Branch and Revision records will still be there -- just the url of the old Branch will have changed to something else
[06:37] <SteveA> ddaa: the object you get to at $person/+branch/+junk/whatever is an IBranch ?
[06:37] <ddaa> I would just like you to work with lifeless to change the model we designed in london so you are happy. So the schema is essentially stable and niemeyer can start working. And so I can work on the python import instead of bouncing between you and lifeless.
[06:37] <ddaa> Keybuk: do we have a deal?
[06:37] <SteveA> ddaa: and if so, is the IBranch.owner the $person ?
[06:38] <ddaa> SteveA: first question: yes
[06:38] <ddaa> SteveA: second question... mh... the $person will be the IBranch.author if it's not None or the IBranch.owner.
[06:39] <SteveA> it will be IBranch.author, unless .author is None, in which case .owner ?
[06:39] <ddaa> I need to check, actually...
[06:39] <Keybuk> ddaa: the model in London (db schema wise) was fine
[06:40] <ddaa> Keybuk: obviously, it's not
[06:40] <Keybuk> I think you misunderstand me
[06:40] <Keybuk> the database model, as in the SQL, is fine
[06:40] <Keybuk> you have an assumed usage model, which may not be
[06:40] <ddaa> My assumed usage model is backed by launchpad webapp code.
[06:41] <ddaa> I understand you want a layer of indirection.
[06:41] <ddaa> Between the user-visible url and the actual branch
[06:41] <ddaa> but it's not there
[06:41] <Keybuk> do I?
[06:41] <Keybuk> I don't think I do
[06:42] <Keybuk> because I need the URL too
[06:42] <Keybuk> so they need to be different for different Branches
[06:42] <ddaa> you want a branch (the thing that is registered, subscribed to, commented on by a user in launchpad) to refer to multiple history lines, with only one which is current
[06:43] <ddaa> stuff that needs to checkout specific revision needs to handle history lines
[06:44] <ddaa> but the stuff that lives in the webapp must not go away because the branch owner backed out some revisions
[06:45] <Keybuk> no I don't
[06:45] <Keybuk> I want multiple history lines to have different Branch objects
[06:45] <Keybuk> much simpler that way
[06:45] <Keybuk> the user than just sees multiple branches for them
[06:46] <ddaa> Registry needs an object that is stable even if the branch owner backs out some history
[06:46] <Keybuk> there's meta-data in the object, so you can make it say "here's the branch we mirrored yesterday before you stamped over the top of it" or whatever
[06:46] <Keybuk> why?
[06:46] <Keybuk> why just one?
[06:46] <Keybuk> make person->branch 1-to-many
[06:46] <Keybuk> because I can't think of a single thing I just have one branch for
[06:46] <ddaa> that's already covered
[06:47] <ddaa> it's $person/$product/$branch-name
[06:47] <ddaa> the issue is that branch-name may refer to incompatible histories at different points in time
[06:47] <Keybuk> why?
[06:48] <Keybuk> if you have multiple Branches, you can have a different branch-name for each
[06:48] <ddaa> the branch name is specified by the user on registration
[06:48] <Keybuk> so when you "import over the top" you create a new Branch record, and rename the old one
[06:48] <Keybuk> it can also be specified by your automatic system
[06:48] <Keybuk> old_branch.name = old_branch.name + "-pre-" + date
[06:49] <ddaa> this stuff is _not_ interesting to show in launchpad
[06:49] <ddaa> at least not right now
[06:49] <ddaa> it's a different feature
[06:49] <SteveA> ddaa: https://chinstrap.ubuntu.com/~dsilvers/paste/fileUJXuWj.html   untested.  that's the basic idea.
[06:50] <Keybuk> IF when importing a new branch, you discover that the history doesn't match that already recorded
[06:50] <Keybuk> 1) rename the old branch, and adjust any meta-data to indicate that it's historic
[06:50] <Keybuk> 2) add a new Branch record with the appropriate data
[06:50] <Keybuk> 3) import new Revision etc. onto the new Branch
[06:51] <Keybuk> you have a branch_status field in your table, that could get a HISTORIC schema entry
[06:51] <SteveA> bug 3053 please, ubugtu
[06:51] <Ubugtu> Error: 'please' is not a valid bug id.
[06:51] <Ubugtu> Error: I cannot access this bug
[06:51] <SteveA> bug 3053, ubugtu
[06:51] <Ubugtu> (bug <abbreviation> <number>) -- Look up bug <number> in the bugzilla associated with <abbreviation>.
[06:51] <Ubugtu> Error: I cannot access this bug
[06:52] <SteveA> bug 3053
[06:52] <Ubugtu> Error: I cannot access this bug
[06:52] <Keybuk> bug ubuntu 3053
[06:52] <Ubugtu> Ubuntu Bugzilla bug #3053: console-terminus package is not in the Ubuntu CD Product: Ubuntu, Component: debian-cd, Severity: major, Assigned to: cjwatson@ubuntu.com, Status: RESOLVED, Resolution: FIXED http://bugzilla.ubuntu.com/show_bug.cgi?id=3053
[06:52] <Keybuk> bug malone 3053
[06:52] <Ubugtu> Error: I cannot access this bug
[06:52] <Keybuk> *shrug*
[06:52] <Keybuk> something like that
[06:52] <SteveA> bradb: i'm getting an errer https://launchpad.net/products/rosetta/+bug/3053
[06:52] <Ubugtu> Error: I cannot access this bug
[06:53] <Keybuk> and bradb, your bot appears to be replying to anything with bug 1234 in the text :p
[06:53] <Ubugtu> Error: I cannot access this bug
[06:54] <bradb> SteveA: kiko reported the bug and I took it
[06:57] <sabdfl> carlos: do you have a handle on the issues in "Translations (some/all?) weren't updated in 20051010?"?
[06:58] <carlos> sabdfl, I was a bit busy with language packs and talking with pitti so I started with that but had to leave to be concentrated with language packs in general
[06:59] <sabdfl> carlos: ok, could you give me a status update before you wrap up today?
[06:59] <carlos> sabdfl, I will not leave today until all know issues are fixed unless I'm really unlucky...
[06:59] <carlos> so yes, I will give you an update
[06:59] <sabdfl> :-)
[07:00] <sabdfl> i'll be here
[07:00] <carlos> ok
[07:00] <sabdfl> is anybody else having trouble adding files to the librarian?
[07:01] <sabdfl> canonical.librarian.storage.DuplicateFileIDError: 37
[07:01] <sabdfl> ring a bell for anybody?
[07:01] <sabdfl> no way its a duplicate file
[07:01] <carlos> sabdfl, I have seen that error
[07:02] <Kinnison> sabdfl: are you uploading to a database, with a librarian root which is not clean?
[07:02] <carlos> kiko-fud, isn't it the error you got some days ago?
[07:02] <sabdfl> i don't know... Kinnison, how do i tell?
[07:03] <SteveA> carlos: are you going to need more code review today?
[07:03] <dda1> Gah... network failure
[07:03] <carlos> If you think the update I sent you is ready to be merged, nothing more
[07:04] <SteveA> with changes after our discussion, it is fine
[07:04] <carlos> SteveA, the other changes are not urgent and will take a bit more to be ready
[07:04] <SteveA> ok
[07:04] <carlos> but should be ready today so I will submit another review
[07:04] <SteveA> kiko-fud: where's that branch for me to debug?
[07:04] <carlos> request
[07:04] <carlos> SteveA, thank you
[07:06] <ddaa> airport routers are crap
[07:06] <ddaa> shiny pretty crap
[07:07] <SteveA> ddaa: did you look at the branch traversal stuff?  do you get what is going on there?
[07:09] <sabdfl> Kinnison: how do i know if the librarian root is "not clean"?
[07:09] <ddaa> SteveA: looking
[07:10] <sabdfl> spiv: ^? help
[07:11] <kiko-fud> SteveA, still merging fixes :-)
[07:11] <ddaa> SteveA: actually I was lying, the person in the canonical url is the owner, as the branch.zcml showed
[07:11] <SteveA> sabdfl: try rm -rf /var/tmp/fatsam*
[07:12] <SteveA> ddaa: okay.  well, you'll know what to do.
[07:12] <SteveA> you can also leave the canonical url defined as in the zcml, if it is that simple.
[07:12] <ddaa> SteveA: okay...
[07:13] <ddaa> I'm not sure what the "path" and "inside" properties in BranchUrlData are about.
[07:13] <kiko> sabdfl, btw, matsubara has a question for you
[07:13] <sabdfl> SteveA: it worked
[07:13] <sabdfl> matsubara: fire away
[07:13] <SteveA> any canonical url has a section of the path, and an object that is relative to
[07:13] <SteveA> sabdfl: maybe you had some test run that failed catastrophically eariler
[07:13] <ddaa> okay, I understand
[07:14] <matsubara> i send it on private
[07:14] <matsubara> Hello sabdfl, I'm having a problem with bug #2895, which two distinct product series have a release with the same name each. At the Product Overview, the releases links, points to the same place: /products/openkore/1.6.3 which causes a system error.  Do you know how the traversal should be in this case?
[07:14] <Ubugtu> Malone bug #2895: Releases with the same directory name causes an error Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Diogo Matsubara, Status: New http://launchpad.net/malone/bugs/2895
[07:14] <ddaa> SteveA: thanks a lot
[07:15] <sabdfl> SteveA: thanks v much ;-)
[07:15] <SteveA> depending when you land this, there will also be breadcrumbs and other url-definition changes to consider.  but we can get to them later. 
[07:16] <kiko> sabdfl, do you know if traversal for releasies should be done under +series?
[07:19] <sabdfl> kiko: there used to be a unique (product, version) on productrelease
[07:19] <sabdfl> so a release number was uniq
[07:19] <sabdfl> and therefor traversal should work
[07:19] <kiko> that explains the traversal
[07:19] <sabdfl> it looks like we will just have to go product/series/release
[07:19] <kiko> this constraint doesn't seem to exist
[07:19] <kiko> I see
[07:19] <sabdfl> no, it's been dropped
[07:19] <kiko> I asked stub to add a constraint for releases being unique in series now
[07:19] <kiko> so that's explained
[07:19] <sabdfl> so /products/mozilla/1.7/1.7.5 is going to have to be it
[07:20] <kiko> drop the +series?
[07:20] <kiko> there's currently a +series in the URL
[07:20] <sabdfl> its pointless if its always required
[07:20] <kiko> do you know why the constraint was dropped?
[07:20] <kiko> did it break in some real-world situation?
[07:20] <sabdfl> the only reason to have a +foo is if you have a default traversal to X, and you want to jump to foo's instead
[07:21] <sabdfl> i think when we made productseries NOT NULL, product was dropped from productrelease
[07:21] <kiko> I'd find it very confusing to have two FF 1.7.0 releases, one from each series
[07:21] <sabdfl> and so the constraint was dropped
[07:21] <sabdfl> it's a bug, so its allowed to be confusing
[07:22] <kiko> lol
[07:22] <kiko> should we just readd the constraint, then?
[07:22] <SteveA> it should be clear from looking at the Navigation class if there is a default traversal
[07:22] <SteveA> it will have a traverse() method, or derive from GetitemNavigation
[07:25] <carlos> so, is gina being running on production??
[07:25] <SteveA> not this second
[07:25] <kiko> soon
[07:25] <SteveA> are you seeing timeouts?
[07:28] <carlos> kiko, wasn't stub's email the confirmation that it's running?
[07:28] <SteveA> it was running
[07:28] <SteveA> and then we had a discussion about whether its running would cause requests to timeout
[07:28] <SteveA> and stu realized it would
[07:28] <SteveA> so he's going to fix that
[07:28] <SteveA> then it will run again
[07:29] <Diablo-D3> subscription to projects feature request: https://launchpad.net/products/launchpad/+bug/3067
[07:30] <Ubugtu> Malone bug #3067: "Soft" Subscription to Projects Fix req. for: launchpad (upstream), Severity: Wishlist, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/3067
[07:30] <Diablo-D3> er, woah
[07:30] <Diablo-D3> a malone bug bot
[07:30] <SteveA> mpt: ping
[07:30] <carlos> ok
[07:30] <Diablo-D3> where can I buy one of these?
[07:31] <SteveA> mpt: i have a question about the breadcrumbs.  actually, i have two questions.
[07:31] <kiko> Diablo-D3, Seveas will sell you one for a mere U$19.95
[07:32] <Diablo-D3> lol
[07:32] <SteveA> mpt: the first is, the spec says a breadcrumb has text.  does it also have a summary tooltip?  an icon?  a specific target other than the default page for that thing?
[07:33] <SteveA> mpt: the second question is, will you ever want to include markup within a breadcrumb, like we needed to with menu link titles?
[07:33] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  disable warning (patch-2623: stuart.bishop@canonical.com)
[07:34] <kiko> sabdfl, should we just add the constraint back?
[07:38] <SteveA> cprov: those reviews you want me to do... are they on the pending-reviews page?
[07:40] <mpt> mpt: I'm pretty sure the answers to your questions are all "no"
[07:41] <kiko> he meant SteveA 
[07:41] <mpt> er yes, SteveA
[07:41] <SteveA> cool
[07:42] <SteveA> this makes the API very simple
[07:43] <Kinnison> mpt: Your tab-completion fingers are more screwwy than zsh
[07:43] <kiko> we'll just have to forgive him this once Kinnison 
[07:44] <Diablo-D3> anonymous never forgives!... er, wait, wrong channel
[07:47] <mpt> hum
[07:48] <mpt> jamesh: A person's calendar isn't handled in person.zcml, so I can't just chuck the person details portlet in there to be consistent with the other person facets. Can you fix that?
[07:59] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: r=kiko Fix for bug 965: Homepage url without http:// breaks. Fixes validator to raise a proper error message, and adds validator and tests for URL-type fields. Patch by Diogo Matsubara <matsubara@async.com.br> (patch-2624: matsubara@async.com.br, christian.reis@canonical.com)
[08:19] <sabdfl> kiko: i don't think we can add the constraint now we don't have a product field in productrelease
[08:19] <sabdfl> not easily, but stub may know
[08:20] <sabdfl> so, yes, if stub can do it without invoking triggers :-)
[08:20] <kiko> sabdfl, are triggers bad? :)
[08:20] <sabdfl> kiko: GUNS dude, GUNS
[08:22] <kiko> hmmm. I think it should be possible. matsubara, can you email stub now and ask if it's possible to add/change the constraint?
[08:27] <sabdfl> does anybody here have RO access to production db?
[08:27] <kiko> yes
[08:27] <kiko> me
[08:27] <sabdfl> https://launchpad.net/people/ubuntu-dev/+poll/tb-nomination-mjg59-2005/
[08:27] <kiko> SteveA does too AFAIK
[08:27] <sabdfl> can you tell me what date that closes?
[08:28] <kiko> I can try
[08:31] <kiko> sabdfl, my emperor access hasn't been finalized, I see
[08:31] <kiko> psql -h emperor launchpad_prod
[08:31] <kiko> psql: FATAL:  IDENT authentication failed for user "kiko"
[08:32] <kiko> SteveA?
[08:33] <SteveA> i have access to the production servers on gangotri
[08:33] <kiko> but not to launchpad_prod?
[08:33] <SteveA> that gives me indirect access to emperor's database, but i'd rather not use it
[08:33] <kiko> does it?
[08:33] <SteveA> it must do
[08:33] <kiko> hmmm
[08:33] <SteveA> i have access as the user that runs the production launchpads
[08:33] <kiko> I asked for ro access
[08:33] <kiko> oh
[08:33] <kiko> I see
[08:33] <SteveA> but, it's a hack
[08:33] <SteveA> i don't intend to use it
[08:34] <SteveA> i have no "legitimate" access to the databases
[08:36] <Seveas> launchpad auto-generated bad wikinames for my team (dutchteam) and I cannot change them...
[08:42] <\sh> sabdfl: the text on the voting page is a bit too big ;)
[08:47] <salgado> kiko, the patch in https://chinstrap.warthogs.hbd.com/~jamesh/pending-reviews/guilherme.salgado@canonical.com/launchpad--shipit-searching--0/filtered-diff has both request pages merged, as you suggested
[08:47] <SteveA> mpt: ping
[08:47] <mpt> SteveA: pong
[08:47] <SteveA> hi
[08:47] <SteveA> so, in the hierarchy spec, you have 
[08:47] <SteveA> #
[08:47] <SteveA>     *
[08:47] <SteveA>       Launchpad > People
[08:48] <SteveA> #
[08:48] <SteveA>  /people
[08:48] <SteveA>     *
[08:48] <SteveA>       Launchpad > People
[08:48] <SteveA> rather
[08:48] <SteveA> at /people we have an IPersonSet content object
[08:48] <SteveA> this object has no facet menu of its own registered
[08:48] <SteveA> it uses the ILaunchpadRoot facet menu
[08:48] <SteveA> as you can see by going to the URL /people, and seeing where the facet menu links go
[08:49] <SteveA> so, its breadcrumb is not displayed
[08:49] <SteveA> i propose a different rule for displaying breadcrumbs
[08:49] <SteveA> that is, the breadcrumb is displayed if it is defined
[08:49] <SteveA> that way, people can define them for those things where it should be defined
[08:49] <SteveA> and not define them for things where it shouldn't
[08:50] <SteveA> if these happen to coincide with where facet menus are registered, then all the better
[08:50] <SteveA> do you think that is okay?
[08:51] <RWG> I open up X-Chat, almose every channel I join someone says my name
[08:52] <salgado> kiko, what are these changes you did in the main template for?
[08:54] <kiko> salgado, just deindenting
[09:05] <mpt> oops, sorry
[09:05] <mpt> SteveA: that sounds fine
[09:06] <SteveA> okay, great
[09:06] <SteveA> one more problem...
[09:06] <SteveA>  /distros/ubuntu/hoary/+sources    Launchpad > Distributions > Ubuntu > 5.04 > Packages
[09:07] <SteveA> mpt: the problem here is that +sources isn't an object at all
[09:07] <SteveA> or, if it is, it won't be in the future
[09:07] <SteveA> hmm, it's a SourcePackageSet now, which is really a SubSet
[09:08] <SteveA> but it should become just a stepthrough('+sources') traversal, with a page registered, or a redirect or something
[09:08] <SteveA> so...
[09:08] <SteveA> i guess we need special breadcrumbs for stepthrough urls sometimes.
[09:08] <SteveA> although, this would seem to go against what sabdfl said about URLs in brazil
[09:09] <mpt> +sources should be a page providing list/search for source packages, right?
[09:09] <SteveA> yes
[09:09] <SteveA> well
[09:09] <SteveA> yes
[09:09] <SteveA> and +source/  would be used as the stepthrough namespace for traversing to source packages
[09:09] <carlos> SteveA, what's exactly the 'marker' you talk about in your review?
[09:10] <carlos> because the _marker variable is just an empty list that is used to compare other variables
[09:10] <SteveA> carlos: it is typically a unique object that is used as a default value when you make a method call
[09:10] <mpt> SteveA: that's unfortunate, but it doesn't alter what the breadcrumbs should be
[09:10] <mpt> SteveA: they should be "Packages" for both
[09:10] <carlos> SteveA, hmm ok, it fits the definition
[09:10] <SteveA> carlos: it is used so that you can detect None coming back from a method call.
[09:11] <SteveA> carlos: so, marker = object()  is the best thing to use for this.
[09:11] <carlos> ok
[09:11] <carlos> it's used inside a class, so I suppose is better if I move it inside that class instead of being global for all the file, right?
[09:12] <SteveA> mpt: so, for http://localhost:8086/distros/ubuntu/hoary/+sources  we should have Launchpad >> Distributions >> Ubuntu >> 5.04 >> Packages
[09:12] <kiko-afk> okay, need to skip out, catch you all later
[09:12] <SteveA> mpt: so, for http://localhost:8086/distros/ubuntu/hoary/+source/evolution  we should have Launchpad >> Distributions >> Ubuntu >> 5.04 >> Packages
[09:12] <SteveA> in the first case, "Packages" links to /distros/ubuntu/hoary/+sources
[09:13] <SteveA> in the second case, "Packages" links to /distros/ubuntu/hoary/+source, which redirects to +sources
[09:13] <mpt> yes
[09:13] <SteveA> this is a pain in the arse ;-)
[09:13] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Removes useless hints (bug 1244), and fixes remaining hints, from calendar forms. Also fixes Launchpad-wide 'An error occured' message. (patch-2625: mpt@canonical.com)
[09:13] <mpt> er, hang on
[09:13] <SteveA> (right now, today, both are +sources, btw)
[09:13] <mpt> http://localhost:8086/distros/ubuntu/hoary/+source/evolution should be Launchpad >> Distributions >> Ubuntu >> 5.04 >> Packages >> evolution
[09:14] <SteveA> okay
[09:14] <SteveA> that is a minor point
[09:14] <SteveA> i need to think how to make this work
[09:14] <kiko-afk> SteveA, can you convince perhaps sabdfl to revoke the instruction to do +source/+sources?
[09:15] <mpt> SteveA: Well, you could persuade Mark to stop ... yes, what kiko-afk said
[09:15] <kiko-afk> it's a lot of complexity for a trivial detail that nobody will appreciate
[09:15] <kiko-afk> it's causing us already 404s in breadcrumbs 
[09:15] <SteveA> that makes no difference to it
[09:15] <SteveA> the main issue is that +source / +sources isn't going to be a content object
[09:15] <mpt> switching between singular and plural might be grammatically correct, but it's bad UI for URL-hackers
[09:15] <SteveA> so it doesn't have its own 'navigation' component
[09:15] <kiko-afk> it's a sourcepackage set
[09:15] <kiko-afk> whatever that means :)
[09:15] <SteveA> it won't be soon
[09:15] <kiko-afk> or subset even
[09:16] <SteveA> right, it is a notional sourcepackage subset
[09:16] <SteveA> but it will soon be nothing at all
[09:16] <SteveA> but a path step
[09:16] <SteveA> to disambiguate what follows
[09:16] <SteveA> i'll think about it
[09:17] <kiko-afk> thanks
[09:17] <SteveA> there will be a solution
[09:17] <SteveA> it will just make the breadcrumbs system more complex
[09:17] <kiko-afk> you sould like an acheiver
[09:19] <SteveA> hmm, time to go home
[09:19] <SteveA> if you need something, ping now!
[09:26] <SteveA> (on the whiteboard, at least)
[09:26] <SteveA> this is interesting.  thinking about this problem has made me think of a change that makes the display of breadcrumbs much simpler.
[09:26] <SteveA> and architectural change.
[09:26] <SteveA> nice.
[09:29] <sabdfl> kiko-afk: +source?
[09:33] <SteveA> sabdfl: +sources / +source
[09:34] <SteveA> the pattern you described in brazil was to have +foo as a "namespace distinction" thing, and +foos as a place to search etc.
[09:34] <SteveA> right now, at +sources, there is a SourcePackageSet object
[09:35] <SteveA> this should be changed to a "stepthrough" traversal, so we can get rid of the SourcePackageSet concept, when it is used as a SourcePackageSubset
[09:35] <SteveA> which is what we really have at +sources
[09:38] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: r=kiko Fix for bug 2904: System error from bug watch edit page. Uses the proper attribute and adds a test for the page. Patch by Diogo Matsubara <matsubara@async.com.br> (patch-2626: matsubara@async.com.br, christian.reis@canonical.com)
[09:40] <sabdfl> SteveA: sec
[09:40] <sabdfl> do portlets need facets in the zcml?
[09:40] <sabdfl> sorry :-)
[09:40] <SteveA> um...
[09:40] <SteveA> how did you know i was still here? ;-)
[09:41] <SteveA> i don't understand what you're asking
[09:41] <SteveA> content objects have facet menus registered for them.
[09:41] <sabdfl>     <browser:page
[09:41] <sabdfl>       name="+portlet-details"
[09:41] <sabdfl>       facet="overview"
[09:41] <sabdfl> is the facet needed?
[09:41] <SteveA> the main template takes care of displaying them.
[09:41] <SteveA> aha
[09:41] <SteveA> i see
[09:41] <SteveA> no, the zcml for portlets does not need to say what facet they are on
[09:42] <SteveA> only the zcml for entire pages needs to do that
[09:42] <SteveA> the easiest way for many things is to use <facet facet="name"> </facet> around the whole of the zcml
[09:42] <sabdfl> cool
[09:42] <SteveA> but it makes no difference either way if a portlet zcml page is within that
[09:43] <SteveA> beacuse although it will still be associated with that facet, that information is never used
[09:43] <SteveA> even if you're debugging, and go to the facet's actual URL in your browser
[09:43] <SteveA> the main template isn't used
[09:43] <SteveA> and so the facet it is on doesn't matter anyway
[09:52] <mpt> carlos, what does "from the Global Translation Wiki" mean?
[09:52] <carlos> mpt, suggestions added by non official translators
[09:59] <gneuman> does anyone know how do i get a parent of a set, like for a PollOptionSet, hw do i now the Poll it belongs to?
[10:04] <mpt> carlos: thanks, I'll call it "Unofficial suggestions" then
[10:04] <mpt> carlos: pofile-translate.pt is a behemoth
[10:04] <carlos> mpt, it's ok for me
[10:07] <mpt> it needs splitting up into about half a dozen modules
[10:07] <mpt> a suggestions macro
[10:07] <mpt> an alternate language macro
[10:08] <mpt> a macro for the actual translation field
[10:08] <mpt> anyway, goodnight people
[10:13] <sabdfl> cprov: ping
[10:13] <cprov> sabdfl: pong
[10:14] <sabdfl> cprov: can you give me a URL to a build overview page?
[10:14] <sabdfl> there is sourcepackagebuild-index.pt
[10:14] <sabdfl> where can i see it in action?
[10:14] <sabdfl> in the sampledata?
[10:15] <cprov> sabdfl: checking
[10:15] <Kinnison> ciao
[10:16] <sabdfl> i'm renaming those pages to build-*.pt
[10:16] <sabdfl> to keep them consistent with the rest of launchpad
[10:17] <cprov> sabdfl: distros/$Distribution.name/src/$Release.name/$package.name/$Release.version/arch
[10:17] <sabdfl> err...
[10:17] <sabdfl> have you tested that?
[10:17] <cprov> sabdfl: but AFAIK it's not exposed in the current sampledata
[10:17] <sabdfl> so, it's never been tested?
[10:17] <cprov> sabdfl: don't think so, it was developed by debonzi
[10:17] <sabdfl> ookkkk
[10:18] <sabdfl> hey rbelem
[10:18] <cprov> sabdfl: do you want I check it, at least present that page 
[10:18] <rbelem> hi sabdfl ;-)
[10:19] <sabdfl> cprov: i have to do it tonight
[10:19] <sabdfl> i'm afraid i have to rewrite chunks of this ui...
[10:20] <cprov> sabdfl: yeah, soyuz needs BasicTestCoverage urgently
[10:20] <sabdfl> cprov: we can add some sampledata by making some uploads and running some builds
[10:21] <sabdfl> real data
[10:22] <sabdfl> i wonder what the best url schema to a build is
[10:22] <sabdfl> given that we might have many of them
[10:22] <cprov> sabdfl: yes, but it still far from the reality, since we didn't test simple things like: are we presenting every declared page properly ?!. Things like that doesn't require real data 
[10:23] <sabdfl> cprov: the problem with the crap data we currently have is that its impossible to know if your page layout is sane for the usual case
[10:23] <sabdfl> real data is worth putting in
[10:23] <cprov> sabdfl: me too, currently I've land canonical_url for build, but it still presenting sources 
[10:23] <sabdfl> look at my sampledata for tickets, and specs
[10:23] <cprov> sabdfl: see you point and agree ... you mean SANE data ;)
[10:24] <sabdfl> cprov: in your builder UI, did you not need to create a page for a build?
[10:24] <sabdfl> where can i see sampledata pages for the build farm?
[10:25] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  shorten person menus (and tweak calendar page) (patch-2627: mpt@canonical.com)
[10:26] <cprov> sabdfl: not really, because build is collapsed in sourcepackage page .. it's the path to a single binary inside a distroarchrelease.
[10:26] <sabdfl> cprov: that doesn't make sense
[10:26] <sabdfl> there's a lot of info related to a build
[10:26] <sabdfl> it deserves a page on its own
[10:26] <sabdfl> i'll create one
[10:26] <sabdfl> where can i find the build farm pages?
[10:27] <cprov> sabdfl: you're right ... 
[10:27] <sabdfl> where can i find the build farm pages?
[10:27] <cprov> sabdfl: +builds  /sources/$distrorelease/+builds, etc
[10:27] <sabdfl> if you  have landed them, and they are about to go into production, ihope there is sampledata for everything
[10:28] <cprov> sabdfl: the complete "facet" is pending the 2nd pass review 
[10:28] <sabdfl> hmm...
[10:28] <sabdfl> ok, some feedback for you
[10:29] <cprov> sabdfl: there is, you can navigate through the existent srcpkgs (mozilla, pmount, etc)
[10:29] <sabdfl>  /+builds is not a good URL
[10:29] <sabdfl>  /buildfarm/ would be better
[10:30] <cprov> sabdfl: do you think ? it was buildfarm/ but I and mpt agree in +builds to present something like a facet 
[10:30] <sabdfl> no
[10:30] <sabdfl> sorry
[10:30] <sabdfl>  /buildfarm/                should be an overview of all the builders
[10:30] <cprov> sabdfl: if you have time have a quick look on ABUI spec 
[10:30] <sabdfl>   /buildfarm/+build/32423               should be build #32423
[10:31] <cprov> sabdfl: it's easy to change
[10:31] <sabdfl>   /buildfarm/bob/               should be the builder called bob
[10:31] <sabdfl> what else do we need?
[10:32] <sabdfl> ok, i will revamp this url space too
[10:32] <cprov> sabdfl: you don't need to see the buildqueue entry itself, you can see it from the published sourcepackage or from the builder page as a row containing all the info 
[10:33] <cprov> sabdfl: we have builds for distribution/distrorelease/distroarchrelease all of them present kind of uniform information but in a restricted domain 
[10:33] <sabdfl> cprov: that's not good, because you may have two or three build attempts for the same package in the same distrorelease
[10:33] <sabdfl> and each of those might produce ten or twenty binary packages
[10:33] <sabdfl> so that page would get hideous
[10:33] <cprov> sabdfl: but never for the same distroarchrelease
[10:34] <sabdfl> cprov: wrong
[10:34] <sabdfl> if it fails, it can get rebuilt
[10:34] <sabdfl> and rebuilt
[10:34] <sabdfl> till it passes
[10:34] <cprov> sabdfl: the result are not inside buildqueue domain ... they are in Build domain
[10:35] <sabdfl> which has no page to describe it
[10:35] <sabdfl> look here's the point
[10:35] <sabdfl> one sourcepackage, 13 architectures, 3 retries, 8 binary packages per success
[10:35] <cprov> sabdfl: if it fails the buildqueue is removed anyway ... you need to rebuild
[10:35] <sabdfl> all on ONE PAGE?
[10:35] <sabdfl> the build should remain as failed
[10:35] <sabdfl> so we retain the logs
[10:35] <sabdfl> we know why it failed
[10:35] <sabdfl> we can analyse it
[10:36] <sabdfl> people can see what went wrong
[10:36] <cprov> sabdfl: currently in sources/warty/i386/mozilla/+builds
[10:37] <sabdfl> cprov: that can't work
[10:37] <cprov> sabdfl: that is the page to see how a published sourcepackagerelease goes for a given distroarchrelease 
[10:37] <sabdfl> you don't know what version you are looking at
[10:37] <sabdfl> i386 is a sourcepackagerelease?
[10:38] <cprov> sabdfl: always the newest one, that page present all of them published 
[10:38] <sabdfl> how do i see an older one?
[10:38] <sabdfl> dude, this is simple
[10:38] <cprov> sabdfl: no an distroarchrelease
[10:38] <sabdfl> you should present each table, as a page
[10:38] <sabdfl> not hard
[10:38] <sabdfl> if there is a biuld table, there should be a build-index.pt
[10:38] <sabdfl> not hard
[10:39] <sabdfl> all you have to do is figure out where it should go
[10:39] <sabdfl> make sense?
[10:39] <cprov> sabdfl:  uhm ... you're probably right ... the idea makes sense
[10:39] <sabdfl> putting the "build" page at a sourcepackagerelease-in-distro page is madness, because the two do not correlate 1-to-1
[10:40] <sabdfl> what is the content object for /+builds
[10:40] <sabdfl> ?
[10:40] <sabdfl> cprov: ^
[10:40] <cprov> sabdfl: lp/+builds is that /buildfarm/ you reffered before .. shows the registered builders
[10:40] <sabdfl> where can i find it in the code? 
[10:41] <sabdfl> i would expect database/builder.py
[10:41] <sabdfl> as BuilderSet
[10:41] <sabdfl> ?
[10:41] <cprov> sabdfl: [db,browser] /builder.py
[10:41] <sabdfl> nice
[10:41] <sabdfl> perfect
[10:41] <cprov> sabdfl: every  xxx-builds.pt 
[10:42] <cprov> sabdfl: builder.py still carrying BuildQueue small classes .. it will change when we think convenient 
[10:42] <cprov> sabdfl: are you working on this soon ?
[10:43] <cprov> sabdfl: steve promised me to review last important patches for builddUI today, if it doesn't happen before you start I suggest you to merge from my personal branch 
[10:44] <cprov> sabdfl: otherwise the conflicts will be horrible :(
[11:02] <sabdfl> cprov: ok, i can merge from it
[11:03] <sabdfl> when do you expect it to land?
[11:05] <sabdfl> cprov: i do like builder.py and build.py, they are nice and clean, the right things in the right placs
[11:12] <cprov> sabdfl: ASAP, tomorrow is the ETA, but depends from steve 
[11:13] <cprov> sabdfl: yep, the reviewers helped a lot for the code sanity 
[11:26] <asmodai> dudes
[11:26] <asmodai> eirikn here is hacking bazaar
[11:26] <eirikn> -ng
[11:26] <asmodai> who of you does a lot with that :)
[11:26] <asmodai> buggers might be off to lunch :P
[11:27] <eirikn> heh
[11:27] <eirikn> what is launchpad anyway?
[11:27] <asmodai> www.launchpad.net
[11:27] <asmodai> these async weirdos are python lubb0rs
[11:27] <asmodai> :)
[11:28] <eirikn> can't connect to the webpage, times out
[11:29] <asmodai> works for
[11:29] <asmodai> me
[11:30] <eirikn> lynx there works
[11:31] <asmodai> You've been filtered!
[11:31] <asmodai> :)
[11:31] <eirikn> :'(
[11:33] <eirikn> restarting firefox fixed it
[11:36] <eirikn> I think the caching in firefox is borked at times
[11:55] <carlos> sabdfl, ok, seems like I have most bugs fixed, now I need to investigate a bit some outdated reports that pitti told me and I think I will be done
[11:55] <carlos> will do it before leaving to sleep and will send an email with a small report of the status, ok?
[12:00] <Trix> what happend that now, do not send ubuntu cd?
[12:01] <salgado> https://launchpad.net/bounties/chquite