| sabdfl | mpt: we definitely need a "highlighted box in the middle of the page" | 12:22 |
|---|---|---|
| sabdfl | could use portlet-style colours | 12:22 |
| Nafallo | sabdfl: launchpad _will_ be open-source in the future, right? gajim upstream bugs me about it :-/. | 12:24 |
| sabdfl | Nafallo: yes, in time | 12:24 |
| sabdfl | we've released bits of it already | 12:24 |
| sabdfl | small bits - libraries, and the calendar code | 12:25 |
| Nafallo | :-) | 12:25 |
| mpt | sabdfl: .highlighted {background-color: #f7f9fa; border: 1px solid #8cacbb; padding: 0.5em;} | 12:25 |
| Nafallo | sabdfl: thanx :-) he found this blog entry: http://azure.humbug.org.au/~aj/blog/2005/09/04#2005-09-04-launchpad-freeness | 12:25 |
| Nafallo | so I thought it was best to ask ;-) | 12:26 |
| sabdfl | mpt: can i commit that? | 12:26 |
| sabdfl | to launchpad.css? | 12:27 |
| mpt | sure | 12:27 |
| sabdfl | mpt: i'll go with dotted | 12:28 |
| Burgundavia | sabdfl, does launchpad have an easy way people can request apps to be packaged for a particular distro? | 12:29 |
| mpt | not dashed? | 12:29 |
| === mpt throttles kiko | ||
| sabdfl | Burgundavia: no, that's a great feature | 12:29 |
| sabdfl | Burgundavia: if you do up a spec in wiki.launchpad.canonical.com we could discuss it at UBZ | 12:30 |
| Burgundavia | sabdfl, sure, will do after I push out the quicktour (which can now be seen here --> http://doc.ubuntu.com/gnome/quicktour/quicktour.html ) | 12:30 |
| === Nafallo goes to look | ||
| Burgundavia | that version is old, but only a few minor cosmetic things have changed | 12:31 |
| Nafallo | Burgundavia: you're not going to add screenshots first? ;-) | 12:31 |
| Nafallo | Burgundavia: ah, :-) | 12:32 |
| Nafallo | Burgundavia: like screenshots? ;-) | 12:32 |
| Burgundavia | Nafallo, no, I am going to ship it like that, so that users can simply imagine the great features | 12:32 |
| Nafallo | Burgundavia: lol :-) | 12:32 |
| Nafallo | Burgundavia: that's what I thought then ;-) | 12:33 |
| Burgundavia | Nafallo, I have to wait for art-freeze on the 29th to start doing screenshots | 12:33 |
| Nafallo | ah | 12:33 |
| === Nafallo was right :-P | ||
| Burgundavia | Nafallo, do use gaim? | 12:33 |
| Nafallo | Burgundavia: gajim :-) | 12:33 |
| Burgundavia | grr | 12:33 |
| Burgundavia | I need a gaim user that connects to multiple different networks (aim, icq, etc.) | 12:34 |
| Nafallo | to bad I've converted my girlfriend then ;-) | 12:34 |
| sabdfl | Burgundavia: looks awesome. why not borrow some of the ubuntu css? | 12:35 |
| Burgundavia | sabdfl, the top bar? I have considered it, not yet tried it out | 12:36 |
| === carlos -> bed | ||
| sabdfl | SteveA: do our cronscripts run as a user? can they? | 12:45 |
| sabdfl | i have to touch an object, and it's giving me : | 12:45 |
| sabdfl | File "/home/mark/projects/ubuntu/launchpad/lib/canonical/launchpad/subscribers/cve.py", line 8, in cve_modified | 12:45 |
| sabdfl | cve.datemodified = UTC_NOW | 12:45 |
| sabdfl | zope.security.interfaces.ForbiddenAttribute: ('datemodified', <Cve at 0x-579ab1b4>) | 12:45 |
| sabdfl | grief | 12:45 |
| sabdfl | interesting, because the code seems to be able to poke other values quite happily | 12:46 |
| Nafallo | sabdfl: please... how do I get from here https://launchpad.net/distros/ubuntu/breezy/+sources/gajim/+pots/gajim/sv to the translation area? ;-) | 01:08 |
| sabdfl | Nafallo: add /+translate | 01:09 |
| sabdfl | https://launchpad.net/distros/ubuntu/breezy/+sources/gajim/+pots/gajim/sv/+translate/+login | 01:09 |
| sabdfl | that's a bit of a brown paper bagger | 01:09 |
| Nafallo | sabdfl: shouldn't that be a link in the portlet? :-) | 01:09 |
| === Lovechild [n=dnielsen@0x50c71cc7.adsl-fixed.tele.dk] has joined #launchpad | ||
| sabdfl | Nafallo: yes, it should be | 01:10 |
| Nafallo | or what the "actions:"-thingie is called ;-) | 01:10 |
| sabdfl | i'm guessing there's a fix on the way | 01:10 |
| Nafallo | sabdfl: cool, thanx :-). I guess that would mean I don't have to file a bug about it? :-) | 01:11 |
| sabdfl | Nafallo: no, i think that one's already noted | 01:12 |
| sabdfl | i may actually be responsible for that | 01:13 |
| sabdfl | oops | 01:13 |
| Nafallo | sabdfl: hehe :-) | 01:13 |
| sabdfl | kiko: that's one for the 1.0 list | 01:13 |
| Nafallo | sabdfl: feel free to patch it ;-) | 01:16 |
| sabdfl | Nafallo: i just did ;-) | 01:17 |
| Nafallo | sabdfl: ROCK ON! :-D | 01:17 |
| kiko | wow | 01:36 |
| kiko | hmmm | 01:36 |
| kiko | mpt, so you're okay with the page titles I added? | 01:40 |
| === superted [n=superted@213.167.101.222] has joined #launchpad | ||
| mpt | kiko: In fresh RF the titles are already there and the pages work | 02:13 |
| mpt | except that +gethelp links to +addticket, which is broken | 02:14 |
| kiko | mpt, must be the sab's interference | 02:14 |
| mpt | ProgrammingError: ERROR: relation "ticket" does not exist SELECT COUNT(*) FROM Ticket WHERE distribution = 1 AND sourcepackagename = 9 | 02:14 |
| kiko | argh | 02:14 |
| kiko | mpt, make schema | 02:15 |
| mpt | ok, that works too | 02:20 |
| mpt | so I have nothing to do here, then | 02:20 |
| kiko | mpt, the pages are already done? | 02:20 |
| kiko | wonderful | 02:20 |
| mpt | well, placeholders are there | 02:20 |
| kiko | any tweaking you'd like to do to them? | 02:20 |
| mpt | +translate is rather orange, but otherwise ok | 02:21 |
| mpt | yeah, I've tweaked +gethelp | 02:21 |
| kiko | mkay | 02:21 |
| kiko | well, thanks, then. this is actually worse than I had hoped for, because there's no way stuart's cherrypicking the fat patch all in | 02:21 |
| kiko | so I have no clue how I'm going to deal with this :-( | 02:21 |
| mpt | If we'd had the support thingy earlier, "Get Help Online..." could have directed straight to +support | 02:21 |
| mpt | though that's not a 100%-certain good idea, so perhaps it's good they are different URLs, to allow for redirecting or not based on later decisions | 02:23 |
| mpt | Those URLs are going to have to live for years | 02:24 |
| kiko | yeah | 02:27 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] adds status legend to distributon release translations page (bug 2138), and fixes customization link text (patch-2375: mpt@canonical.com) | 02:28 |
| === stub [n=stub@203-217-37-199.dyn.iinet.net.au] has joined #launchpad | ||
| jordi | fun, so tar.bz2 uploads break | 02:33 |
| jordi | good night mates | 02:34 |
| Nafallo | jordi: night, and thanx for everything today :-) | 02:35 |
| jordi | np :) | 02:35 |
| kiko | stub, so have a few moments to chat? | 03:39 |
| stub | kiko: sure | 03:53 |
| kiko | stub, so couple of things | 03:53 |
| kiko | breezy release was on today | 03:53 |
| kiko | so tomorrow people might start hitting +gethelp and +translate | 03:53 |
| kiko | these pages are currently 500s | 03:53 |
| === niemeyer needs some sleep.. | ||
| kiko | thankfully enough the sourcepackagenames exist now thanks to your good work | 03:54 |
| niemeyer | Night folks | 03:54 |
| kiko | niemeyer, sleep is for babies | 03:54 |
| niemeyer | :) | 03:54 |
| stub | night | 03:54 |
| kiko | stub, however, unless we fix the pagetitles, they will go on being 500s | 03:54 |
| kiko | breezy releasenoted launchpadintegration | 03:55 |
| stub | So there is a patch to cherry pick to fix this? | 03:56 |
| kiko | well | 03:56 |
| kiko | here's the problem | 03:56 |
| kiko | I /have/ a patch which fixes this | 03:56 |
| kiko | unfortunately mark landed a fix for the same problem in RF in his massive support-tracker branch | 03:57 |
| kiko | so much for keeping patches simple | 03:57 |
| === mpool [n=mbp@cor6-ppp610.for.dsl.connect.net.au] has left #launchpad [] | ||
| stub | So we need to branch production--1.31, fix, and merge back into production--1.31 | 03:57 |
| stub | Or I can just cherry pick your fix into production | 03:58 |
| kiko | I never landed it in RF because of mark's bonk. | 03:58 |
| stub | Landing to rocketfuel is nice, because it confirms that the code plays nice with head (cause the tests are run there), and when I cherry pick from there it confirms it runs nice with production too. But landing in rocketfuel is not necessary for production cherry picks. | 03:59 |
| kiko | I think the patch I landed added some failing tests to xx-notfound-traversals | 04:00 |
| kiko | is that a big deal? | 04:00 |
| kiko | stub, the patch basically adds pagetitles -- that's all that's broken there :-( | 04:01 |
| stub | Yes - cherry picks will fail unless the tests pass | 04:01 |
| kiko | stub, I'll mail you a diff; how about that? | 04:01 |
| kiko | :) | 04:01 |
| stub | Sure | 04:02 |
| stub | If I can remember how to apply a patch manually. | 04:02 |
| kiko | patch -p1 < patch | 04:02 |
| kiko | sent | 04:04 |
| kiko | stub, so on to the next set of problems | 04:05 |
| kiko | stub, do you have an updated script from carlos? | 04:05 |
| stub | No | 04:05 |
| kiko | really? | 04:05 |
| kiko | that's a shame | 04:05 |
| stub | Unless he landed it in rocketfuel | 04:05 |
| === mpt [n=mpt@200-171-140-32.dsl.telesp.net.br] has joined #launchpad | ||
| kiko | sheesh. | 04:06 |
| stub | Does that mean the last run failed and I can resync the staging database today? | 04:06 |
| kiko | stub, well, it failed less horribly. | 04:06 |
| stub | No diff from you yet btw... | 04:07 |
| kiko | stub, so here, I actually have carlos' patch. | 04:07 |
| kiko | grumble grumble | 04:07 |
| kiko | https://chinstrap.warthogs.hbd.com/~jamesh/pending-reviews/carlos.perello@canonical.com--2004/launchpad--devel--0/filtered-diff | 04:07 |
| stub | So I should pull that branch and run the migration script against staging to see what happens | 04:08 |
| kiko | stub, that in addition to RF should produce a beautiful database. | 04:09 |
| kiko | well | 04:09 |
| kiko | right, if you pick up the stuff carlos landed in RF as well. | 04:09 |
| kiko | stub, so ready for part 3 in this drama? | 04:11 |
| stub | Ok. I'll resync the staging database, update the code to rocketfuel trunk (with my config file fixes in pqm atm), merge in carlos' branch and run the migration script | 04:12 |
| kiko | stub, cool. any idea on how long will it take? | 04:12 |
| stub | About two hours for staging updates to all happen (including the db sync), and another 20 odd hours for the migration script to run | 04:13 |
| kiko | 20 hours depresses me | 04:13 |
| kiko | I was kinda hoping, you know | 04:13 |
| kiko | to generate some working language packs tomorrow | 04:14 |
| kiko | I should just accept the fact that we're not going to launch rosetta for the next 12 days, right? | 04:14 |
| stub | What? That someone pulled out some problematic database entries, added them into the sampledata so we wouldn't have to keep trial-an-error running against production data? | 04:14 |
| kiko | hey | 04:15 |
| kiko | carlos has been adding tests | 04:15 |
| stub | ;) | 04:15 |
| kiko | the issue is that there are lots of little corner cases! | 04:15 |
| stub | I'm hungy | 04:15 |
| === kiko throws stub an r | ||
| === stub eats it | ||
| kiko | ai ai ai | 04:16 |
| kiko | well | 04:16 |
| kiko | I'll ask carlos to give me instructions on how to generate the language packs | 04:16 |
| kiko | who knows | 04:16 |
| kiko | I might convince our DBA to give me read-only access to staging | 04:16 |
| stub | You got an account on macquarie or mawson? | 04:17 |
| kiko | I used to have one on mawson | 04:17 |
| kiko | let's see | 04:17 |
| kiko | Permission denied (publickey,keyboard-interactive). | 04:18 |
| kiko | I guess not anymore. | 04:18 |
| stub | I can give you access if you get an account on a more-secure-than-chinstrap box | 04:18 |
| kiko | I'll work on that tomorrow. Does salgado have access? | 04:19 |
| stub | I think so | 04:20 |
| stub | Nope... | 04:21 |
| kiko | hmmm | 04:21 |
| stub | Same deal | 04:21 |
| kiko | I thought he had an account on one of those boxes | 04:21 |
| kiko | okay, I'll ask elmo and stay up tomorrow. | 04:22 |
| stub | I'm checking. cprov has on mawson | 04:22 |
| stub | As do you! | 04:22 |
| stub | Unless elmo closed accounts and left the home directories there | 04:23 |
| kiko | id kiko | 04:23 |
| kiko | but my password doesn't work, hmmm. | 04:23 |
| stub | Yup | 04:23 |
| kiko | whee! | 04:23 |
| kiko | it worked | 04:23 |
| stub | you are there. | 04:24 |
| stub | ok... I'll open up readonly access for you. | 04:24 |
| kiko | thanks | 04:24 |
| === kiko should probably generate an ssh key on chinstrap | ||
| stub | You type passwords? | 04:24 |
| kiko | stub, does that make sense, generating a key and adding it to my authorized keys? | 04:24 |
| kiko | never | 04:24 |
| kiko | but I hadn't created keys on chinstrap, just that | 04:25 |
| stub | You want a separate key for that account? | 04:26 |
| stub | "psql -d launchpad_staging -H asuka.ubuntu.com -U ro" should now work for you | 04:26 |
| kiko | stub, I don't want to go about copying private keys here and there | 04:26 |
| stub | Why would you need to have any private keys on the servers? | 04:27 |
| kiko | for sshing from chinstrap to mawson? | 04:27 |
| stub | Oh. I don't do that. | 04:27 |
| elmo | err | 04:27 |
| kiko | yes elmo? | 04:27 |
| kiko | is that frowned upon? | 04:28 |
| elmo | please use the damn proxycommand trick | 04:28 |
| kiko | I use it | 04:28 |
| kiko | I was just fooled to sshing from chinstrap to mawson and considered the ssh key. but whatever.. | 04:28 |
| elmo | then why you need to ssh from chinstrap to mawson? | 04:28 |
| kiko | because I don't think too much about where I am sshing from | 04:28 |
| kiko | perhaps I need more sleep | 04:28 |
| kiko | but then again | 04:28 |
| kiko | so do you :-P | 04:28 |
| kiko | stub, for the record, it's lowercase -h | 04:30 |
| === mp1 [n=mpt@200-171-140-32.dsl.telesp.net.br] has joined #launchpad | ||
| kiko | and thanks | 04:31 |
| stub | kiko: If you had a private key on chinstrap that let kiko@chinstrap ssh to mawson without passwords or ssh-agent etc., you have just made mawson less secure than chinstrap (defeating the purpose of requiring you to have an account on a machine more secure than chinstrap.) Same think if you ever type your mawson password when logged into chinstrap. | 04:31 |
| stub | (not that ssh-agent is a particularly good idea to forward around either) | 04:32 |
| stub | Don't convert the attack trees into a mesh | 04:34 |
| kiko | okay okay okay | 04:34 |
| kiko | stub, ready for part 3 in the drama? | 04:36 |
| stub | Ya know, you really don't need to raise the dramatic tension. Just spit it out ;) | 04:37 |
| kiko | I need to test the channel | 04:37 |
| kiko | so salgado has some shipitness to land tomorrow | 04:37 |
| kiko | it's not very difficult | 04:38 |
| kiko | I'm doing the review now | 04:38 |
| kiko | however | 04:38 |
| kiko | it will land, say, tomorrow afternoon | 04:38 |
| kiko | now | 04:38 |
| kiko | this doesn't need to go into production until tuesday/wednesday | 04:38 |
| kiko | so I was going to ask what you thought of this | 04:38 |
| stub | We have landed worse ;) | 04:39 |
| kiko | how about cutting production like, say, saturday morning and delaying production rollout till wednesday | 04:39 |
| stub | Yup. Sounds good. | 04:39 |
| kiko | or whatever you feel comfortable with | 04:39 |
| kiko | because otherwise it's going to be difficult to cherry-pick | 04:39 |
| kiko | mark's landed the support tracker | 04:39 |
| kiko | that's going to be difficult | 04:39 |
| kiko | I have a QA intern starting on monday | 04:40 |
| kiko | so I'll sic him on staging | 04:40 |
| kiko | see if he can find bustage in time to fix | 04:40 |
| stub | Score! | 04:40 |
| === stub high fives kiko | ||
| spiv | Q... A? | 04:41 |
| kiko | we try harder! | 04:41 |
| spiv | What's that? ;) | 04:41 |
| kiko | questions and answers | 04:41 |
| kiko | he asks questions, spiv answers "sorry, my bug" | 04:41 |
| kiko | for instance | 04:42 |
| spiv | Q: "Why is it broken?" A: "It's software!" | 04:42 |
| kiko | there's this librarian issue | 04:42 |
| stub | Todays rollout was brought to you by the letters 'Q' and 'A' | 04:42 |
| kiko | I don't know if I've told you about it | 04:42 |
| kiko | there are lots of Qs in this issue | 04:42 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Staging and production config changes (patch-2376: stuart.bishop@canonical.com) | 04:42 |
| kiko | I don't imagine you'll have seen any As lying around? | 04:42 |
| stub | I'm full of A | 04:43 |
| spiv | Not yet, but I'll will be looking into today... | 04:43 |
| stub | Or I'm full of something, anyway | 04:43 |
| kiko | oh so somebody fed you? | 04:43 |
| spiv | But in the mean time, I'm un-full of lunch. | 04:43 |
| kiko | spiv, hooray for As | 04:43 |
| kiko | lunch? is it that late already? my god | 04:43 |
| stub | Dammit I still havn't had breakfast! | 04:43 |
| stub | type faster kiko | 04:43 |
| spiv | stub: Well, me either ;) | 04:44 |
| stub | I'm not really aware of the Librarian issue, but if spiv thinks he has a handle on it and will be working on it I probably don't need to ;) | 04:44 |
| kiko | that was all meant as just nastiness to master spiv | 04:45 |
| kiko | I know the issue is a lot trickier than the traceback suggests | 04:46 |
| stub | Is there a bug#? | 04:48 |
| kiko | that's a good question | 04:48 |
| kiko | let me see | 04:48 |
| kiko | https://launchpad.net/malone/bugs/1887 | 04:49 |
| === stub kicks off the staging update | ||
| kiko | who could have reported such bug? | 04:49 |
| stub | What is interesting is that http://librarian.launchpad.net/264524/264557/gl.po is actually there and downloadable from the librarian, so it is purely a client.py issue | 04:56 |
| stub | Maybe having difficulties downloading from the librarian (eg. when I forget to bounce it after an upgrade ;) ), but the exception being swallowed and converted to a LookupError | 04:57 |
| spiv | stub: Well, it smells like a transaction issue. | 05:01 |
| kiko | to me the same | 05:01 |
| stub | spiv: Well, the librarian won't serve the file until the transaction that uploaded it has committed. | 05:02 |
| stub | (and possibly will need a small delay for the commit to propogate) | 05:02 |
| spiv | Tell me more about this "small delay". | 05:03 |
| stub | apart from that, I don't see a possible transaction issue in there. | 05:03 |
| spiv | Well, just that the client is needing to access database rows that the server has added and committed.. | 05:03 |
| stub | If you say 'transaction.commit(); get_the_file_from_the_librarian()', there might be a race condition whilst PostgreSQL commits the transaction. If the librarian starts serving the file before that commit has finished, it will still see the old data in the table missing the newly added row. | 05:04 |
| stub | (But I'm guessing here) | 05:04 |
| spiv | Well, the LookupError is due to a 404 on the server side. I got it backwards; the server needs to see rows that the client inserted and committed. | 05:05 |
| spiv | Hmm. I would have naively expected transaction.commit() to block until the commit was fully done and the changes visible to any new transaction. | 05:05 |
| spiv | But it would perhaps be interesting to see if immediately retrying would work around the problem. | 05:06 |
| spiv | Food for thought... I should get some food for my stomach. | 05:07 |
| === robitaille [n=daniel@d154-5-117-228.bchsia.telus.net] has joined #launchpad | ||
| kiko-zzz | my god | 05:22 |
| kiko-zzz | need to bed | 05:22 |
| stub | spiv: The Librarian connection will not see newly inserted rows if it is already inside a transaction because it is running in serializable transaction isolation level. eg. if Librarian thread had previously issued 'select' statements on the LibraryFileAlias it will not see newly inserted rows until the transaction is reset or the transaction isolation level changed. | 05:33 |
| stub | spiv: If we have the librarian issue con.set_isolation_level(0), it will even see uncommitted rows, which could greatly simplify our transactional semantics. As far as I can see, this will not adversely affect the librarian (as it never alters rows and new insertions will never conflict). | 05:46 |
| === SteveA [n=steve@office.pov.lt] has joined #launchpad | ||
| spiv | stub: In theory, the librarian should be starting a transaction for each web request, and aborting it at the end of those requests. Your set_isolation_level idea sounds good, though! | 06:01 |
| === stub considers upgrading to breezy | ||
| stub | spiv: bugger. isolation level 0 is autocommit in psycopg, not read uncommitted (which PostgreSQL doesn't have :-( ) | 06:37 |
| spiv | Ah, suck. | 06:37 |
| stub | spiv: set_isolation_level(1) might help in this case (read committed), which would avoid the need to reset the connection every request if for some reason it isn't being done. But it won't improve the Librarian client transactional semantics at all. | 06:39 |
| spiv | I wonder if the client really is committing often enough. | 07:03 |
| spiv | The calls to the librarian and the calls to commit in po_export_queue.py are seperate enough that it's hard to tell. | 07:04 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--production--1.31: [trivial] Fix some page titles on production (patch-4: stuart.bishop@canonical.com) | 07:11 |
| === robertbb [n=robertbb@d154-20-129-24.bchsia.telus.net] has joined #launchpad | ||
| === vinsci [n=nvinsci@dsl-sjkgw2jb1.dial.inet.fi] has left #launchpad ["Lmnar"] | ||
| === niran [n=niran@sabin.Stanford.EDU] has joined #launchpad | ||
| spiv | stub: Good rant. | 08:02 |
| stub | Didn't get enough sleep last night | 08:03 |
| stub | ;) | 08:04 |
| spiv | Clearly you should be sleep deprived more often ;) | 08:04 |
| === robitaille [n=robitail@d154-5-117-228.bchsia.telus.net] has joined #launchpad | ||
| === dand [n=dand@gw.datagroup.ro] has joined #launchpad | ||
| === carlos [n=carlos@243.Red-83-47-24.pooles.rima-tde.net] has joined #launchpad | ||
| carlos | morning | 09:10 |
| spiv | carlos: Morning. | 09:13 |
| spiv | carlos: can there be more than one pofile and one potemplate in a single export? | 09:14 |
| carlos | spiv, more than one pofile, yes. More than one potemplate no | 09:15 |
| spiv | carlos: Is it possible that the same pofile might be included in the same export multiple times? If so, is it likely? | 09:20 |
| === spiv is finally understanding the po export code somewhat. | ||
| carlos | spiv, no, it's not possible | 09:26 |
| carlos | spiv, the db model will not allow that | 09:26 |
| spiv | That's good news :) | 09:26 |
| carlos | spiv, in fact, I think kiko told me that the code is not able to handle that and if you request the pofile twice, you get a db error | 09:26 |
| carlos | spiv, hmm, well, we could export twice the same pofile but in different transactions | 09:27 |
| carlos | if different people ask for it | 09:27 |
| carlos | it will happen in the same export run, but different transactions | 09:27 |
| spiv | Well the question I guess is will IPOExportRequestSet.popRequest return the same object multiple times in one invocation. | 09:28 |
| spiv | And it seems the answer is no, which is good :) | 09:28 |
| === BjornT [n=bjorn@office.pov.lt] has joined #launchpad | ||
| carlos | spiv, right, the answer is no | 09:29 |
| carlos | spiv, hmm, looking twice to the db model... | 09:30 |
| carlos | spiv, it's possible, but not usual | 09:30 |
| spiv | Hmm. | 09:30 |
| spiv | So, here's what made me ask the question: | 09:31 |
| carlos | spiv, if they request a pofile and later the same pofile as a .mo export | 09:31 |
| spiv | transaction.commit() happens between invocations of process_multi_object_request, which deals with multiple files. | 09:31 |
| carlos | spiv, hmm, forget that, the db model allows that, the code does not | 09:31 |
| spiv | (why the export code refers to "objects" instead of files I don't know) | 09:32 |
| carlos | spiv, no idea either, daf wrote that code | 09:32 |
| carlos | from what I see, yes, it should be 'files' | 09:32 |
| jordi | hey | 09:42 |
| === superted [n=superted@213.167.101.222] has joined #launchpad | ||
| carlos | jordi, hi | 09:47 |
| carlos | SteveA, hi, around? | 09:47 |
| BjornT | carlos: SteveA should be around in 30 mins or so | 09:50 |
| carlos | BjornT, ok, thanks | 09:50 |
| === Seveas [n=seveas@ksl403-uva-132.wireless.uva.nl] has joined #launchpad | ||
| sabdfl | moin moin | 10:02 |
| Kinnison | !niom niom :lfdbas | 10:08 |
| lifeless | moin | 10:10 |
| === WaterSevenUb [n=WaterSev@195-23-220-223.net.novis.pt] has joined #launchpad | ||
| === cprov [n=cprov@217.205.109.249] has joined #launchpad | ||
| SteveA | hi | 10:29 |
| SteveA | i'm around | 10:29 |
| SteveA | carlos: [omg | 10:29 |
| SteveA | um, | 10:29 |
| SteveA | carlos: ping | 10:29 |
| SteveA | sabdfl: scripts that use zcml generally run as a special user | 10:29 |
| carlos | SteveA, hi, did you see kiko's review ? | 10:29 |
| SteveA | this user can read/write stuff that has a permission declared for it | 10:30 |
| carlos | SteveA, I have a question for you related to the review he did for one of my branches | 10:30 |
| SteveA | so in your case above, check that datemodified is in the interface, and is declared as a settable attribute. | 10:30 |
| SteveA | carlos: i haven't read any email yet today. kiko's review of what? | 10:30 |
| carlos | REVIEW: carlos.perello@canonical.com--2004/launchpad--devel--0 | 10:31 |
| carlos | SteveA, it's related to helpers.py | 10:31 |
| carlos | I need to know what should I do with some functions added there in that branch | 10:31 |
| carlos | SteveA, he asked me to check it with you | 10:32 |
| lifeless | jamesh: ping | 10:33 |
| carlos | so if you have time, I prefer to move it to the right place now instead of leaving it for another day (or we will forget it...) | 10:33 |
| SteveA | carlos: okay, i'll look at it shortly. | 10:34 |
| carlos | SteveA, thank you | 10:35 |
| SteveA | so, it is about running "sanity_fixes" on a pot message set's data | 10:38 |
| sabdfl | SteveA: the issue was a cut-and-paste readonly=True | 10:39 |
| carlos | SteveA, yeah | 10:39 |
| SteveA | sabdfl: okay, that makes sense. | 10:39 |
| SteveA | carlos: so, can you make it a method on a pot msg set? | 10:39 |
| sabdfl | SteveA: i have an issue, I'm trying to make a "removeform" | 10:39 |
| sabdfl | and have been fudging it with an addform | 10:39 |
| sabdfl | but now that I'm trying to add events to the mix, it has all gone pear shaped | 10:40 |
| === mdke [n=matt@unaffiliated/mdke] has joined #launchpad | ||
| mdke | hi all | 10:40 |
| SteveA | what's a typical url that this remove form will be at? | 10:40 |
| sabdfl | +unlinkbug | 10:40 |
| SteveA | on what? | 10:40 |
| sabdfl | basically, I want to render it like an add form | 10:40 |
| mdke | i heard the ubuntu members email addresses got set up, how do I activate mine? anyone know? | 10:40 |
| mdke | s/addresses/forwards | 10:41 |
| SteveA | i need to see the url, including its context object, to make sense of it | 10:41 |
| sabdfl | but instead of a def create() and def add(), I just want a def remove() | 10:41 |
| SteveA | what's the context object? | 10:41 |
| sabdfl | in this case, it's a CVE | 10:42 |
| sabdfl | and I want to link, and unlink, it from a bug | 10:42 |
| sabdfl | so, i have a BugCve | 10:42 |
| sabdfl | and the link form looks like an addform for a BugCve | 10:42 |
| SteveA | so, this unlinks a bug from the cve reference, but removing the BugCVE | 10:42 |
| sabdfl | with the CVE being a ContextWidget | 10:42 |
| SteveA | or perhaps altering the BugCVE | 10:42 |
| sabdfl | and the bug being a bug number input widget | 10:42 |
| carlos | SteveA, hmm, could try to adapt it to use the 'self' argument yes, otherwise it will not make sense ther | 10:43 |
| sabdfl | removing the bugcve | 10:43 |
| carlos | there | 10:43 |
| sabdfl | there's a similar pattern for subscriptions | 10:43 |
| sabdfl | i've handled subscriptions by posting to the core ObjectView, and parsing the form in the __init__ of the object view | 10:43 |
| SteveA | carlos: submission.pomsgset.potmsgset.apply_sanity_fixes(translation.translation) | 10:43 |
| sabdfl | but wanted to try something different for linking to bugs | 10:43 |
| SteveA | can you use an edit form for this? | 10:44 |
| SteveA | rather than an add form | 10:44 |
| sabdfl | not really, no | 10:44 |
| sabdfl | i want to select something for removal | 10:44 |
| sabdfl | the problem at the moment is this | 10:44 |
| sabdfl | when i remove the BugCve object, the addform createAndAdd method tries to adapt the return value of add() to an IBugCve | 10:45 |
| sabdfl | and of course None won't adapt | 10:45 |
| sabdfl | i was cheating, and returning the destroyed BugCve, but introducing events makes that trickery unworkable | 10:45 |
| sabdfl | let me see what I can do | 10:46 |
| SteveA | why do you specifically want to use an add form for removing something? | 10:47 |
| carlos | SteveA, sure | 10:47 |
| sabdfl | SteveA: because there is no removeform | 10:49 |
| sabdfl | it's a hack | 10:49 |
| SteveA | you can completely override createAndAdd and make it do what you want. | 10:49 |
| SteveA | it sounds like a confusing hack, though. seeing as this "let's link some content object to some other object, via a linking object, and have a ui on this" is a common pattern in launchpad... | 10:50 |
| SteveA | we should have an admin-links kind of form that makes this non-hacky. | 10:51 |
| BjornT | Kinnison: on PackageDBRework, in which section does BinaryPackageName belong? | 10:52 |
| stub | An add form is just an edit form with create and some extra pain-in-the-bum zodb specific crack (must return an object implementing the interface, because it assumes that result will be stuffed in the ZODB somewere). Unless it has changed recently, edit form is more flexible (addForm extends editform I think) | 10:53 |
| SteveA | the other thing about an add form is that it is meant for adding something that is not there already | 10:54 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] remove unused, broken, code dealing with binary packages. remove BugFactory. (patch-2377: bjorn.tillenius@canonical.com) | 10:54 |
| SteveA | an edit form is about manipulating something that is already there | 10:54 |
| SteveA | a remove form, if it existed, would also be about manipulating something that is already there | 10:54 |
| Kinnison | BjornT: binarypackagename didn't change | 10:54 |
| BjornT | Kinnison: well, it's broken (not the parts that malone uses, though), it references the BinaryPackage table | 10:55 |
| sabdfl | SteveA: the problem is that i dont want to choose the thing to remove, BEFORE I display the form | 10:56 |
| sabdfl | here's the detail | 10:56 |
| sabdfl | i'm viewing a CVE | 10:56 |
| sabdfl | I want to go to CVE/+unlinkbug | 10:56 |
| sabdfl | there, I want to see a bug numer input widget | 10:56 |
| sabdfl | when I post that form, if the bug number is one for which there is a bugcve on that cve, it should be deleted | 10:56 |
| Kinnison | BjornT: The sql object? | 10:56 |
| sabdfl | the addform is nice because it allows you to specify the details | 10:57 |
| sabdfl | hence, input the bug number | 10:57 |
| sabdfl | instead of creating a new bugcve, though, i FIND the BugCve, and the destroy it | 10:57 |
| sabdfl | but, the addform then wants to go ahead and add something | 10:57 |
| sabdfl | i just want to get rid of that part | 10:57 |
| BjornT | Kinnison: yeah | 10:58 |
| stub | Because you want to use addform built from the existing IBugCVE schema rather than create a schema to describe your form and use editform? | 10:58 |
| Kinnison | BjornT: make a new entry in the table, thanks for spotting it | 10:58 |
| SteveA | sabdfl: just override createAndAdd and make it do no creating and adding. | 10:58 |
| stub | Mmm... that sounds familiar. | 10:59 |
| SteveA | http://faassen.n--tree.net/blog/view/weblog/2005/09/06/0 <-- faassen says to ignore browser:editform and browser:addform, and use zope.formlib. we can experiment with this in a couple of weeks, when we get the latest zope3. | 11:00 |
| sabdfl | stub: the editform wants to edit an object | 11:00 |
| === jinty [n=jinty@205.134.224.215] has joined #launchpad | ||
| SteveA | the editform wants to edit some data. the data is defined by giving the editform a schema. you can override EditForm.update() to do whatever you want when the form is updated. | 11:02 |
| SteveA | I mean EditView.update() | 11:03 |
| SteveA | it is possible to use EditView as the base class for your own view class, and make it a simple browser:page | 11:03 |
| SteveA | and not a browser:addform or browser:editform | 11:03 |
| SteveA | that gives you a much simpler base to do customizations on | 11:04 |
| SteveA | EditView is in lib/zope/app/form/browser/editview.py | 11:04 |
| === mdke [n=matt@unaffiliated/mdke] has left #launchpad [] | ||
| === mdz [n=mdz@ca-studio-bsr1o-251.vnnyca.adelphia.net] has joined #launchpad | ||
| Kinnison | SteveA: What is the officially accepted way of doing logical xnor in python? | 11:19 |
| SteveA | don't mess with my head before i've had a cup of tea! | 11:20 |
| Kinnison | ddaa gave me ((bool) + (bool)) != 1 | 11:20 |
| SteveA | we love punning | 11:21 |
| Kinnison | we do | 11:22 |
| Kinnison | I've commented the line as (bool) XNOR (bool) | 11:22 |
| Kinnison | just so we know what it's meant to be | 11:22 |
| SteveA | >>> def xnor(a, b): | 11:22 |
| SteveA | ... return (a and b) or (not a and not b) | 11:22 |
| SteveA | ... | 11:22 |
| SteveA | clarity, please | 11:22 |
| Kinnison | Hurrah for single-use clarity methods | 11:23 |
| SteveA | for extra points, put the truth table in the docstring, as a doctest | 11:23 |
| Kinnison | and for minus points, do it as a lambda? | 11:23 |
| SteveA | yes | 11:23 |
| Kinnison | :-( | 11:24 |
| SteveA | no docstring | 11:24 |
| SteveA | and, the confusing word "lambda" | 11:24 |
| SteveA | when it grows up, it'll be a sheepda | 11:24 |
| === Kinnison feels (left and right) or not (left or right) is a clearer xnor than yours | ||
| SteveA | i just ripped it out of wikipedia | 11:25 |
| Kinnison | heh | 11:25 |
| Kinnison | I just scribbled down a truth table | 11:25 |
| SteveA | aha | 11:26 |
| SteveA | (not a ^ b) | 11:26 |
| SteveA | how about that? | 11:26 |
| Kinnison | isn't ^ binary xor ? | 11:27 |
| Kinnison | in which case we're back to punning | 11:27 |
| Kinnison | if xnor(opts.generator is None, opts.intervention is None): | 11:27 |
| Kinnison | that's just dandy | 11:27 |
| SteveA | >>> True ^ False | 11:28 |
| SteveA | True | 11:28 |
| SteveA | so, it does work boolean in a boolean context | 11:28 |
| Kinnison | okay, since it returned a bool | 11:28 |
| SteveA | using the xor function is nice and clear, though | 11:31 |
| SteveA | and i don't suppose speed matters at all here | 11:31 |
| Kinnison | gah | 11:32 |
| Kinnison | it's too late | 11:32 |
| Kinnison | if not ((opts.generator is None) ^ (opts.intervention is None)): | 11:32 |
| Kinnison | and I'm not rewriting that line *AGAIN* | 11:32 |
| SteveA | okay | 11:32 |
| === BjornT [n=bjorn@office.pov.lt] has joined #launchpad | ||
| === cprov [n=cprov@217.205.109.249] has joined #launchpad | ||
| Kinnison | Can everyone please tell lifeless to get a better song? | 12:20 |
| lifeless | dum de dum, dum dum | 12:20 |
| === Kinnison 's brain dribbles out of his ears | ||
| lifeless | drib bib ble, drib le | 12:21 |
| cprov | SteveA: ping | 12:22 |
| SteveA | cprov: pong | 12:22 |
| cprov | SteveA: could you do another quick-review for buildd ? | 12:22 |
| SteveA | ok | 12:23 |
| cprov | SteveA: -> https://chinstrap.ubuntu.com/~dsilvers/paste/fileM8sw8a.html | 12:23 |
| Kinnison | Is there a cheap way to convert a dict of dicts into something with attributes instead of keys? | 12:26 |
| carlos | stub, are you running the migration script on staging already? or are you waiting for my merge? | 12:26 |
| Kinnison | it appears you're not allowed to monkeypatch dict instances :-( | 12:27 |
| stub | carlos: It is running now | 12:27 |
| stub | 24.7005 done (985000 of 3987779). eta 12:26:46.294794 | 12:28 |
| SteveA | Kinnison: kind of | 12:28 |
| carlos | cool | 12:28 |
| carlos | stub, thank you | 12:28 |
| === carlos -> out for a while | ||
| carlos | see you later | 12:28 |
| SteveA | Kinnison: why? adding arbitrary attributes to things is generally a bad idea | 12:28 |
| stub | carlos: Thank kiko - he told me about it ;) | 12:28 |
| carlos | stub, I know | 12:28 |
| carlos | but I was not sure if you were waiting for me to merge my branch or not | 12:28 |
| carlos | and I had some problems adapting the test to the changes asked by kiko | 12:29 |
| Kinnison | SteveA: for code prettiness | 12:29 |
| SteveA | Kinnison: yuck | 12:29 |
| SteveA | Kinnison: arbitrary attribute access is very low-level in python | 12:29 |
| Kinnison | SteveA: self.config.intervention.pretarup is prettier than self.config["intervention"] ["pretarup"] | 12:29 |
| carlos | as you are running it already... I have some time to fix it before merging ;-) | 12:29 |
| === carlos -> out | ||
| === Kinnison shrugs, I'll use ordinary dicts | ||
| SteveA | if you really want to do it, write a wrapper class that implements getattr as a call to __getitem__ | 12:30 |
| SteveA | but, i think it is grim | 12:30 |
| SteveA | now, if that's launchpad.conf you're talking about... | 12:30 |
| Kinnison | it's not | 12:30 |
| Kinnison | but hey :-) | 12:30 |
| SteveA | cprov: reviewed, emailed. approved with some comments. | 12:36 |
| cprov | SteveA: thank you | 12:36 |
| ddaa | Kinnison: I just find "xnor(a, b)" to be more obscure than "bool(a) + bool(b) == 1" | 12:39 |
| ddaa | "bool(a) + bool(b) != 1" even... | 12:40 |
| Kinnison | ddaa: But you're not my reviewer :-) | 12:40 |
| ddaa | SteveA: can I be the reviewer of Kinnison's patch, please? :) | 12:40 |
| === _Rappy_ [n=hunt-pre@dsl-253-122.monet.no] has joined #launchpad | ||
| Kinnison | ddaa: There's klingons on the starboard bow, starboard bow, starboard bow! There's klingons on the starboard bow! Scrape 'em off, jim! | 12:40 |
| lifeless | oneButNotBoth(a, b) | 12:40 |
| === Kinnison loves that noise | ||
| lifeless | or if you extend objects... a.oneButNotBoth(b) | 12:41 |
| SteveA | ddaa: dude, it's a pun. puns are bad. | 12:41 |
| SteveA | lifeless: that's a nice function name, especially for those not familiar with the wealth of logical operators | 12:41 |
| ddaa | "when it grows up, it will be sheepda"... and you say puns are bad... | 12:41 |
| lifeless | SteveA: but nuns are good | 12:41 |
| SteveA | ddaa: i'm not committing that one to code. | 12:41 |
| === Kinnison refers lifeless to http://www.nun.org.uk/ | ||
| SteveA | lifeless: it is a requirement for the job, i hear. | 12:41 |
| ddaa | SteveA: my argument was that the standard (not the common US one) logical diagram notation represents XOR as a box with "=1" inside it. | 12:42 |
| lifeless | ddaa: common in Paris ? | 12:43 |
| cprov | SteveA: -> Why is there a '-' in here? did you mean the UNKNOWN-SUM ? | 12:43 |
| ddaa | lifeless: I said, "standard, not common" | 12:43 |
| SteveA | cprov: yes | 12:43 |
| lifeless | ddaa: so your standard is uncommon ? | 12:43 |
| Kinnison | lifeless: sorry, http://www.nun.org.uk/fetishworks.png | 12:43 |
| === camilotelles [n=Camilo@20132139198.user.veloxzone.com.br] has joined #launchpad | ||
| === ddaa goes back at increasing launchpad value | ||
| Kinnison | lifeless: eitherOr is better than oneButNotBoth | 12:44 |
| cprov | SteveA: it's really not related with the patch, you know it, but I'll change, it's ok | 12:44 |
| lifeless | SteveA: alternatively, 'onlyOneOf(<list>)' | 12:44 |
| lifeless | Kinnison: not for americans or other non english speakers | 12:45 |
| SteveA | cprov: great | 12:45 |
| sivang | sabdfl: ping, 'sup? | 12:46 |
| sivang | sabdfl: I just managed to set up my dialer net connection in breezy, so it seems that all is needed is the right PPTP server addressed and the nameservers per each ISP, what would you say of maybe adding to launchapd an interface in which ISPs can update their data, and then each lunchpad managed distribution can pull this data up into their respective netconnection pkgs.. | 12:48 |
| sivang | could be a nice feature for people in countires in which dialers are mandatory | 12:48 |
| sivang | (Like .IL for example) | 12:48 |
| === Lovechild [n=dnielsen@love-sources/Lovechild] has joined #launchpad | ||
| lifeless | SteveA: ping | 12:52 |
| SteveA | hi | 12:52 |
| lifeless | the pythno problem-files have precisely two revisions. | 12:52 |
| lifeless | one in 1998-08-18, Initial revision by jack. | 12:53 |
| SteveA | these are the ones with the stupid filenames? | 12:53 |
| lifeless | and one to delete them in 1999-02-01 'removed old IDE stuff -- jvr' by just | 12:53 |
| lifeless | yes | 12:53 |
| === Keybuk [n=scott@syndicate.netsplit.com] has joined #launchpad | ||
| SteveA | okay | 12:53 |
| SteveA | so, junk | 12:53 |
| lifeless | I'm inclined to just Filter them out and report that. | 12:53 |
| lifeless | do yo uthink the python community will care ? | 12:54 |
| SteveA | no | 12:54 |
| SteveA | ancient history | 12:54 |
| lifeless | cool | 12:54 |
| SteveA | and junk | 12:54 |
| === mdz [n=mdz@ca-studio-bsr1o-251.vnnyca.adelphia.net] has joined #launchpad | ||
| SteveA | hardly even worth mentioning | 12:54 |
| lifeless | ok. | 12:54 |
| SteveA | spiv: ping | 01:03 |
| Kinnison | I: Base system installed successfully. | 01:12 |
| Kinnison | just like me, it longs to be, debootstrapped | 01:12 |
| Kinnison | :-) | 01:12 |
| === mdke [n=matt@unaffiliated/mdke] has joined #launchpad | ||
| lifeless | this after you turn down a office whipping | 01:13 |
| lifeless | such _mixed_ signals | 01:13 |
| === Kinnison likes to keep you on your toes | ||
| lifeless | promises promises | 01:14 |
| jordi | sabdfl: for Xfce, would it make sense to create a new translators group? | 01:15 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] correct computation of month bounds when timezone is not UTC (patch-2378: james.henstridge@canonical.com) | 01:20 |
| lifeless | SteveA: how do I tell if a python string has non 7-bit ascii characters ? | 01:31 |
| Kinnison | str.encode("ascii") and trap the exception? | 01:31 |
| lifeless | thanks | 01:32 |
| Kinnison | or, len([c for c in string if ord(c) > 127] ) | 01:32 |
| Kinnison | which may, or may not, be faster | 01:32 |
| SteveA | Kinnison: bool, not len | 01:38 |
| Kinnison | prollobolee | 01:38 |
| === Kinnison shrugs | ||
| Kinnison | 12:40 < mjg59> I like Tom Lord | 01:40 |
| Kinnison | 12:40 < mjg59> He's charmingly mad | 01:40 |
| === Kinnison snorts | ||
| SteveA | jamesh: ping | 01:42 |
| jamesh | SteveA: yeah? | 01:46 |
| SteveA | do you know the exact url that the "get help" app menu item will go to? | 01:46 |
| SteveA | oh, it's okay, i have it | 01:46 |
| lifeless | jamesh: has the lp gpg stuff hlanded yet ? | 01:47 |
| jamesh | SteveA: sourcepackage-gethelp.pt is the page template | 01:47 |
| lifeless | jamesh: and what did you think of the pendingreviews work ? | 01:47 |
| SteveA | jamesh: yeah, i wanted to check that it would go do 'breezy' and not 'hoary' | 01:48 |
| jordi | is anyone feels like fixing a trivial bug, https://launchpad.net/malone/bugs/1857 :) | 01:48 |
| jordi | it's been bugging me for a while | 01:48 |
| jamesh | lifeless: looks okay. I'll merge it soon. | 01:49 |
| lifeless | jamesh: sweet | 01:49 |
| lifeless | jamesh: I'll feed you updates if there are bzr api changes (there will be) | 01:49 |
| jamesh | SteveA: it uses the "lsb_release --codename" command to pick the distrorelease name | 01:49 |
| jamesh | SteveA: so it does the right thing whichever release you are using | 01:50 |
| jamesh | it'd potentially work for distros other than Ubuntu, provided lsb_release gives the right info | 01:50 |
| === cprov [n=cprov@217.205.109.249] has joined #launchpad | ||
| === Seveas [n=seveas@ksl403-uva-132.wireless.uva.nl] has joined #launchpad | ||
| === niemeyer [n=niemeyer@200.103.244.36] has joined #launchpad | ||
| === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad | ||
| niemeyer | Good morning! | 02:14 |
| Keybuk | heyhey | 02:15 |
| salgado | Kinnison, around? | 02:33 |
| Kinnison | salgado: yo | 02:36 |
| Kinnison | lifeless: mmm, napples | 02:36 |
| salgado | hi Kinnison. I forgot what we discussed about that columns that were missing notNulls... binarypackagerelease.{essential, architecturespecific} must have a notNull=True. is that right? | 02:37 |
| Kinnison | yep, that's what we decided | 02:37 |
| lifeless | niemeyer: morning | 02:37 |
| lifeless | ddaa: niemeyer is here, you should confirm dates | 02:38 |
| lifeless | ddaa: love the siren | 02:38 |
| lifeless | ddaa: I could do this all day | 02:38 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] handle +translate and +gethelp pages of sourcepackages that do not exist in a particular distrorelease by displaying the comingsoon page instead of giving a 404. (patch-2379: steve.alexander@canonical.com) | 02:38 |
| Kinnison | lifeless: There's klingons on the starboard bow, starboard bow, starboard bow! There's klingons on the starboard bow! Scrape 'em off, ddaa! | 02:39 |
| Kinnison | ddaa: http://10.90.90.199/Music/Misc/Star%20Trekkin&.mp3 | 02:40 |
| Kinnison | lifeless: check out ddaa's facial expression | 02:41 |
| niemeyer | lifeless: Good morning | 02:43 |
| lifeless | niemeyer: how are you ? ready for the trip ? | 02:43 |
| niemeyer | lifeless: Do you have an idea about how much money do we need for one week in London? | 02:43 |
| niemeyer | lifeless: Almost ready | 02:44 |
| lifeless | we have room and breakfast paid for | 02:44 |
| lifeless | you'll need about 20 pounds for transport | 02:44 |
| lifeless | and there is an allowance fo 15pounds a day for lunch and dinner combined, but that is expensed so you get it back later | 02:44 |
| lifeless | so add that all up :) | 02:45 |
| ddaa | and about 50 pounds for the occasional extra (beer, more expensive food, etc.) | 02:45 |
| ddaa | food in london is insanely expensive, it's _very_ easy to overdue the dinner allowance | 02:45 |
| ddaa | * to overdo | 02:45 |
| === Seveas [n=seveas@ksl403-uva-132.wireless.uva.nl] has joined #launchpad | ||
| niemeyer | 200 pounds should probably make it then.. | 02:46 |
| ddaa | 100 should be more than enough | 02:47 |
| ddaa | niemeyer: I need to book my plane tickets. When are you flying to Montreal (so I'll try to book in the same plane, or as close as possible), and when and where would you like me to land in Brazil? | 02:48 |
| lifeless | you should spend 1 week with niemeyer in brazil before heading to montreal | 02:49 |
| === niemeyer checks | ||
| niemeyer | ddaa: | 02:51 |
| niemeyer | > 25 OCT - GRU - EWR - 2210 - 0600 +1 | 02:51 |
| niemeyer | > 26 OCT - EWR - YUL - 0725 - 0850 | 02:51 |
| niemeyer | That's the flight to Montreal | 02:51 |
| === ddaa got too used to direct flights... | ||
| ddaa | niemeyer: you are taking leave days on 27, 28, 31 and 1st nov? | 02:53 |
| ddaa | (or maybe only the first three...) | 02:54 |
| niemeyer | ddaa: Huh? | 02:55 |
| ddaa | You are expected in Montreal on Nov. 1st | 02:55 |
| niemeyer | ddaa: Ah, no, I'm going to be there for the two weeks. | 02:56 |
| ddaa | I'm was asking whether you took the days between your arrival and Nov. 1st as leave or if you plan to be working. | 02:56 |
| ddaa | That's not what the wiki says... | 02:56 |
| ddaa | When you are going to be there and when you are required are two different things. | 02:57 |
| ddaa | So, I want to know if the early time in Montreal will be a leave for you, or if it will be working time. So we can figure out when I should arrive. | 02:58 |
| lifeless | ddaa: are you not going to brazil ? | 02:59 |
| ddaa | When I should I brazil, I mean. | 02:59 |
| lifeless | ddaa: if you are going to brazil, all the matters is that you arrive on the 16th or so | 02:59 |
| lifeless | 1 week before the date you leave. | 02:59 |
| ddaa | I'm moderately enthusiast at the perpective of extending the away time by two full weeks. | 03:00 |
| ddaa | * enthusiastic | 03:00 |
| === spiv [n=andrew@adsl-66-203.swiftdsl.com.au] has joined #launchpad | ||
| niemeyer | ddaa: Ok, I'll check that.. | 03:01 |
| ddaa | so, if niemeyer does not take the time between his early arrival and the beginning of the LP team sprint as leave to enjoy the area, I'd rather try to use these days for the HCTLaunchpad sprint | 03:02 |
| ddaa | otherwise, I guess I will have to take these as leave as well. | 03:03 |
| ddaa | niemeyer: okay, tell me when you've decided whether you want to spend those early days in montreal on the sprint or on something else. I am already overdue for my plane bookings. | 03:06 |
| niemeyer | ddaa: I'm not planning any leaves.. | 03:06 |
| lifeless | ah I see | 03:07 |
| lifeless | niemeyer: I think you booked slightly early :0). We're just updating things | 03:07 |
| niemeyer | lifeless: Understood.. that's the case indeed. Will check the flights again. | 03:11 |
| spiv | SteveA: pong | 03:11 |
| SteveA | hi andrw | 03:12 |
| SteveA | i pinged you about an sqlobject issue, but i sent a mail to the list anyway. | 03:12 |
| === cprov [n=cprov@217.205.109.249] has joined #launchpad | ||
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=stevea] Fixing Buildd-Slave process termination workflow (patch-2380: celso.providelo@canonical.com) | 03:15 |
| === kiko-zzz [n=kiko@200-171-140-32.dsl.telesp.net.br] has joined #launchpad | ||
| SteveA | kiko: ping | 03:22 |
| kiko | carlos, carlos, carlos | 03:26 |
| carlos | kiko, kiko, kiko | 03:29 |
| carlos | kiko, I'm going to have lunch now | 03:29 |
| carlos | will talk when I'm back, ok? | 03:29 |
| kiko | one sec though | 03:30 |
| kiko | carlos, just confirm with me: stub's running the updated script, correct? | 03:30 |
| carlos | kiko, right | 03:31 |
| kiko | and okay with the review I sent? | 03:31 |
| kiko | stub granted me RO access to the database | 03:32 |
| kiko | so I can generate the new language packs IF you put up a wikipage explaining exactly how they are built | 03:32 |
| SteveA | mpt: ping | 03:36 |
| mpt | SteveA: pong | 03:42 |
| === otep [n=otep@AP-203.167.31.177.sysads.com] has joined #launchpad | ||
| === lamont [n=lamont@15.238.5.62] has joined #launchpad | ||
| === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has joined #launchpad | ||
| mpt | woo, 17 conflicts | 03:50 |
| jbailey | jordi: Around? | 03:52 |
| Keybuk | niemeyer: about? | 03:58 |
| niemeyer | Keybuk: Pong | 04:00 |
| sabdfl | carlos: are you landing a fix for the pofile menus? | 04:01 |
| carlos | sabdfl, I landed a fix for the upload/download last week, nothing more | 04:01 |
| Keybuk | niemeyer: busy? | 04:01 |
| sabdfl | carlos: staging doesn't look right | 04:01 |
| niemeyer | Keybuk: Nothing that couldn't be interrupted | 04:02 |
| Kinnison | ciao dudes, lunchtastic | 04:02 |
| Keybuk | I thought I might take half an hour to explain how Sourcerer works | 04:02 |
| carlos | sabdfl, I know, I added the old action links. I don't know why the new layout is not working | 04:02 |
| niemeyer | Keybuk: Perfect! | 04:02 |
| carlos | sabdfl, In fact I thought those new menu tabs were removed until mpt told me that it was a css change | 04:02 |
| niemeyer | Keybuk: I'm working on it, so it'll be great indeed. | 04:02 |
| niemeyer | Keybuk: Interrupt me whenever you want. ;)) | 04:03 |
| Keybuk | ok | 04:03 |
| Keybuk | so the basic class in Sourcerer is Inventory | 04:03 |
| Keybuk | think of it as simply a list of items that are sub-classes of InventoryItem | 04:03 |
| Keybuk | the job of sourcerer can be summed up as | 04:04 |
| Keybuk | 1) turn a bunch of files on disk into an Inventory, and a set of matching directories of source | 04:04 |
| carlos | kiko, the review is ok. The test is taking me much more time than the code changes.... it's not so easy to test those new methods as part of POTMsgSet... | 04:04 |
| Keybuk | 2) match InventoryPatchItems to their parents; match them to their counterpart Manifest*Entry objects in the previous release and general clean-up | 04:05 |
| Keybuk | 3) product a Manifest from the Inventory | 04:05 |
| kiko | carlos, well, as I said, you could just XXX it, and fix it later -- we don't want you to lose time over this | 04:05 |
| kiko | there are other battles to fight | 04:05 |
| Keybuk | the code for #2 and #3 are in the Inventory class, and InventoryItem classes | 04:05 |
| carlos | kiko, it's done, is the test the only thing that gives me problems | 04:05 |
| niemeyer | Keybuk: Ok | 04:06 |
| Keybuk | and are pretty much intended to be generic across the board. Once you have an Inventory, you do the same job on it [ inv.priorManifest(old_manifest); inv.prepareImport(); new_manifest = inv.createManifest() ] | 04:06 |
| Keybuk | you can see those calls in sourcerer.bubblewrap | 04:06 |
| niemeyer | Keybuk: Yes, I did that yesterday, and created a xml manifest using xmlfiles | 04:06 |
| Keybuk | yup | 04:06 |
| Keybuk | so if you look through Inventory, some of the noteworthy functions | 04:07 |
| Keybuk | Inventory.priorManifest, InventoryItem.matchingManifestEntry and InventoryItem.priorManifestEntry | 04:07 |
| Keybuk | these deal with matching up an InventoryItem to an equivalent ManifestEntry in the previous version | 04:08 |
| Keybuk | it's pretty simple -- if it's the same type with roughly the same path, we assume it's the same | 04:08 |
| niemeyer | Right | 04:08 |
| carlos | kiko, and anyway, the tests are working now... | 04:08 |
| Keybuk | Inventory.parentItems, Inventory.orphanItems, Inventory.matchOrphansToParents, Inventory.matchItems, Inventory.removeOrphans, InventoryItem.canBeParent, InventoryItem.isOrphan, InventoryItem.isParent, InventoryItem.tryParet | 04:09 |
| Keybuk | those all deal with matching patches up to their parent item | 04:10 |
| Keybuk | basically it's try every patch with every possible parent (where parents can include patches with known parents) until it applies without problem | 04:10 |
| niemeyer | That's a tricky part | 04:10 |
| Keybuk | yeah, basically you have | 04:10 |
| Keybuk | parents: items that can be the parent to a patch. This is "solid" things like a tar file, a zip file, a directory of source, etc. something we don't need to build | 04:10 |
| niemeyer | Keybuk: What do you do with "unknown" cases? | 04:11 |
| Keybuk | orphans: items that _need_ a parent. This is just "patches" at the moment -- but later we might make changesets or xdeltas, etc. | 04:11 |
| niemeyer | Ok | 04:11 |
| === bradb jumps on the double-digit conflict bandwagon | ||
| Keybuk | now if you look at the parentItems function, it actually tries to order them intelligently using the "hints" for each item (more on these later) | 04:12 |
| Keybuk | so basically it uses the "this is what patches will apply to" hint as the first one to try | 04:12 |
| Keybuk | and we look through those lists through Inventory.matchItems | 04:12 |
| Keybuk | which puts successful matches back onto the parents list for the next try | 04:12 |
| Keybuk | rinse, repeat, until we have no more parents to try | 04:12 |
| Keybuk | if we have orphans left over, we remove their inventory items -- we can't import them. but by doing this we _don't_ remove the actual patch file later, which means that the patch is just imported in the parent as-is | 04:13 |
| Keybuk | so instead of an empty "patches" directory with a branch for the patch file inside it | 04:13 |
| Keybuk | you see a "patches" directory with a checked in, version-controlled, patch file | 04:13 |
| Keybuk | every instance I've seen so far, it's been a patch that actually doesn't apply and is obsolete and left in the source because the maintainer didn't bother removing it | 04:14 |
| niemeyer | Humm.. | 04:14 |
| niemeyer | One case that comes into my mind is a -p0 patch adding a new file. | 04:14 |
| Keybuk | yeah, those work for everything <g> fortunately we default to applying it to the .diff.gz (in Debian's case) so the result is almost always right | 04:15 |
| Keybuk | if we get it slightly wrong, it's ok -- the user can fix it up with hct later | 04:15 |
| niemeyer | Understood | 04:15 |
| Keybuk | we now have an Inventory with matched up patches and parents hopefully | 04:16 |
| Keybuk | so we go and make sure that it exists on the disk in the right state -- that's the Inventory.placeInLibrary, Inventory.cleanLibrary, InventoryItem.placeInLibrary functions | 04:16 |
| Keybuk | in effect, we have a directory for each InventoryItem which contains a clean copy of the source we want to import for it | 04:17 |
| Keybuk | (ie. with files-that-will-be-branches removed and stuff) | 04:17 |
| Keybuk | (note that Library in HCT terms doesn't refer to the Launchpad Librarian -- spiv stole my term) | 04:18 |
| Keybuk | a Library (hct.util.library) is just a managed temp directory | 04:18 |
| niemeyer | Yes.. it's a directory where files are expanded. | 04:18 |
| niemeyer | Interesting concept :) | 04:18 |
| Keybuk | ok, so the final thing we do is call Inventory.createManifest (which calls InventoryItem.createManifestEntry and InventoryItem.createBranch) | 04:19 |
| niemeyer | But TempDir would be a better name, I think.. ;)) | 04:19 |
| Keybuk | this creates a Manifest object and lots of Manifest*Entry objects in it that look and smell exactly like the Inventory ones | 04:19 |
| Keybuk | but also does the job of actually making the baz branches, doing the import, etc. | 04:19 |
| Keybuk | the end result is something we can use with HCT | 04:20 |
| niemeyer | Cool | 04:20 |
| Keybuk | so that's stages #2 and #3 of Sourcerer, we entirely skipped stage #1 | 04:20 |
| Keybuk | which is perhaps the "interesting" bit | 04:20 |
| niemeyer | Who handles the actual import procedure? I mean, someone has to take care about moving the new files into the correct old files, and removing unexistent old files, right? | 04:21 |
| niemeyer | Or perhaps baz already has some smartness for that? | 04:21 |
| Keybuk | most of that is done by HCT -- at this point Sourcerer just acts like an HCT client and does "working_tree.importFrom(library_dir)" | 04:21 |
| Keybuk | that's hct.workingtree.WorkingTree.importFrom | 04:21 |
| niemeyer | Ok | 04:21 |
| Keybuk | (hct has an equivalent to baz import) | 04:21 |
| Keybuk | so, stage #1 | 04:22 |
| Keybuk | turn a bunch of files on the disk into an Inventory | 04:22 |
| niemeyer | Inspect! | 04:22 |
| Keybuk | this is partly specific to a source format, and partly generic base classes that can be overriden | 04:22 |
| Keybuk | and yup, that's what Inspector is all about | 04:22 |
| Keybuk | the base class here is the Inspector | 04:23 |
| Keybuk | there are sub-classes to deal with particular file-types; TarInspector, ZipInspector, PatchInspector, etc. | 04:23 |
| Keybuk | the job of an inspector is to open up the file, get it onto disk if it can, go through the contents, identify any other special files within it, and instantiate a new Inspector for those | 04:23 |
| Keybuk | pretty much, instantiating any Inspector sub-class does this | 04:24 |
| Keybuk | note that for a patch, we must _already_know_ at this point what its parent is and prune level -- so this is only really useful for things like the .diff.gz | 04:24 |
| niemeyer | Keybuk: It will inspect the patch itself, or the full tree with the patch applied? | 04:25 |
| Keybuk | it inspects the patch itself | 04:25 |
| Keybuk | the full tree is useful if we find other things in it, only | 04:25 |
| Keybuk | the *Inspector classes are pretty trivial, and hopefully obvious in how they work | 04:26 |
| Keybuk | their job is to create an Inventory of that file | 04:26 |
| Keybuk | and they do this in partnership with another class, FileInventory | 04:26 |
| niemeyer | So, they get a orig.tar.gz, and find the patches inside it. Is that the case? | 04:26 |
| Keybuk | yup | 04:26 |
| niemeyer | Ok.. it didn't sound obvious at first because rpms are a bit different in that sense. | 04:26 |
| Keybuk | when an Inspector starts, it calls FileInventory.start(); for each "interesting file/dir/etc." it finds inside it, it calls FileInventory.append*(); and when done it calls FileInventory.finish() | 04:27 |
| Keybuk | you always have an Inspector/FileInventory pair | 04:27 |
| niemeyer | I don't think a Inspector would be needed for rpms, since the interesting content is always "outside". | 04:27 |
| Keybuk | in fact, if you look at the inspect() example function at the bottom, it instantiates a FileInventory then the Inspector and couples them | 04:28 |
| niemeyer | We just need one, perhaps, that will inspect SRPM files. | 04:28 |
| Keybuk | right | 04:28 |
| Keybuk | the job of FileInventory is to decide whether what the Inspector has found it useful or not | 04:28 |
| niemeyer | ... and store it, if it is. | 04:28 |
| Keybuk | and to make InventoryItem objects for useful things, and ignore non-useful ones | 04:28 |
| Keybuk | yup | 04:28 |
| Keybuk | there's stuff in there to turn a filename into something "Inventory-local" | 04:28 |
| Keybuk | if you look at the bottom of debian.py, you'll see there's actually a FileInventory sub-class it uses which grabs out the top-level debian/ directory and turns it into the packaging item | 04:29 |
| === niemeyer checks | ||
| niemeyer | Nice! | 04:30 |
| Keybuk | (it's almost all doc-string, that class) | 04:30 |
| Keybuk | so now we have a generic framework for inspecting any kind of file, and making a chain of InventoryItems out of it | 04:31 |
| niemeyer | Keybuk: Yes, very well documented. | 04:31 |
| Keybuk | we still need an uber-object to actually make a complete Inventory of the lot, as well as pick out the files to inspect | 04:31 |
| Keybuk | the simplest of those is upstream.py | 04:31 |
| Keybuk | UpstreamInventory just picks the appropriate Inspector class, matches it with a FileInventory object it creates, and takes the items out of it it [ self.extend(contents) ] | 04:32 |
| Keybuk | so if you want a Manifest of any zip or tar file you have on disk; that's what you use | 04:33 |
| carlos | kiko, ping | 04:33 |
| Keybuk | there's one little bit on the end of that, the branchPolicy() function -- this has the job of setting the name and hint for any interesting things in the inventory | 04:33 |
| Keybuk | it always just sets the first item to ORIGINAL_SOURCE and suggests --release-- for the branch name | 04:34 |
| niemeyer | Ahh, so that's what model.name is | 04:35 |
| Keybuk | yeah, I'll get to models in about 10 minutes <g> | 04:35 |
| niemeyer | :) | 04:35 |
| Keybuk | so, UpstreamInventory gives us the inventory of a simple one-file sourec | 04:35 |
| Keybuk | DebianInventory (in debian.py) is along the same lines, but a bit more complex | 04:36 |
| Keybuk | it possibly has to inspect two files (.orig.tar.gz and .diff.gz) | 04:36 |
| Keybuk | and the branchPolicy function is actually quite involved | 04:36 |
| Keybuk | with various hints and names that can be assigned to different bits | 04:36 |
| Keybuk | and even more wild, it actually reforms the Inventory sometimes | 04:37 |
| Keybuk | if we were to leave the inventory as-is, we'd end up creating an .orig.tar.gz and a .diff.gz -- which while exactly what we saw, aren't the best form for distro people -- they expect an .orig.tar.gz and an unpacked directory | 04:37 |
| Keybuk | so we mutate the inventory to turn the diff into an InventoryCopyItem instead, and rename/move all the children of that about | 04:38 |
| niemeyer | Makes a lot of sense | 04:38 |
| Keybuk | on top of all that is bubblewrap | 04:38 |
| Keybuk | it picks either UpstreamInventory or DebianInventory, runs the functions in the right order to make a Manfiest and saves it to the HCT URL given | 04:39 |
| Keybuk | it takes away the sharp-edges | 04:39 |
| niemeyer | "Copy" is how the assembled tree will be generated out of the baz/bzr branch, right? | 04:39 |
| Keybuk | right, a Manifest consisting entirely of ManifestCopyEntry objects is basically an arch config | 04:40 |
| niemeyer | Interesting | 04:40 |
| bradb | sabdfl: Just a note that because I've changed everything to be registered on IBugTask instead of IBug now, anything that you do that involves registering things against those interfaces or writing ZPT against those APIs as their context, or traverser code that traverses IBug or IBugTask will give me a lot of hard-to-resolve conflicts. | 04:40 |
| Keybuk | ok, so musings on how to do an SRPM importer with this model | 04:40 |
| Keybuk | you could create an SrpmInspector which knows how to unpack them, spread the contents on disk, and inherently cause those contents to be inspected (because that's implicit) | 04:41 |
| Keybuk | and then an SprmInventory class which just instantiated an SprmInspector/FileInventory pair and applied branchPolicy afterwards | 04:41 |
| Keybuk | most of the code to do that can be c&p from the old rpm.py -- it just happens to predate this cute model of doing imports | 04:42 |
| Keybuk | (in particular rpm.py still contains its own "patch dating" code, before I ripped it off into the generic core) | 04:42 |
| === lifeless gets nervous at cute code | ||
| lifeless | s/at/around | 04:42 |
| Keybuk | lifeless: dude, you helped design it | 04:42 |
| Keybuk | you sat me down on your knee and taught me about programming patterns, and unit tests, and stuff | 04:42 |
| lifeless | Keybuk: run and hide, run and hide! | 04:42 |
| Kinnison | Keybuk: you sat on lifeless' knee? | 04:43 |
| Keybuk | waayyyyyyy back in August last year | 04:43 |
| Kinnison | that explains a lot | 04:43 |
| lifeless | Keybuk: I'm just teasing. Don't you get nervous around cute things ? | 04:43 |
| Keybuk | lifeless: no, I get horny | 04:43 |
| === Kinnison nods | ||
| lifeless | they are not exclusive y'know :) | 04:43 |
| Keybuk | niemeyer: anyway, dodging the peanuts from the gallery for a minute ... | 04:43 |
| === lifeless launches a lolly goblet | ||
| Keybuk | most of the code in rpm.py can be thrown away in favour of the generic core -- and c&p to turn it into an SrpmInspector class instead | 04:44 |
| Keybuk | or, if you prefer, you could just write the "unpack an srpm, spread it out and inspect the pieces" code in SrpmInventory itself | 04:44 |
| niemeyer | Ok | 04:44 |
| Keybuk | (there's no DebianSourceInspector, for example) | 04:44 |
| Keybuk | I'm not actually sure which would be easier | 04:45 |
| niemeyer | I'll figure it out :) | 04:45 |
| Keybuk | I suspect SrpmInspector is easier, because you just have to write the "open an srpm", "list the contents of an srpm" and "put the contents on disk somewhere" functions | 04:45 |
| Keybuk | the Inspector stuff takes care of the rest for you | 04:45 |
| niemeyer | I was thinking about building an assembled tree which would match the format expected by rpmbuild (SOURCES/*, SPECS/*.spec, etc). | 04:45 |
| Keybuk | yup | 04:46 |
| niemeyer | Keybuk: Is that what you had in mind? | 04:46 |
| Keybuk | so Manifest output expectations | 04:46 |
| Keybuk | don't bother trying to replicate the two-level Debian format -- that's actually going away with W&P | 04:46 |
| Keybuk | SOURCES/<tar file name> | 04:46 |
| Keybuk | PATCHES/<patch name> | 04:46 |
| niemeyer | Nice! | 04:46 |
| Keybuk | SPECS/<spec name> (btw... InventoryFileItem/ManifestFileItem is what you want for this) | 04:46 |
| Keybuk | is one possibility | 04:47 |
| Keybuk | though, to be entirely honest, I'd actually suggest just doing: | 04:47 |
| Keybuk | <tar file name> | 04:47 |
| Keybuk | <patch name> | 04:47 |
| Keybuk | <spec name> | 04:47 |
| Keybuk | it's up to you though, either way would work well | 04:47 |
| Keybuk | making them match rpmbuild has plus points, so does making them flat | 04:48 |
| Keybuk | you can pick | 04:48 |
| niemeyer | Are you talking about the assembled tree or the branches? | 04:48 |
| Keybuk | the assembled tree looks like the "path" entry for each ManifestEntry | 04:48 |
| Keybuk | I'm talking about the contents of the path field :) | 04:48 |
| niemeyer | :) | 04:48 |
| Keybuk | ok, so almost exactly 10 minutes later | 04:49 |
| Keybuk | a quick recap on the fields of Manifest, I think you probably know all of these by now, but just making sure | 04:49 |
| Keybuk | path -- where it goes in the assembled tree | 04:49 |
| Keybuk | Debian sources have an icky "source-1.0/debian/patches/01-fix-something.patch" format for this | 04:49 |
| ddaa | Keybuk: is any of your stuff using foreign keys to the changeset table? | 04:50 |
| Keybuk | but it means it gets assembled in the right format for dpkg-buildpackage | 04:50 |
| Keybuk | ddaa: yes, ManifestEntry | 04:50 |
| mpt | SteveA: Should class SourcePackageFacets(StandardLaunchpadFacets): exist any more? | 04:50 |
| SteveA | mpt: ping again | 04:50 |
| Keybuk | hint -- this is a ManifestEntryHint | 04:50 |
| Keybuk | ORIGINAL_SOURCE = reserved for the original, unmodified source tarball | 04:50 |
| mpt | (10:36:27) SteveA: mpt: ping | 04:50 |
| mpt | (10:42:31) mpt: SteveA: pong | 04:50 |
| Keybuk | PATCH_BASE = default base for new patches (if the user doesn't specify one) | 04:50 |
| Keybuk | (give it to the major source tarball of the package) | 04:51 |
| SteveA | mpt: yep, just came back from lunch | 04:51 |
| Keybuk | PACKAGING = for you, the spec item | 04:51 |
| Keybuk | dirname -- this isn't anything to do with path; this is the directory name that gets encoded _inside_ the tarball, zip or patch | 04:51 |
| jbailey | Keybuk: How does get_source notice that you've added something to hct? Does it rely on a new version of get_source being added, or is it just waiting for your script to do the import? | 04:51 |
| Keybuk | a Entry with path="foo/bar-1.0.tar.gz" and dirname="wibble-1.0/" would create foo/bar-1.0.tar.gz which when unpacked puts all the files under wibble-1.0/ | 04:52 |
| === jinty [n=jinty@205.134.224.215] has joined #launchpad | ||
| mpt | SteveA: The reason I ask is that I found two copies of it in browser/sourcepackage.py, probably a bad merge | 04:52 |
| ddaa | Keybuk: is that precious data, or can you regenerate it? | 04:52 |
| Keybuk | for patches, this is also the major hint as to the -pX date | 04:52 |
| Keybuk | ddaa: precious | 04:52 |
| SteveA | almost certainly a bad merge | 04:52 |
| Keybuk | jbailey: grabs the list once a day | 04:53 |
| niemeyer | Keybuk: Gotcha | 04:53 |
| Keybuk | (and sourcerer uses the same list to do the imports) | 04:53 |
| mpt | SteveA: So, should it exist at all, or not? | 04:53 |
| Keybuk | niemeyer: finally there's branch and changeset (ooh look, two of the conversations just merged <g>) | 04:53 |
| Keybuk | branch is the arch branch we need to checkout | 04:53 |
| SteveA | mpt: i expect it should exist. | 04:53 |
| Keybuk | and changeset is the actual changeset on that branch | 04:53 |
| mpt | ok | 04:53 |
| Keybuk | because sources can share a branch, changeset is important -- it tells us whether to checkout --patch-1 or --patch-9 of the debian/ directory | 04:54 |
| ddaa | Keybuk: in production, all the ManifestEntry.changeset are NULL | 04:54 |
| Keybuk | as well as /any/ other piece of the source | 04:54 |
| jbailey | Keybuk: 'kay. I'll be more patient then. =) | 04:54 |
| Keybuk | ddaa: there's no imports in production, so I'm rather surprised if there's any ManifestEntry records at all | 04:54 |
| Nafallo | carlos, jordi: seahorse is not translatable? | 04:54 |
| lifeless | allo allo allo | 04:55 |
| lifeless | whats up ? | 04:55 |
| Keybuk | launchpad_hct=# select count(*) from manifestentry; | 04:55 |
| Keybuk | 5250 | 04:55 |
| Keybuk | launchpad_hct=# select count(*) from manifestentry where changeset=null; | 04:55 |
| ddaa | we would like to be able to DROP TABLE Changeset as part of the BranchDataStorage (because we are removing Changeset.branch and that would be annoying to convert) | 04:55 |
| Keybuk | 0 | 04:55 |
| lifeless | hang ong | 04:55 |
| lifeless | this discussion, if its what I think it is is premature. | 04:55 |
| lifeless | ddaa: in production, its safe to drop the changesets as tey are nmot referenced yet. | 04:56 |
| Keybuk | sorry | 04:56 |
| Keybuk | launchpad_hct=# select count(*) from manifestentry where changeset is null; | 04:56 |
| Keybuk | 111 | 04:56 |
| Keybuk | <g> me learns SQL again | 04:56 |
| lifeless | Keybuk: we'll be talking next weelk aboutthe impact on hct, you me mark neimeyer | 04:56 |
| Keybuk | lifeless: that's cool | 04:56 |
| Keybuk | I suspect it will be "replace changeset with revno" or something | 04:56 |
| ddaa | lifeless: ack, but I wanted to check because "yet" tends to have very changing values. | 04:56 |
| Keybuk | or "don't update casey to the latest db yet" | 04:56 |
| lifeless | Keybuk: right. that would be bad. | 04:56 |
| Keybuk | (back to the lecture) | 04:57 |
| ddaa | Keybuk: something like that, Changeset -> Revision and Changeset.branch -> RevisionNumber table | 04:57 |
| Keybuk | niemeyer: so, that's ManifestEntry's properties ... ManiefstPatchEntry also has an extra "patch_on" field that tells us what the patch gets applied to; or should be diff'd from | 04:57 |
| Keybuk | that's actually a reference to the ManifestEntry object, rather than a number or anything | 04:57 |
| Keybuk | in the database we use sequence numbers to replicate that | 04:58 |
| Keybuk | ddaa: works for me | 04:58 |
| ddaa | lifeless: so, IIUC I should not DROP TABLE but DELETE everything. | 04:58 |
| niemeyer | Keybuk: Understood | 05:00 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: Change u'\u2022' with a space character automatically. r=kiko (patch-2381: carlos.perello@canonical.com) | 05:01 |
| lifeless | ddaa: yes, DELETE FROM REVISION | 05:02 |
| Keybuk | niemeyer: right, now if you look at InventoryItem you'll see it basically has the same properties | 05:06 |
| Keybuk | but with a few variations | 05:06 |
| Keybuk | parent_item <~> patch_on (actually ManifestEntry will probably become parent_item soon because of a bug I found :p) | 05:06 |
| Keybuk | virtual instead of branch/changeset -- at Inventory time, we don't yet have the branches; we just need to know whether or not we make branches | 05:07 |
| Keybuk | a virtual item is one that we need to assemble, but doesn't actually have a branch of its own -- a typical example is an .orig.tar.gz that only contains other tarballs -- no point checking in something empty | 05:07 |
| niemeyer | Hummm.. interesting. Wasn't aware about those. | 05:08 |
| Keybuk | there's also prefix, which is the common path of everything inside it -- this is used to generate dirname, and regenerate it if we change our minds later | 05:08 |
| Keybuk | yeah | 05:08 |
| Keybuk | virtual items pretty much only show up in Debian | 05:08 |
| Keybuk | you can do tricks like this | 05:08 |
| Keybuk | path="foo.tar.gz", virtual=True | 05:09 |
| Keybuk | path="foo.tar.gz/other1.tar.gz", virtual=False | 05:09 |
| Keybuk | path="foo.tar.gz/other2.tar.gz", virtual=False | 05:09 |
| Keybuk | other1 and other2 will be imported as branches | 05:09 |
| Keybuk | hct assemble will create just a foo.tar.gz file | 05:09 |
| Keybuk | which when unpacked gives you other1.tar.gz and other2.tar.gz files | 05:09 |
| niemeyer | Ohh! Cool :) | 05:09 |
| Keybuk | which when unpacked give you their respective branches | 05:09 |
| Keybuk | (the path of any entry/item can be relative to the path of another ... which means it gets assembled inside it) | 05:10 |
| Keybuk | consider | 05:10 |
| Keybuk | foo-1.0/debian/, virtual=False (--packaging--) | 05:10 |
| Keybuk | foo-1.0/debian/patches/01-something.patch, virtual=False | 05:10 |
| Keybuk | foo-1.0/debian/patches/02-something.patch, virtual=False | 05:10 |
| === cprov [n=cprov@217.205.109.249] has joined #launchpad | ||
| Keybuk | the patches/01-something.patch and patches/02-something.patch are assembled inside the debian (packaging) directory before that is put in place | 05:11 |
| Keybuk | the debian/ (packaging) directory is itself relative to the foo-1.0/ branch | 05:11 |
| kiko | carlos, you are da man | 05:12 |
| Keybuk | and there's one more property of InventoryItem (and ManifestEntry too, but it's in one of my secret uncommitted directories right now) | 05:13 |
| Keybuk | mode | 05:13 |
| Keybuk | uh, model | 05:13 |
| === Keybuk learns to type | ||
| Keybuk | model is an instance of BranchModel (in hct.model) | 05:13 |
| Keybuk | all InventoryItems have them | 05:13 |
| Keybuk | so, to explain what they do, I'll explain why they exist | 05:13 |
| cprov | SteveA: ping ? | 05:14 |
| Keybuk | I was having a hard time keeping track of whether to branch off the upstream import, the original tarball, the point in cvs we found the closest copy, etc. | 05:14 |
| Keybuk | I had code that tried to assign a priority to each one, and only defer in cases of lower priority | 05:14 |
| Keybuk | then I tried to reorder the code to do things in priority order | 05:14 |
| Keybuk | neither worked and confused the buggery out of me | 05:15 |
| SteveA | cprov: hello | 05:15 |
| Keybuk | so I charted it all out on my whiteboard, and had a little table of "parent in the manifest", "entry from previous manifest", "upstream import we're based on", "point in cvs we found" | 05:15 |
| Keybuk | and tried to work out the net effect | 05:15 |
| Keybuk | and I realised, why not just have a class that encapsulated that table | 05:15 |
| Keybuk | then I could dump the entire logic into that class as one function | 05:16 |
| Keybuk | that's what BranchModel is | 05:16 |
| Keybuk | as you set up an Inventory, you fill in the fields you know about | 05:16 |
| cprov | SteveA: aparently no sqlbase method (quote, quote_like, sqlvalues) is safe against escape chars ('\\'), is it right ? | 05:16 |
| Keybuk | .model.name you set to the --bit-- of the branch if you care what it should be. (mostly you don't, because it's taken from the filename if missing -- but you might want to use --packaging-- for the spec branch) | 05:16 |
| SteveA | cprov: i don't know for sure. but, probably not. | 05:16 |
| Keybuk | .model.parent you set to the .model of the parent item in the same Inventory (later Manifest) | 05:17 |
| Keybuk | if priorManifest() is called, that sents .model.prior_entry to point to the previous ManifestEntry | 05:17 |
| === mdke_ [n=matt@81-178-149-216.dsl.pipex.com] has joined #launchpad | ||
| Keybuk | if findUpstream() [some shaky code I'm not entirely pleased with] is called, that sets .model.based_on to the manifest entry of the upstream import | 05:17 |
| Keybuk | and likewise findUpstream() might set .model.sync_with to the CVS point | 05:18 |
| Keybuk | so it's an object that just keeps a record of all the interesting things | 05:18 |
| Keybuk | those are the "in" properties | 05:18 |
| Keybuk | it also has a bunch of "out" propreties | 05:19 |
| niemeyer | Right, sounds reasonable | 05:19 |
| Keybuk | there's another class called Naming (in hct.naming) that works with it | 05:19 |
| Keybuk | this is icky, Naming is already gone and folded into BranchModel | 05:19 |
| Keybuk | so pretend the functions you see there are in BranchModel | 05:19 |
| === mdke_ is now known as mdke | ||
| Keybuk | basically there's a function to take the "in" properties, work out exactly what to do with each of them, and toss out a "Branch" object at the end of it | 05:20 |
| Keybuk | Naming.newFromModel | 05:20 |
| Keybuk | as well as set the "out" properties | 05:20 |
| Keybuk | and then there's Model.create which takes the "out" properties and the branch object, and actually puts the branch together | 05:21 |
| Keybuk | there's workflow here | 05:21 |
| === depoll is now known as dePOLL | ||
| Keybuk | the idea is that every time you want to make some changes to a manifest, you make a model, manipulate it, then save the model back to the manifest (thereby updating it) | 05:22 |
| Keybuk | next week at the sprint, I'll show you how things like "give the user local branches to commit to", "give the user a new patch branch", "merge two manifests", etc. all work with this Model API (and are all TRIVIAL! Muahahaha!) | 05:22 |
| Keybuk | for now, you just need to know that you fill in the .model.name property to the branch name if you care what it should be | 05:23 |
| niemeyer | Ok :)) | 05:23 |
| niemeyer | Keybuk: So, that was indeed a very nice overview of sourcerer. Thanks a lot! | 05:25 |
| Keybuk | last useful bits | 05:25 |
| Keybuk | sourcerer/deb/ is the module that implements a pure-Python version of the bits of dpkg-source we needed | 05:25 |
| Keybuk | sourcerer/sprm/ is the stuff jamesh wrote to do the same for src.rpm | 05:25 |
| === hannosch [i=hannosch@85.182.70.124] has joined #launchpad | ||
| niemeyer | Keybuk: I've seen that.. Btw, Smart implements control-file parsing as well. :) | 05:26 |
| Keybuk | and pretty much everything in both hct and sourcerer use hct.util | 05:26 |
| Keybuk | which is Keybuk's library-o-happy-python-joy | 05:26 |
| niemeyer | Keybuk: I'm not yet sure about how important parsing the spec file really is. | 05:26 |
| carlos | kiko, https://wiki.launchpad.canonical.com/LanguagePacksHowTo | 05:26 |
| Keybuk | me neither | 05:26 |
| Keybuk | so there you go, you now know more about sourcerer and hct than anyone else in the company | 05:27 |
| niemeyer | Keybuk: Talking the patch files should be just a matter of trying to create PatchFiles out of the contents and checking if it errors or not. | 05:27 |
| Keybuk | yup, I should think so | 05:27 |
| Keybuk | let the generic code worry about matching them to their taralls | 05:28 |
| niemeyer | Keybuk: I don't think so.. :) But I'll do my best to learn and help you. | 05:28 |
| Keybuk | hehe | 05:28 |
| Keybuk | thom did make some rpm 4.4 packages before he left for greener pastures | 05:29 |
| Keybuk | http://people.ubuntu.com/~thom/ | 05:29 |
| niemeyer | hct.util has many nifty utilities.. | 05:29 |
| Keybuk | still on there, if youw ant to play with them | 05:29 |
| niemeyer | Will certainly be useful | 05:30 |
| === \sh [n=sh@server3.servereyes.de] has joined #launchpad | ||
| jordi | Nafallo: if it's not in breezy and it hasn't been setup, maybe not. | 05:47 |
| Nafallo | jordi: seahorse is in breezy, probably not the later though. | 05:48 |
| jordi | Nafallo: in breezy main, or breezy universe? | 05:48 |
| Nafallo | jordi: universe :-) | 05:48 |
| jordi | if it's universe, it's not automatically imported | 05:49 |
| Nafallo | jordi: ah, so you have to kick it for me then? :-) | 05:49 |
| jordi | hmm, the product doesn't even exist. | 05:49 |
| Nafallo | nope, not as product, but the package should exist. | 05:50 |
| Nafallo | atleast in the archives :-P | 05:50 |
| jordi | I thought there was a product in launchpad for every package in ubuntu, even universe. | 05:51 |
| jordi | but apparently nto. | 05:52 |
| SteveA | kiko: ping | 05:52 |
| kiko | YES | 05:52 |
| kiko | how goes it SteveA? | 05:53 |
| jordi | great | 05:54 |
| jordi | my checkout of seahorse was last updated in April 2003 | 05:54 |
| jordi | carlos: so when we create these kind of products and do the initial import of files, who is in charge of refreshing them? | 05:56 |
| carlos | jordi, who asked you to do the import | 05:57 |
| carlos | jordi, or the own translators | 05:57 |
| carlos | jordi, the idea is tha tusually, we only import products that upstream ask for them | 05:58 |
| jordi | carlos: what if Nafallo suddenly decides to go live in the jungle? Who takes care of "his" products? | 05:58 |
| jordi | carlos: that isn't what I was told | 05:58 |
| carlos | jordi, or people that will take care of those updates from time to time | 05:58 |
| jordi | I was told to import mostly everything that's requested. | 05:58 |
| carlos | jordi, well we don't reject anything, but it's good to ask them to get that compromise... | 05:59 |
| === cpro1 [n=cprov@217.205.109.249] has joined #launchpad | ||
| jordi | carlos: Nafallo may agree to do that now, but he might go MIA in two weeks. | 05:59 |
| jordi | carlos: anyway, seahorse belongs to gnome cvs. | 05:59 |
| jordi | So I guess it needs to be assigned to GNOME translators, which makes it not so useful to Nafallo. | 05:59 |
| carlos | jordi, I know, and we cannot do anything until we implement a way to import directly from upstream | 06:00 |
| carlos | jordi, right | 06:00 |
| jordi | carlos: yeah. | 06:00 |
| jordi | Nafallo: are you a member of your lang's GNOME translation team? | 06:00 |
| Nafallo | jordi: nope | 06:01 |
| === camilotelles [n=Camilo@20132139198.user.veloxzone.com.br] has joined #launchpad | ||
| Nafallo | jordi: and I'm not planning to be, since I only do rushs on translation from time to time and are mainly a packager kind of guy :-) | 06:01 |
| jordi | Nafallo: then I guess it wouldn't be useful at all to add seahorse for you now. | 06:02 |
| jordi | carlos: do you agree with that? | 06:02 |
| Nafallo | jordi: indeed, I'll have to use gtranslator and add an upstream wishlist bug or something instead :-P. | 06:03 |
| jordi | nod | 06:03 |
| carlos | jordi, yeah, the only way to translate GNOME modules is using their teams | 06:04 |
| jordi | ok. | 06:04 |
| jordi | Nafallo: sorry. If you're really interested, you could talk to them about joining it. | 06:04 |
| jordi | it shouldn't be a problem | 06:04 |
| jordi | Nafallo: what language is this? | 06:05 |
| Nafallo | jordi: swedish | 06:09 |
| jordi | oh | 06:10 |
| jordi | MENTHOS' II! | 06:10 |
| Nafallo | jordi: seems translations exist in their cvs already, but it doesn't seem to be in breezy | 06:10 |
| Nafallo | atleast not up-to-date :-) | 06:10 |
| Nafallo | hehe | 06:10 |
| jordi | Nafallo: maybe translations were added after release, or the package is not up to date? | 06:11 |
| Nafallo | jordi: the package is up-to-date with debian, but not with upstream indeed | 06:11 |
| jordi | I know who to kick :/ | 06:12 |
| Nafallo | hehe, we _are_ in UVF still ;-) | 06:12 |
| jordi | I pinged | 06:12 |
| Nafallo | still no updated swedish translations. | 06:14 |
| jordi | you upgraded? | 06:14 |
| Nafallo | I could do them "off rosetta" and add them to the package with my MOTU role ;-) | 06:14 |
| Nafallo | http://sourceforge.net/mailarchive/forum.php?thread_id=7838669&forum_id=4102 | 06:14 |
| Nafallo | jordi: I settle for improving the po manually and include it in breezy or something :-) | 06:17 |
| dilys | Merge to rocketfuel@canonical.com/sqlobject--test--0.6: Fix BoolValidator to not treat NULL values as False (backported from upstream's svn trunk). r=SteveA (patch-35: guilherme.salgado@canonical.com) | 06:21 |
| jordi | Nafallo: good luck :) | 06:29 |
| === Seveas [n=seveas@seveas.demon.nl] has joined #launchpad | ||
| === bradb & # lunch | ||
| sabdfl | mpt: ping | 07:16 |
| SteveA | sabdfl: he's away for a couple more hours. | 07:16 |
| Keybuk | meh @ not being able to write a comment when you fix a bug in Malone :-/ | 07:24 |
| sabdfl | SteveA: where is the bit that registers "addform"? | 07:24 |
| kiko | Keybuk, there's the whiteboard.. | 07:24 |
| SteveA | sabdfl: do you mean, where is the thing that processes the browser:addform zcml? | 07:25 |
| sabdfl | yes | 07:25 |
| Keybuk | kiko: that isn't a comment that appears for anyone else though | 07:25 |
| Keybuk | I generally like to close a bug with an explanation of /how/ I fixed it | 07:25 |
| sabdfl | there's an AddViewFactory, but what calls *that* | 07:25 |
| sabdfl | also, how hard would it be to have a /fmt:moin ? | 07:26 |
| sabdfl | just to render a text field as html, with moin rules | 07:26 |
| SteveA | the bulk of it is in zope/app/form/browser/metaconfigure.py has the things that process that zcml directive | 07:26 |
| === cpro1 [n=cprov@217.205.109.249] has joined #launchpad | ||
| SteveA | in launchpad, it is actually processed by something in launchpad/webapp, but all that does is support the facet=".." stuff we need for menus. | 07:27 |
| SteveA | if the moin formatting stuff has a reasonable API to call, it would be easy to have a /fmt:moin | 07:27 |
| sabdfl | SteveA: i've written a thing that looks similar to AddView, and i want to get it to handle <browser:form | 07:27 |
| SteveA | we might need to think about cacheing its output though. | 07:27 |
| SteveA | sabdfl: the code you need is in metaconfigure.py | 07:29 |
| SteveA | you can see examples of testing new zcml directives in launchpad/doc/zcmldirectives.txt | 07:29 |
| SteveA | on the other hand, if you want to pass it on to me, i can work on it on monday. | 07:30 |
| SteveA | metaconfigure/EditFormDirective looks quite straightforward | 07:31 |
| SteveA | you also need to write a schema for your directive. | 07:31 |
| SteveA | see zope/app/form/browser/metadirectives.py | 07:31 |
| SteveA | you also need to hook it up | 07:32 |
| SteveA | see zope/app/form/browser/meta.zcml | 07:32 |
| BjornT | sabdfl, SteveA: browser:form already exists in zope 3.1, maybe we could simply backport that if it does what we want? | 07:32 |
| SteveA | we hook up new directives in launchpad in webapp/meta.zcml | 07:32 |
| SteveA | we'll be moving to the new zope in under 2 weeks. | 07:32 |
| SteveA | however, i'd recommend against adding browser:form, because it is easier to just use your own base-class, and register it as a normal browser:page view. | 07:33 |
| SteveA | much less infrastructure to set up | 07:33 |
| SteveA | much less to test | 07:34 |
| sabdfl | SteveA: can i get fields, and keyword_arguments, and schema, with a normal browser:page? | 07:44 |
| SteveA | no. but, you can set them in your class in python code. | 07:45 |
| === bradb returns | ||
| SteveA | zope3 is moving towards doing more of this "assembling a form" stuff in python code, and not in zcml. | 07:46 |
| bradb | sabdfl: did you get my note from before about conflicts? | 07:47 |
| sabdfl | bradb: yes | 07:54 |
| bradb | ok | 07:54 |
| === hannosch [i=hannosch@85.182.70.124] has left #launchpad [] | ||
| === niemeyer_ [n=niemeyer@200-193-158-174.ctame7006.dsl.brasiltelecom.net.br] has joined #launchpad | ||
| Kinnison | ciao dudes | 08:15 |
| \sh | jblack: ping | 08:19 |
| \sh | or at least some bzr/baz pros here? I need a short information about importing baz/bzr to svn | 08:20 |
| \sh | and vice versa without losing the changelog history ;) | 08:21 |
| jblack | hmm? | 08:23 |
| jblack | which one? | 08:23 |
| \sh | jblack: in common...any possibility? I'm trying to convince one upstream to use baz/bzr but they are using trac as basement for their development env...and this plays nicely with svn...so I want to import it to your bazaar server and provide some ubuntu specific patches (as I did now with lp integration) but need a possibility to import as well those changes automatically to svn...(best way without the diff thing) | 08:25 |
| jblack | Launchpad can convert cvs/svn repoistories into bazaar archives. | 08:26 |
| jblack | There is a tool called tailor that can convert svn archives into bzr. There's also a tool to convert bazaar archives to bzr archives called baz2bzr | 08:26 |
| \sh | but baz2svn / bzr2svn is not invented? :) | 08:27 |
| jblack | Tailor probably can. | 08:27 |
| jblack | I hear that tailor is a bit lossy on history though. | 08:28 |
| \sh | so the best way is manual work...2 branches...one orig branch which is imported from svn and one working branch for ubuntu...diffing those two branches and repatch the svn head checkout | 08:29 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Add sbuild.conf to launchpad-buildd package, release v4 of package (patch-2382: daniel.silverstone@canonical.com) | 08:29 |
| jblack | That should work, yes. | 08:30 |
| jblack | Carrying code through two RCS systems bidirectionally is still not a very well explored area. | 08:31 |
| jblack | There's been a few successes and a few failures, but I'm not aware of any clear set of rules that universally apply. | 08:31 |
| SteveA | jamesh: ping? | 08:31 |
| \sh | jblack: ok...but when I generate a changelog text from all commits to baz/bzr...generate a diff to the main svn export branch and patch it to a clean svn checkout..and provide the history of my baz/bzr commits into a single commit message to svn..this should work...*nodnod* yeah..lets try it | 08:33 |
| cprov | lifeless: can you get the builddUI.diff at http://10.90.90.200/~cprov/builddUI.diff and verify if it's ok ? | 08:34 |
| mdke | jordi, got those pots ready for you | 08:35 |
| mdke | jordi, emailing to r@u.c? | 08:35 |
| cprov | lifeless: for celso.providelo@canonical.com/launchpad--builddUI--0--patch-43 | 08:37 |
| kiko | salgado, ping? | 08:40 |
| salgado | kiko, pong | 08:40 |
| kiko | salgado, so, can you ensure that | 08:41 |
| kiko | Missing: person_changetimezone | 08:41 |
| kiko | Missing: person_key | 08:41 |
| kiko | are both nuked from our tree in 10 minutes? kthxbye | 08:41 |
| kiko | Missing: poll_options | 08:41 |
| kiko | that's another one | 08:41 |
| salgado | the first two ones don't exist anylonger | 08:41 |
| salgado | the third one I just added the pagetitle | 08:41 |
| kiko | sure | 08:42 |
| kiko | nuke them away | 08:42 |
| kiko | rs=kiko | 08:42 |
| salgado | I thought they were already nuked | 08:43 |
| elmo | err, foaf searching's kind of painful | 08:43 |
| kiko | salgado, they are still in templates/ | 08:44 |
| elmo | is it unreasonable to expect searching for 'freese' to DTRT | 08:44 |
| elmo | i.e. find this guy: https://launchpad.net/people/bddebian | 08:44 |
| salgado | kiko, I just removed them. | 08:44 |
| kiko | thanks | 08:45 |
| salgado | elmo, you did a search for 'freese' and got this guy as result? | 08:46 |
| elmo | salgado: no, if I search for freese I don't get him, if I search for defreese (his full surname) I do | 08:47 |
| elmo | but I'd like partial matches of surnames to be returned too | 08:48 |
| salgado | elmo, the problem is in our full text indexes. look what it does for defreese: | 08:49 |
| salgado | launchpad_dev=# select ftq('defreese'); | 08:49 |
| salgado | ftq | 08:49 |
| salgado | ----------- | 08:49 |
| salgado | 'defrees' | 08:49 |
| salgado | (1 row) | 08:49 |
| kiko | elmo, that's a fault of our FTI searches. | 08:49 |
| salgado | so, if you search for defrees you won't get anything either | 08:50 |
| === Seveas` [n=seveas@seveas.demon.nl] has joined #launchpad | ||
| salgado | bah, there must be something wrong | 08:50 |
| \sh | sabdfl: ping can I talk to you for 5 mins? | 08:54 |
| mdz | kiko: how did your work on the landing pages go? | 08:56 |
| Keybuk | randomly, I keep meaning to mention to this to people | 08:57 |
| Keybuk | https://chinstrap.ubuntu.com/~scott/keybuk-launchpad_1.2_all.deb | 08:57 |
| Keybuk | drags in the launchpad deps and sets up postgresql for you | 08:58 |
| sabdfl | \sh: sure, privmsg? | 08:58 |
| sabdfl | mpt: ping | 08:58 |
| \sh | sabdfl: yes | 08:58 |
| kiko | mdz, it went well, no 404s any longer right? | 08:59 |
| === SnakeBite [n=SnakeBit@84.242.143.64] has joined #launchpad | ||
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=stevea] Fix buildduration IntervalCol value in builddmaster (patch-2383: celso.providelo@canonical.com) | 09:10 |
| bradb | sabdfl: Just so you know, I've got IBugTask.target returning the correct target in my branch now too (D, DR, DSP, DRSP, P). | 09:11 |
| bradb | (documented in bugtask.txt) | 09:11 |
| bradb | I created a DistroSourcePackage on this branch | 09:12 |
| mdz | kiko: no 404s, but the text still looks like an error | 09:12 |
| kiko | mdz, hey, you said the least was a 200ok | 09:13 |
| mdz | kiko: indeed I did | 09:14 |
| bradb | mpt: In what kind of thing should I put the "This bug has *not yet been reported* ..." message? If you tell me what it should look like, I can possibly do the CSS. | 09:14 |
| mdz | stevea and I talked about the text; I guess I assumed that was trivial | 09:14 |
| kiko | it is actually trivial if not for rollout issues | 09:15 |
| SteveA | kiko took a different approach | 09:15 |
| SteveA | the "coming soon" page is displayed if there is no such package in launchpad | 09:15 |
| kiko | lifeless, ping? | 09:15 |
| SteveA | the real "get help" page is displayed if there is a package | 09:16 |
| SteveA | so, you're seeing the "real" page | 09:16 |
| lifeless | pong | 09:16 |
| kiko | lifeless, save me, privmsg | 09:16 |
| kiko | liiiifeless | 09:19 |
| === kiko nudges lifeless | ||
| Keybuk | niemeyer: where did you note down the breezy compilation failure for zope? | 09:26 |
| === Mez [n=Mez@cpc4-lich4-3-0-cust247.brhm.cable.ntl.com] has joined #launchpad | ||
| niemeyer | Keybuk: I've sent the patch to the launchpad list. | 09:26 |
| niemeyer | Keybuk: Do you want it? | 09:26 |
| Keybuk | ah yes, that's where I saw it | 09:27 |
| === Keybuk was looking on the wiki | ||
| Keybuk | s'ok, found it | 09:27 |
| carlos | ok dudes, time to leave | 09:29 |
| carlos | see you in a week or so | 09:29 |
| sabdfl | W00T | 09:30 |
| sabdfl | just wrote a general form processor | 09:30 |
| sabdfl | thank god | 09:31 |
| sabdfl | no more faking addforms | 09:31 |
| sabdfl | nosirree | 09:31 |
| sabdfl | those days are OVER | 09:31 |
| sabdfl | kiko: do we have working langpacks? | 09:34 |
| sabdfl | kiko: is mpt around? | 09:34 |
| kiko | sabdfl, mpt should be arriving any minute now from classes | 09:35 |
| kiko | as for langpacks | 09:35 |
| kiko | all known whitespace issues have been fixed | 09:35 |
| kiko | this took us 3 iterations to get right | 09:35 |
| kiko | the migration script is running on staging and will be finished tonight | 09:36 |
| === dePOLL is now known as depoll | ||
| kiko | most known export issues that were blockers are now fixed | 09:36 |
| kiko | I'm generating a language pack based on carlos' branch | 09:36 |
| kiko | and will compare against the official packs later to assert we've got most issues nailed down | 09:37 |
| kiko | I must say there are lots of little corner cases that will need to be shaked down over time | 09:37 |
| kiko | so "working langpack" is not a binary thing | 09:37 |
| kiko | the majority of files now does export successfully, however. | 09:37 |
| sabdfl | what classes are mpt taking? | 09:38 |
| salgado | :q | 09:38 |
| salgado | damn focus | 09:38 |
| sabdfl | ok, thanks for the status update | 09:38 |
| kiko | sabdfl, it's thursday, just basic pt_BR classes | 09:39 |
| kiko | he more than replaces the time | 09:39 |
| sabdfl | kiko: k thanks | 09:43 |
| sabdfl | bradb: any reason that malone email does not say who made the change? | 09:43 |
| bradb | sabdfl: It says it in the From: line. | 09:43 |
| sabdfl | i'd like to make that more explicit | 09:43 |
| bradb | sabdfl: The plan was to change those headers anyway, so that explicitness could happen at the same time. | 09:44 |
| bradb | (as per what Keybuk suggested, etc.) | 09:44 |
| sabdfl | separate issue | 09:44 |
| sabdfl | is it going to break a lot of tests? | 09:44 |
| bradb | sabdfl: If you change something in the body, it'll break quite a bit of bugnotification-email.txt. | 09:45 |
| bradb | Should be quick to fix. Other than that, I don't think much else should break from a change of the body content in the email. | 09:45 |
| sabdfl | ok | 09:46 |
| sabdfl | i think i will just reformat that mail substantially, if i get the time | 09:46 |
| bradb | ok | 09:47 |
| Virtuall | - - Software Freedom Day '05, 00:30 !!! | 09:48 |
| Virtuall | ...sorry for that | 09:49 |
| sabdfl | Virtuall: bez problem | 09:52 |
| sabdfl | shto ti xotjish znaet? | 09:53 |
| sabdfl | znaesh, perhaps | 09:53 |
| Virtuall | , , Ubuntu Team Latvia . . | 09:54 |
| Virtuall | sabdfl, ? | 09:55 |
| Virtuall | :) | 09:55 |
| sabdfl | ok, that's harder to translate | 09:55 |
| sabdfl | all i got was ?????????????? ???????? | 09:55 |
| kiko | I got some funky norwegian | 09:55 |
| bradb | sabdfl: also, just so you know, i'm changing all the bug actions portlet links to be +addfoo (unless you have any objections) | 10:04 |
| sabdfl | +addfoo? | 10:05 |
| Virtuall | :D | 10:05 |
| Virtuall | damnit :( | 10:05 |
| sabdfl | +addcve etc? | 10:05 |
| sabdfl | sure | 10:05 |
| Virtuall | anyway, forget it :) | 10:05 |
| bradb | sabdfl: yeah | 10:05 |
| sabdfl | bradb: do you know if the IBugAttachment schema will magically give me the upload-a-binary-object-fu? | 10:07 |
| sabdfl | the Object schema type is not one i've seen before | 10:07 |
| bradb | sabdfl: no idea. BjornT might know, but I guess he's not around | 10:08 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: r=bjornt various menus and facet-assignment fixes. (patch-2384: steve.alexander@canonical.com, mpt@canonical.com) | 10:09 |
| SteveA | an Object field type specifies an attribute that contains some object that provides the schema specified in the field | 10:10 |
| SteveA | so, you can use it to say that the attribute 'target' must be an IBugTarget | 10:10 |
| SteveA | for example | 10:10 |
| bradb | ah, nice | 10:10 |
| === Lovechild [n=dnielsen@0x50c71cc7.adsl-fixed.tele.dk] has joined #launchpad | ||
| === rw` [n=user@200.128.80.250] has joined #launchpad | ||
| sabdfl | that is nice | 10:13 |
| SteveA | if you want an "upload a file" widget | 10:14 |
| bradb | sabdfl: I think you might want a Bytes field, btw. But I'm only guessing from looking at IBugAttachmentAddForm | 10:14 |
| SteveA | you'll need to use a Bytes field | 10:14 |
| SteveA | sabdfl: nice that you included a test of facets in xx-ticket-01-overview.txt | 10:16 |
| sabdfl | bradb: yes, i found that too. thanks. | 10:20 |
| sabdfl | SteveA: i have a nice simple "process a form" now | 10:21 |
| SteveA | cool | 10:21 |
| sabdfl | all you do is declare the <browser:page with the view, inherit from FormView, tell it schema, _arguments and _keyword_arguments, and write the function that actually processes the results | 10:21 |
| mdke | jordi, here? | 10:22 |
| lifeless | kiko: about to leave here soon | 10:22 |
| salgado | kiko, lifeless, still mirroring | 10:23 |
| kiko | lifeless, almost there | 10:24 |
| kiko | the base-0 mirror is big | 10:24 |
| lifeless | you can mirror with --no-cachedrevs | 10:24 |
| kiko | ah? | 10:25 |
| kiko | salgado? | 10:25 |
| salgado | is it worth stop the mirroring now to use --no-cachedrevs? the base-0 seems to be mirrored already | 10:26 |
| lifeless | if the base-0 is done, dont stop | 10:26 |
| salgado | okay, finished. guilherme.salgado@canonical.com/launchpad--production--1.31 | 10:29 |
| kiko | lifeless, DO IT | 10:31 |
| sabdfl | SteveA: help | 10:35 |
| lifeless | help me rhonda, help help me rhonda | 10:35 |
| sabdfl | i'm trying to use an editform, with a schema that is a subset of an IPerson | 10:35 |
| sabdfl | subset, in the sense that it has 3 things with the same names as things in IPerson | 10:36 |
| sabdfl | but they are different | 10:36 |
| sabdfl | TypeError: ('Could not adapt', <Person at 0x-4a9afc34>, <InterfaceClass canonical.launchpad.browser.person.IPersonHomePageEditSchema>) | 10:36 |
| lifeless | have you registered an adapter ? | 10:36 |
| sabdfl | do i need to do something special to be able to do that? | 10:36 |
| sabdfl | lifeless: where do i do that? | 10:36 |
| lifeless | yes, either the object needs to declare it implements the interface, or you need to write the code that uses an IPerson to implement an IPersonHomePageEditSchema, and then tell launchpad about that | 10:37 |
| bradb | sabdfl: If you override .create in your view, you can get around having to write an adapter | 10:37 |
| lifeless | so the first question is, does person actually implement IPersonHomePageEditSchema already ? | 10:37 |
| sabdfl | lifeless: i think so, yes | 10:38 |
| sabdfl | lifeless: in the sense that there are three things with the same name in IPerson | 10:38 |
| sabdfl | in the one, they are Bytes | 10:38 |
| sabdfl | inthe other, Object's | 10:38 |
| lifeless | sabdfl: in which case, I think the patah of least resistance (but maybe not good zope style - your reviewer will pick up this and check in more detail) is to add IPersonHomePageEditSchema to the interface list in Person | 10:39 |
| lifeless | i.e. implements(IPerson) | 10:39 |
| bradb | (s/create/createAndAdd/, that is) | 10:39 |
| lifeless | implements(IPersonHomePageEditSchema) | 10:39 |
| lifeless | bradb: oh ? | 10:39 |
| bradb | the base add views try to adapt the context class to the schema in createAndAdd | 10:40 |
| lifeless | ah, so by overriding that you can choose the used schema ? | 10:40 |
| lifeless | seems like routing-around-dmg to me | 10:41 |
| bradb | right, even just overriding .create works for me | 10:42 |
| bradb | (I just did it for +addcve, so that I don't have to write an adapter from IBugTask to ICVERef.) | 10:42 |
| bradb | in sabdfl's case, this might be different though :/ I think the thing that is returned from .create has to provide the interface named in schema="..." | 10:43 |
| bradb | in my case i return an ICVERef from .create, so it provides the schema="...ICVERef" interface. | 10:44 |
| lifeless | bradb: so you did write an adapter;0 | 10:44 |
| bradb | with a schema that was created to render one specific form them, you pretty much have to bend over | 10:44 |
| bradb | lifeless: no | 10:44 |
| === eruin [n=eruin@unaffiliated/eruin] has joined #launchpad | ||
| bradb | the last line of my .create is: | 10:45 |
| eruin | re: why aren't there templates for, say, synaptic in rosetta? | 10:45 |
| bradb | (well, lines): | 10:45 |
| bradb | return getUtility(ICVERefSet).createCVERef( | 10:45 |
| bradb | bug=bugtask.bug, cveref=form_values['cveref'] , | 10:45 |
| bradb | cvestate=form_values['cvestate'] , | 10:45 |
| bradb | title=form_values['title'] , | 10:45 |
| bradb | owner=getUtility(ILaunchBag).user) | 10:45 |
| lifeless | bradb: thats how I would have written the adapter ;0 | 10:45 |
| bradb | i.e. it's something that already provides the interface that was used as the schema="..." for my form | 10:45 |
| sabdfl | eruin: good question, i don't know | 10:46 |
| lifeless | bradb: though it may not be easy withou tthe form state variables | 10:46 |
| sabdfl | carlos just left on holiday | 10:46 |
| sabdfl | kiko: ? | 10:46 |
| eruin | I'd love to help translating it and others fully in time for breezy | 10:46 |
| mdke | what hours does jordi keep sabdfl do you know? | 10:47 |
| mdke | insert punctuation in that sentence as necessary | 10:47 |
| eruin | knowing how when a particular app isn't on rosetta is.. confusing at best ;) | 10:47 |
| lifeless | jordi - pretty normal east-spain hours | 10:48 |
| lifeless | (IIRC) | 10:48 |
| lifeless | jordi: ping ^^^ | 10:48 |
| mdke | he has a day job though right? | 10:48 |
| mdke | anyhow is rosetta@ubuntu.com the correct address for him? | 10:49 |
| mpt | sabdfl: pong | 10:51 |
| mpt | bradb: <p> would do | 10:52 |
| mpt | <p>This bug is not recorded as occurring in {context}. ( Yes It Does )</p> | 10:52 |
| mpt | or something like that | 10:52 |
| bradb | mpt: Hm, it doesn't seem to look ideal without some kind of emphasis (particularly if there's already other portal messages being shown above it.) | 10:53 |
| mpt | bradb: Well, then we come back to my old <h2>Status in {context}</h2> and <h2>Status elsewhere</h2> idea | 10:54 |
| bradb | hm. ok, i'll let this one bake a bit longer. working on other things atm (+addfoo for all the bug-related object add pages) | 10:55 |
| bradb | I wonder if there'll be a Malone page test that I *won't* touch in this patch. | 10:56 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--production--1.31: production cherrypick from salgado (patch-5: guilherme.salgado@canonical.com) | 10:57 |
| kiko | sabdfl? | 10:57 |
| kiko | what did I do now | 10:58 |
| lifeless | kiko is that better? | 10:58 |
| === BjornT [n=bjorn@82-135-221-189.ip.takas.lt] has joined #launchpad | ||
| bradb | kiko: I think he might have been forwarding on this question to you, in carlos' absence: 16:45 < eruin> re: why aren't there templates for, say, synaptic in rosetta? | 10:59 |
| kiko | lifeless, uhm, well, almost. | 11:00 |
| lifeless | kiko: I'm so out of it, its not funny. | 11:01 |
| kiko | lifeless, I'll have stuart fix it, no worries. | 11:02 |
| lifeless | what needs doing now ? | 11:02 |
| kiko | thanks. | 11:02 |
| lifeless | ok. gnight | 11:02 |
| kiko | just too much going on at once | 11:02 |
| lifeless | sabdfl: gnight. see you monday. | 11:02 |
| lifeless | kiko: do you need me to roll it back ? | 11:02 |
| === cprov [n=cprov@217.205.109.249] has joined #launchpad | ||
| lifeless | kiko: or is it an improvement as it stands ? | 11:02 |
| kiko | lifeless, rolling it back will be ideal :-( | 11:03 |
| lifeless | doing so now | 11:03 |
| kiko | mpt has a pair of pages which will save us till next week, and salgado/stuart can get it up | 11:03 |
| lifeless | done | 11:04 |
| === lifeless crashes | ||
| asmodai | kiko: oi! | 11:08 |
| asmodai | kiko: Tudo bem? | 11:08 |
| kiko | asmodai, t tudo daquele jeito | 11:15 |
| asmodai | kiko: :) | 11:15 |
| asmodai | Good to see you alive and kicking ;) | 11:15 |
| kiko | asmodai, I'm kicking as hard as we can | 11:17 |
| asmodai | kiko: That much work? | 11:17 |
| kiko | i'd be lying if I said yes | 11:17 |
| kiko | more than that | 11:17 |
| kiko | THAT MUCH | 11:18 |
| asmodai | :| | 11:18 |
| asmodai | Too much? | 11:18 |
| kiko | perhaps :) | 11:18 |
| asmodai | *smiles* | 11:19 |
| === asmodai is about to get hired by a Dutch uni. Part of work will be pgsql/dspace hacking | ||
| Nafallo | jordi: ping launchpad-integration | 11:20 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Fix missing pagetitles, improve our basic test coverage for those pages, and add utilities/check-templates.sh which verifies if all templates are registered and properly pagetitled. Only one page title missing, but that's Salgado's fault (patch-2385: christian.reis@canonical.com) | 11:29 |
| bradb | sabdfl, BjornT: so, just a heads up then (to hopefully avoid potential conflicts) that all the bug-related object add pages are now officially +addcve, +addattachment, +addurl and +addwatch on my branch | 11:33 |
| sabdfl | bradb: eta to landing? | 11:33 |
| bradb | and i blew way the factories for those things, using the equiv *Set now | 11:33 |
| bradb | sabdfl: another couple of days, probably | 11:33 |
| bradb | s/couple/few/ considering code review and such | 11:33 |
| sabdfl | bradb: i'm starting to prefer a slightly different approach now | 11:36 |
| sabdfl | where you have something that is always associated with something else | 11:36 |
| sabdfl | instead of a *Set, just put the add on the thing that its linked to | 11:36 |
| sabdfl | so for example | 11:36 |
| sabdfl | my new subscription code does not have a TicketSubscriptionSet.new(ticket, person) | 11:37 |
| sabdfl | it has Ticket.subscribe(person) | 11:37 |
| sabdfl | much more natural | 11:37 |
| bradb | right | 11:37 |
| bradb | I'm probably best to save that refactoring for the firefighting-merge after this one lands. It will be a monster. | 11:39 |
| bradb | (or maybe even the merge after that) | 11:39 |
| bradb | I changed the bug page to highlight the current task too. I think it looks a heck of a lot better that way. | 11:42 |
| niemeyer | sabdfl: Is the sprint happening at Fieldwave's office (Axiscross House)? | 11:46 |
| sabdfl | niemeyer: yes | 11:47 |
| sabdfl | bradb: i like the idea of highlighting the current task, if we know it | 11:47 |
| bradb | sabdfl: we *always* know it now :) | 11:48 |
| bradb | even /malone/bugs/1 redirects to context. no escaping it! | 11:48 |
| sabdfl | sounds good. which context | 11:48 |
| bradb | sabdfl: the first one it finds. first == the bugtask with the smallest id | 11:49 |
| sabdfl | bradb: ok | 11:49 |
| === cprov [n=cprov@217.205.109.249] has joined #launchpad | ||
| === bradb fixed that goofy duplicate names bug in the maintainers portlet too | ||
| bradb | no user deserves to see that | 11:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
