=== BradB|London [~bradb@224-21-161-212.DSL.ONCOLT.COM] has joined #launchpad [01:37] tla killed [01:59] !alindeman:*! Hi all! As you may know, Space Ship One is go for its flight tomorrow morning. If you're interested, #spaceshipone is gearing up to monitor and celebrate the event. [06:00] that must make your work more difficult, now that tla is dead === lifeless is now known as __owen__ === __owen__ is now known as lifeless [08:42] mdz: not really, its quite phoenix like [08:46] autofs is cool. === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad [09:31] lifeless, jblack_: ping [09:31] morning === BradB|London [~bradb@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === cprov [~cprov@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === debonzi [~debonzi@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === limi [~limi@159.80-202-72.nextgentel.com] has joined #launchpad === carlos is still waiting a merge request confirmation since yesterday night [10:22] stub: You around? [10:22] Yup [10:23] For how much longer? :) [10:24] Probably another 7 hours [10:25] Heh, ok :) === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #launchpad === elmo_ [~james@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [10:40] elmo_: do you know if is there any problem with the chinstrap mail? [10:41] carlos: we had some problems with PQM yesterday [10:41] elmo_: pqm is not processing my merge request since yesterday === carlos needs to know if it's safe to resend the merge or should wait [10:41] if in doubt, wait [10:42] it's not chinstrap mail [10:42] it's pqm/tla [10:47] elmo_: I don't know where is the problem and lifeless/jblack_ are not available to ask about pqm so I ask you as the mailadmin :-P === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [10:48] carlos: err, and I answered? [10:49] will be offline for a bit, changing networks [10:49] elmo_: yes, don't worry [10:50] elmo_: change ask by asked, sorry [10:51] carlos: the n~ characters are just omitted by my xchat [10:52] I don't know about mark's [10:52] so I wonder if mark got a good translation [10:52] hmm [10:52] I will send it by mail then [10:53] mark has it okay [10:54] ok [10:57] breakfast time, see you later [11:03] carlos: should Schema.name be lowercase only while I'm at it? [11:04] stub: sorry, I don't understand the question [11:05] I'm putting the unique constraint on schema.name. I was wondering if I should also enforce that schema.name is also lowercase (I do this for some other .name columns where we want to use them in urls) [11:05] ooh, hmm, It could be a problem === limi [~limi@159.80-202-72.nextgentel.com] has joined #launchpad [11:06] we have labels with names like es_ES [11:06] or pt_BR [11:06] hm, that didn't work all that well [11:06] seems like I have to migrate to the office [11:08] carlos: No problem - I won't put any other constraints in then. [11:09] stub: ok, thanks [11:09] carlos: aren't those label names not schema namet, though? [11:09] daf: no [11:09] hmm [11:09] wait [11:09] too many negations [11:09] those label names are not schema names [11:09] let me rephrase :) [11:09] right [11:10] daf: so? [11:10] it seems to me that stub was talking about schemas and you were talking about labels [11:10] hmm [11:10] right [11:10] O:-) [11:10] so, schema names can be lowercase, but label names can't? [11:10] right [11:11] stub: forget what I told you, and add the lower case constraint for Schema.name, please [11:11] carlos: Ok. :-) === carlos is back [11:23] after getting some food and sugar, my brain should work better :-P [11:27] spiv: the commit rocketfuel just got from you, is from today? [11:30] Hmm, no, it's from yesterday. [11:30] limi: rocketfuel now has that patch I sent you yesterday properly merged in. [11:30] great [11:34] so I should wait [11:34] before any new commit... [11:34] spiv: thanks for the information [11:35] Presumably it's working through the backlog :) [12:06] finally!! my merge was done [12:07] spiv: so the problem was "only" an empty request? [12:09] carlos: Yeah, blame SteveA. [12:09] ;) [12:10] :-P [12:11] hmm [12:11] I did not changed some files that the commit log says I did [12:11] lib/canonical/lp/images/arrowBottom.gif [12:11] lib/canonical/lp/images/arrowDown.gif [12:11] lib/canonical/lp/images/arrowRight.gif [12:11] lib/canonical/lp/images/info.gif [12:11] lib/canonical/lp/images/languages.gif === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has left #launchpad [] [12:14] Hmm, that's a bit of a mystery. [12:17] carlos: looks like some changes I made [12:17] None of the changesets it claims to have merged touched those files. [12:17] (at least, not according to my browsing of archzoom) [12:17] https://chinstrap.warthogs.hbd.com/archzoom/daf@canonical.com--2004/launchpad--devel--0--patch-182?log [12:18] Weird. [12:18] daf: but I'm talking about my merge, why it list those files in my merge request? [12:18] carlos: no idea [12:18] which merge? [12:18] This sounds like a question for the arch guys. [12:18] hmmm [12:18] perhaps you changed the permissions back [12:19] ls -l lib/canonical/lp/images/arrowBottom.gif [12:19] ? [12:19] well, not deliberately, obviously [12:19] daf: Not according to his changesets... [12:19] the permissions stuff in Arch does seem rather flakey [12:19] -rw-r--r-- 1 carlos carlos 102 2004-08-16 12:23 lib/canonical/lp/images/arrowBottom.gif [12:19] weird! [12:20] that's the correct permission [12:21] daf: so I did not broke anything [12:21] ok, more mistery arround arch :-P [12:22] I'll mail the arch guys. [12:22] carlos: mistery -- is that like a combination of "mystery" and "misery"? :) [12:23] daf: a kind of :-P [12:50] daf: could we move the #1973 to post beta after lalo's changes? [12:53] huh? [12:53] is it fixed yet? [12:54] daf: with indexes and lalo changes the import speed has been improved a lot, so I think it's not a priority now [12:55] we still should profile the process to improve it more, but it's not as important as other bugs we have [12:55] of course, under my point of view [12:56] let's leave it as it is for now [12:57] ok === limi [~limi@193.71.38.142] has joined #launchpad [01:08] so, everything is OK wrt PQM and friends now? [01:09] yeah, except for the null-merge-wedged-pqm bug [01:09] * wedges === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [01:11] limi: Largely; see my mail to the launchpad list. [01:12] ok [01:22] New bug 2052 for Launchpad/Launchpad: Make ShipIt use andrew's XML-RPC auth service [01:22] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2052 [01:24] New bug 2053 for Launchpad/Launchpad: Code security review of shipit [01:24] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2053 === elmo_ [~james@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [01:28] lulu: isn't it lunctime yet? :) [01:31] daf: -ECHAN, #launchpad [01:31] blah #lunchpad [01:34] daf: almost! === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has left #launchpad [] [01:39] stub: ping? [01:39] spiv: pong [01:39] Get my mail? [01:40] (and checking you haven't gone to sleep ;) === stub checks [01:40] Yup - Sourceforge table [01:42] It's slightly misnamed, I guess, we'll put freshmeat info in there as well. [01:42] Sounds sane, and I have no problem with it. The database is there to fulfill the developers' needs ;) [01:42] Excellent :) [01:44] What tool is writing to it, and what tool will migrate the data from it to Product? (For documentation) [01:46] spiv: And should I add it now, or wait until you have confirmed all the columns you need are actually there? [01:46] For the former, we have code from someone Mark contracted to do gather the data, although I'm not sure exactly where we'll take its results and put it in the table. [01:46] For the latter, it'll be part of the launchpad web UI. [01:47] I think add it now. === stub tries to think of a better name than 'Sourceforge' [01:48] Its already being used for more than just sourceforge data (you mentioned freshmeat) - anyone else there have any better ideas? [01:48] ProjectDetailsScrapedFromExternalSources ;) [01:49] ScrapedProject perhaps (which is the shortened version of yours...) [01:49] That works for me. [01:50] Can you quickly ask there? [01:50] Mark's in a rush atm. [01:51] homepageurl should be unique? (I'm thinking how the scraper will work) [01:52] Or do we need some sort of external id so the scraper knows if it already has that one? [01:53] daf:lunch :o) [01:53] lulu: Wheres mine dammit? [01:53] And about to disappear for a meeting... [01:54] stub: come on over! [02:09] daf: following your instructions, It says that my archive is missing the patch-214 [02:09] hmm [02:09] ok, forget it [02:10] I thought you were talking about missing patchs from rocketfuel into my archive [02:10] now, that mail makes more sense :-P === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [02:20] lulu: mark spoke about three deadlines, the 7th, the 13th and the 20th October (I believe) - do you know what these are? there was a lot of noise, so I couldn't make it all out. [02:21] limi: hiya [02:21] limi: websites - we need to have them sorted by the 7th [02:21] 13th - gold release of Warty and Malone Alpha [02:23] 20th - official release - after any showstopping bugs in Warty are dealt with (if any) and print of CDs [02:23] great, thanks [02:23] 13th = named, the "candidate release" [02:24] limi:no worries. [02:30] limi: have you worked with Luirker before? [02:30] lurker... [02:31] that's the nick of one of my employees ;) [02:31] I've seen it, yes [02:31] not worked extensively with it [02:32] limi: ok - I'm about to send you an email on it ... [02:32] ok === elmo__ [~james@83.216.141.215] has joined #launchpad [02:59] limi:sent === cprov [~cprov@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [04:14] New bug 2054 for Launchpad/Rosetta: URL pointing to inexistent POFile objects should not fail [04:14] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2054 [04:22] nonexitent, not inexistent :-) [04:35] lalalala [04:35] :-P [04:36] fixed [04:40] in these situations, Lithuanian friends of mine say "Me fail english? unpossible!" [04:41] X-) === limi Mozilla DOM inspector === limi [~limi@193.71.38.142] has joined #launchpad [05:42] SteveA: (or anyone). How do I get the Person.id of the currently authenticated connection? I'm guessing I need to adapt request to something, but I don't know what something is. [05:43] stub: person = IPerson(request.principal, None) [05:43] if person is not None: [05:43] then you have a valid person, if it's None is an anonymous request [05:43] stub: look at rosetta/browser.py we have code about it there [05:45] ta. [06:30] hmm [06:30] I'm having problems with cStringIO [06:30] TypeError: argument 1 must be file, not cStringIO.StringO [06:32] I thought a cStringIO was a kind of file object [06:35] where is that exception being raised? [06:36] In new code [06:36] Is this when trying to construct a cStringIO? [06:37] data = bz2.decompress(r1.read()) [06:37] parser = apt_pkg.ParseTagFile(StringIO(data)) [06:37] Ah, hmm. [06:37] I guess you'll need to give it a real file then :/ [06:38] really? [06:38] a cStringIO isn't a file, it's just file-like. [06:38] sounds like stupid type checking in APT [06:38] Sounds like apt_pkg could be a bit smarter. [06:38] well, I will use a temporal file then... [06:38] But it may actually expect to pass the C layer an actual FILE * or something. [06:38] ah, hmm [06:38] Yeah, use the tempfile module I guess. [06:39] in that case, the C library is stupid :) [06:39] daf: :-P [06:39] mdz: no offence meant [06:40] Heh. [06:40] seriously, it seems useful to be able to parse data you have in memory without having to write it to a file [06:43] perfect [06:43] we have now a way to get the list of packages from warty [06:43] :-) [06:44] and it's only 15 lines of code [06:46] isn't this what grep-dctrl does? :) [06:47] daf: I think it's more robust if we have already a parser for the format we need :-P [06:47] of course, the python-apt documentation sucks [06:47] because it's null [06:47] carlos: hmm? [06:47] carlos: aren't you parsing the Packages file? [06:48] Sources.bz2 [06:48] conn = httplib.HTTPConnection("archive.ubuntu.com") [06:48] conn.request("GET", "/ubuntu/dists/warty/main/source/Sources.bz2") [06:50] curl http://archive.ubuntu.com/ubuntu/dists/warty/main/source/Sources.bz2 | bzcat | grep-dctrl -n -s Package -e . [06:50] :) [06:51] daf: error handling? [06:51] daf: and what happens if you want other fields? (like we need) [06:51] :-) [06:52] just pulling your leg :) [06:52] :-P [06:54] I need some food... [07:22] limi: I've implemented the "logged in as" feature [07:22] limi: now it's your job to make it pretty :) [07:23] hehe === limi has promised to save Malone first === daf nods [07:23] whenever you have the time... [07:23] daf: do you need any source or binpackage in rosetta ? [07:24] daf: cause I'll delete them and use real one instead [07:25] no, we don't need them, I don't think [07:31] daf: ok, they will be deleted then [07:31] deleted from where? [07:39] daf: python-apt is weird [07:40] mdz: seems so [07:41] mdz: it's not the C library making this requirement then? [07:42] if (PyArg_ParseTuple(Args,"O!",&PyFile_Type,&File) == 0) [07:42] ewwwww [07:43] daf: it actually needs a file descriptor [07:43] because that is what the underlying library expects [07:43] ah, right [07:43] doesn't the underlying library have a way of parsing an arbitrary chunk of data? [07:43] I want to rewrite libapt-pkg in python :-( [07:44] wouldn't that mandate rewriting apt itself in Python? :) [07:44] daf: any rfc2822 parser should do [07:44] daf: yes, it would be delightful [07:44] hmm, good point [07:44] no, I don't think it has an in-memory tagfile parser [07:45] daf: there are a whole bunch of Debian control file parsers floating around [07:45] there's one in linda [07:45] on second thoughts, I don't think you could send a Sources file to the rfc822 module [07:45] there's one in apt-listchanges [07:45] (python implementations) [07:46] that's silly [07:46] of course, if python-apt sucks... [07:46] python-apt doesn't suck; it's just not very python :-) [07:46] it's very apt [07:46] mdz: I saw it, and they also relay on python-apt, only for the version comparation algorithm [07:47] carlos: right, because that bit is difficult, and the tag file parser is easy :-) === carlos talks about apt-listchanges [07:47] :-P [07:47] the world could use the One True Python Tag File Parser, though [07:47] one with a nice iterator interface [07:47] yummy [07:50] anyone know if there is someway to get a reference to the request if it has been lost? === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has left #launchpad [] [07:53] stub: you can get it from the interaction [07:53] but, why has it been lost? [07:54] Because one of Zope's classes doesn't want to pass it on :-( [07:54] oh sucky [07:54] well, there's a getInteraction somewhere [07:54] and the interaction knows about the request [07:55] The zcml addform directive creates a view on a container. This view creates subobjects. These subobjects have no access to the request as far as I can tell. The container also doesn't have access to request, so can't fix it up in its hook either :-) [07:56] a container should not have access to a request [07:56] as it is an app object, not a view [07:57] Yup. And I don't want to subclass the addform view if I can help it, cause then I'd have to manually assemble the view rather than use the addform zcml directive. [07:58] So where is this interaction? My use case for it dissappeared before it was implemented :-) [07:59] (or the principal will do in this case...) === stub tries zope.security.management.getInteraction() === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #launchpad === lifeless [~robertc@dsl-66.7.240.220.rns01-kent-syd.dsl.comindico.com.au] has joined #launchpad [09:06] New bug 2055 for Launchpad/Soyuz: Should store gpg keysize in database [09:06] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2055 === lalo [~lalo@201.3.157.110] has joined #launchpad === elmo__ [~james@83.216.141.215] has joined #launchpad === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad === lalo returns === elmo [~james@83.216.141.215] has joined #launchpad === lalo [~lalo@201.10.27.117] has joined #launchpad [10:21] New bug 2056 for Launchpad/Soyuz: Sort out component of "inherited" packages in derivatives. [10:21] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2056 === lalo [~lalo@201.10.27.117] has joined #launchpad === lalo [~lalo@201.10.27.117] has left #launchpad [] === lalo [~lalo@201.10.27.117] has joined #launchpad === lalo [~lalo@201.10.27.117] has joined #launchpad === cprov [~cprov@224-21-161-212.DSL.ONCOLT.COM] has joined #launchpad