tag was enough [10:19] SteveA: I've copied you [10:19] I suppose it's a scope problem [10:19] if you can produce a minimal example, then i can probably explain what is going on, and see if it is a bug in page templates. === zyga [n=zyga@2-mi2-1.acn.waw.pl] has joined #launchpad [10:29] SteveA, https://chinstrap.ubuntu.com/~dsilvers/paste/fileAhWTyu.html vs. https://chinstrap.ubuntu.com/~dsilvers/paste/fileZNg3lJ.html [10:29] That's the only change I did [10:30] ah [10:30] okay, so in the example that didn't work, you weren't actually defining the macro at all [10:30] because you were using the define-macro in a part of the template that was being thrown away [10:31] yeah, I guess [10:32] carlos: hello [10:32] zyga, hi [10:34] SteveA, I need to send an argument to that macro, something like a fill-slot but as a [10:34] SteveA, I don't see anything about that in our FAQ [10:34] zyga, I suppose you want to talk about GNOME imports, right? [10:38] dogfood back running, thanks for your patience [10:40] carlos: you cannot put arguments into a macro. there are other ways to do what you need to do. [10:40] for example, you can put the define="..." around the use-macro [10:44] carlos: exactly [10:44] carlos: pitti told me yesterday that they are invoked manually [10:45] carlos: but since 2.12 is already frozen we could trigger that import to get an up-to-date view of the situation [10:45] (especially since polish translators were busy enough to get near 100%) :-) [10:51] SteveA, something like?: [10:51] metal:use-macro="template/macros/translation-suggestions" [10:51] tal:define="submissions python:messageSet.getSuggestedSubmissions(index)"> [10:52] carlos: maybe. i don't know if that will work. i'd say, to be clear, .... [10:52] zyga, we are not imoporting any GNOME module outside the Ubuntu's packages we have that is done automatically [10:53] SteveA, I have that already [10:53] SteveA, but when I try to use submissions inside the macro, I get a KeyError [10:54] I tried to move the tal:define inside the meta:use-macro with the same error [10:54] stub: help! [10:54] eh? [10:55] I need to get "make check" in launchpad to apply BranchDataStorage.sql before running tests [10:55] since I'm in a launchpad/branches sprint now [10:55] I renamed pending/BranchDataStorage.sql to patch-25-22-0.sql [10:56] carlos: show me the code [10:56] and tried cd database/schema ; make [10:56] but then I get [10:56] 08:52:14 CRITICAL patch-25-22-0.sql failed to update LaunchpadDatabaseRevision correctly [10:56] jamesh: ping ? [10:57] Add to the end of the patch 'INSERT INTO LaunchpadDatabaseRevison VALUES (25, 22, 0)' [10:57] SteveA, https://chinstrap.ubuntu.com/~dsilvers/paste/filexc96R7.html [10:57] stub: how should I diagnose/fix handwave-away the problem? [10:57] ddaa: Actually - pick a higher number like 78 or something - makes it easier for me if it accidently lands in rocketfuel [10:57] SteveA, the raises the KeyError [10:57] inside the macro definition [10:58] ddaa: (ie. call itpatch-25-90-0.sql, with 'INSERT INTO LaunchpadDatabaseRevision VALUES (25, 90, 0)' added to the end) [10:58] ack [11:00] hu... ha, okay, I see, the Makefile checks whether the LaunchpadDatabaseRevision table looks consistent with the names of applied patches [11:01] carlos: although you can say , I think it reads more clearly to always use tal:condition [11:01] so, use [11:01] that way, people can visually scan the source for tal:condition [11:02] ok [11:02] so, you have: [11:02]

[11:02] [11:02] [11:02] you're defining a macro [11:02] however, the macro will still be output at this point in the template [11:03] there is no variable 'submissions' defined at this point [11:03] right [11:04] you have a choice. you can choose that you want to display the macro here, where is is defined, so you need to make 'submissions' mean something. or say tal:condition="submissions|nothing". OR, you can decide you don't want to show the contents of the macro here, and surround it in tal:condition="nothing" [11:04] how could I do to fix that? [11:04] hmmm [11:04] last option looks better [11:04] stub: now, it blows up in the "* Security setup" [11:04] File "security.py", line 237, in main [11:04] assert obj_name in schema.keys(), 'Bad object name %r'%(obj_name,) [11:04] AssertionError: Bad object name 'public.changeset' [11:05] Did we drop the changeset table? [11:05] Merge to rocketfuel@canonical.com/launchpad--devel--0: debbugssync, hct enabling, and ui fixes. r=jamesh (patch-2018: mark.shuttleworth@canonical.com, scott@canonical.com) [11:05] Merge to thelove@canonical.com/bazaar--devo--1.5: Fixed relative dest path for "baz export" (used to panic), mini API for management of user errors (patch-63: Matthieu.Moy@imag.fr) === ddaa checks [11:05] Or renamed it? Same effect [11:06] SteveA, thanks [11:06] it should become 'revision' [11:06] Yes, "ALTER TABLE Changeset RENAME TO Revision;" [11:06] where are the security chicken bones, so that I rethrow them? [11:07] ddaa: Edit security.cfg and change references to public.changeset to public.revision [11:07] ack [11:07] (in database/schema) === jinty [n=jinty@205.134.224.215] has joined #launchpad [11:09] jamesh: ping [11:19] stub: now, I have a sampledata conflict. I reverted my tree and db, but I'm looking for the magic word to apply the db patch to the live sampledata so I can "make newsampledata". How do apply a sql patch on the sampledata? [11:21] jamesh: ping [11:21] First build a fresh database without your patch (rename it to something not patch-25-??-?.sql to do this) [11:22] ddaa: Then run your patch manually (psql -d launchpad_dev -f my-renamed-patch.sql) [11:22] ddaa: Then modify your sampledata, and run 'make newsampledata' as per the documentation === BjornT heads out for lunch and some appointments [11:23] ddaa: You can then put your dbpatch back in place [11:23] (yes - this is a pita but I'm not sure if it can be improved easily without making other compromises) === carlos -> breakfast === niran [n=niran@cpe-67-10-213-51.houston.res.rr.com] has joined #launchpad === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad [11:45] i'm trying to get a bazaar mirror of a project that's currently developed using cvs, so if i register the project with launchpad and tell it the cvs server, will the mirror automatically be created? [11:45] spiv: ping? [11:46] stub: I have another problem... [11:46] When trying to update the sampledata, I get this error: [11:46] psql:pending/BranchDataStorage.sql:88: ERROR: new row for relation "branch" violates check constraint "valid_name" [11:47] oh... [11:47] I think I see... the update script produces a number of empty names... [11:47] niran: it will get tested for importabailty yes [11:47] also, we are going to need to add "@_" as valid chars for branch names [11:47] niran: and you can chat with jblack or ddaa here to get the mirror checked more carefully [11:48] stub: is that okay to add those chars to the valid_name regex? [11:48] lifeless, ok, thanks [11:48] ddaa: There is already valid_branch_name - use that. We can't add those characters to valid_name [11:48] I must have added it after creating that basic patch. [11:48] Oh, right, I missed it in my confusion :) === ddaa now tries to find out where the empty names come from === zyga [n=zyga@2-mi2-1.acn.waw.pl] has joined #launchpad [11:59] Kinnison: pong [12:00] spiv: any chance you can go over the remaining stuff in cprov's buildd branches? [12:00] spiv: We need them mergable asap [12:01] jamesh has done a bunch of review already and I believe cprov has dealt with most, if not all, of his comments [12:03] Kinnison: Ok. celso.providelo@canonical.com/launchpad--buildd--0 and celso.providelo@canonical.com/launchpad--buildd-queuebuilder-archaware--0? [12:04] cprov: ? [12:04] Kinnison: spiv: yes, they two [12:04] carlos: is there any way to star translating a template without any translated messages? [12:05] cprov: Ok. [12:08] zyga, sure [12:08] spiv: great, special attention to the buildd which contains killing process issues, would be nice if you can suggest something based on your librarian experience [12:08] zyga, 'morning zyga... how went your installation tests of breezy?:) [12:08] zyga, why do you think you cannot do that? [12:08] zyga, in the translation side of course. [12:09] cprov: I'll take a look, but the librarian never spawns subprocesses, so I don't think there's any particular insight to be gained there. [12:09] pqm does [12:09] so whatever you do, it can feed inot PqmRobustness :0 [12:10] spiv: right, get inside, you'll probably have something better than that in mind [12:11] WaterSevenUb: morning :-) [12:11] WaterSevenUb: pretty good but I've found one annoying issue [12:12] WaterSevenUb: installation path: warty->upgrade is terrible due to clashes in xfree86-common and xorg.common (rgb.txt somewhere) [12:12] WaterSevenUb: as for colony CD it's not perfect yet but I'm already pulling the fresh one :) [12:12] zyga,and what about those issues of "Time Zone Configuratoin" and "ubuntu configuration" (post-install)... did you find them? [12:13] WaterSevenUb: well I'd love to but those templates just don't appear on the list [12:13] WaterSevenUb: no, they were not in any of the .po files breezy has - probably unmarked [12:14] zyga, well... the point is .... should we annoy Carlos again to point us someone we could talk to before we report the problem somewhere?;) [12:15] carlos, :) [12:15] WaterSevenUb: I'd rather grep the source package [12:16] WaterSevenUb: write a patch and then annoy the hell out of people :) [12:16] WaterSevenUb: similar case: 'hibernate this computer' [12:16] WaterSevenUb: do you know where that is? [12:17] zyga, that one is on my "todoWhereTo" list too :) [12:18] WaterSevenUb: translators should be able to pull a list of .pot files with *every* string extracted [12:18] and a list with only marked strings extracted [12:18] that would solve 99% of the problems [12:18] if we had a clone of pitti he could spare some time to do this === hannosch [i=hannosch@d194177.adsl.hansenet.de] has joined #launchpad [12:22] jordi: ayt? [12:23] zyga, yeah, I agree. [12:23] WaterSevenUb: I'll be hacking synaptic in the meantime, minor issues though === Keybuk [n=scott@syndicate.netsplit.com] has joined #launchpad === ddaa just notice some minor synaptic UI crack [12:27] ddaa: ? [12:27] zyga: when running it for the first time, after updating packages, it displays a dialog "everything went fine" with a checkbox to automatically close the dialog at the end of future updates. [12:27] Clicking on the checkbox closes the dialog. [12:28] That is helpful, in the sense that when you click the checkbox, you want the dialog to go away pretty soon, but that is suprising because, well... checking a checkbox should not close the window! [12:28] just a minor WTF, not really a blocker [12:33] WaterSevenUb, zyga I cannot help you too much with that kind of issues as I hadn't time too look into those things. Usually, is better if you ask the maintainer of those packages or the Ubuntu team if you don't know the exact package. [12:35] carlos: that's okay - we know you are really busy :) [12:38] zyga, thank you [12:38] stub, what's the ETA finish for the whitespace script on staging? [12:38] 2006 [12:38] haha [12:39] carlos: 10.2459 done (400000 of 3904014). eta 21:24:20.121362 [12:39] lifeless, kiko would hate you :-) [12:41] stub, thanks [12:41] lifeless: i haven't received a reply from pqm yet [12:42] did you check the pqm status page? === carlos -> shower [12:42] carlos: why is synaptic not in rosetta? [12:42] http://pqm.ubuntu.com/ [12:42] suggests you should not have [12:42] cprov, spiv: It seems jamesh was reviewing one of the branches, Can you coordinate and check that everything looks sane on that? [12:42] lifeless: thanks [12:43] carlos: (as far as /pl is concerned) [12:45] carlos: synaptic + rosetta = b0rked https://launchpad.net/products/synaptic/+translations === asgeirf [n=asgeirf@203-173-59-20.dyn.iinet.net.au] has joined #launchpad [12:58] is launchpad still donw? I still can't open launchpad integration pages.. [12:59] zyga, automatic imports are off for a couple of days while pitti does some changes to the buildd <-> rosetta path, it should be restored soon and synaptic will appear [01:00] stub: I'm almost there, but I still need your help for a little thingy [01:00] 10:58:16 WARNING No permissions specified for ['"public"."branchmessage"', '"public"."branchsubscription"', '"public"."revisionparent"'] [01:00] what should I do to make it happy? [01:02] ddaa: You need to add some security declarations to security.cfg for those tables. Currently only superuser accounts have access to them, which is a problem. [01:02] Well, I do not think that any code is actually using those, yet... [01:03] so it's not a terribly big problem, but lifeless thinks I should fix the problem right now. [01:03] ddaa: Then ignore the warnings. If you want to silence them, stick a section 'public.branchsubscription=' in the [public] section should do the trick [01:03] nothing after the = sign? [01:03] ddaa: Nope. That explicity says 'give no permissions' [01:04] thx [01:04] So anything attempting to access them will raise an exception, and the relevant entries added to security.cfg then. [01:04] Yup, way to go. [01:05] I'm not going to give speculative permissions that I will forget about and which will come back to hit me later. === Keybuk [n=scott@syndicate.netsplit.com] has joined #launchpad [01:17] WaterSevenUb: do you know where can we translate lanuchpad integration details? [01:19] zyga, no. Let me know if you find it. I will let you know if I find it. (I'm currently busy ) === dand [n=dand@gw.datagroup.ro] has joined #launchpad [01:27] WaterSevenUb: well... that was easier than I though ... apt-get source launchpad-integration === zyga_ [n=zyga@2-mi2-1.acn.waw.pl] has joined #launchpad === Nafallo [n=nafallo@unaffiliated/nafallo] has joined #launchpad === niemeyer [n=niemeyer@mandriva/developer/niemeyer] has joined #launchpad [01:46] Morning! [01:49] spiv: ok, nice idea to kill process, I'm implementing it . [01:50] cprov: No worries. [01:50] cprov: I'm about to go to bed, so if you want anything else from me, send me an email and I'll do it tomorrow morning. [01:51] (I see that jamesh has followed up to the reviews) [02:02] thanks spiv === Kinnison ruffles === BjornT [i=10183@82-135-221-189.ip.takas.lt] has joined #launchpad [02:34] right [02:34] so next thing to try [02:34] cd /tmp [02:34] hct source dbus [02:35] File "/home/niemeyer/src/mango-sorbet/pybaz/backends/forkexec.py", line 384, i raise ExecProblem(self) [02:35] ExecProblem: baz exited with code 2 (expected exit code 0) [02:35] argv: 'get', 'TO-BE-DELETED@REALLY-DO-NOT-USE.ubuntu.com/dbus--orig--0.36.2--pat* error report [02:35] get: could not connect to the archive for (TO-BE-DELETED@REALLY-DO-NOT-USE.ubunt2005-09-05 09:34:40,373 INFO hct.source.SourceTree.Library Removing library [02:35] ah, d'oh [02:35] baz register-archive sftp://casey.ubuntu.com/srv/launchpad.ubuntu.com/archive [02:35] and try again :p [02:36] (you may have to delete a "dbus" directory) [02:37] Hummm.. [02:37] It looks like I don't have an account on that machine [02:38] elmo: ? ^ [02:38] Humm.. [02:38] I do [02:38] you should have an sftponly account [02:39] I thought the mail to db.warthogs.hdb.com would install the key everywhere, but it looks like it wasn't the case. [02:40] Ok, I've registered the frightening TO-BE-DELETED@REALLY-DO-NOT-USE.ubuntu.com archive. :) === dand [n=dand@gw.datagroup.ro] has joined #launchpad [02:41] it's supposed to, bug elmo about that [02:41] yeah, Mark picked that name [02:41] it's trying to hint that you shouldn't branch off it [02:42] ah ... elmo's actually usefully given you an account [02:42] (a real one, that is) === niemeyer hct source dbus [02:43] Great! [02:43] I've installed my key manually, so everything is fine now. :) [02:43] You've mentioned that I'd need Launchpad working. What parts of hct interact with launchpad right now? [02:44] right [02:44] so mango-sorbet is my development config, which I use for testing distro-side stuff [02:44] it's got two main bits in it ... [02:45] hct -- which is the generic module bit, the utility library (hct.util) and the command-line interface (hct.cli) [02:45] sourcerer -- which is the source package importer -- it uses hct, but isn't "part" of it [02:45] it doesn't have any of the launchpad stuff [02:45] now, if you look at your launchpad config, it also has a lib/hct and lib/sourcerer which match these two [02:46] launchpad also has the server-side stuff [02:46] lib/canonical/launchpad/hctapi.py <-- the direct-to-database backend code [02:46] lib/canonical/launchpad/daemons/trebuchet.py <-- the xml-rpc server [02:47] Hummm... I see [02:47] so, how the backends work: [02:47] hct doesn't have any real concept of a source package, or how to find them. or anything like that. It just wants a Manifest object [02:47] so it uses a backend to convert an arbitrary string into a Manifest object [02:48] so when you typed "hct source dbus", the following happened: [02:48] - it parsed it as a URL, saw there was no scheme, so added the default ("hct") scheme to it [02:48] - it looked up the handler for the "hct" scheme (hct.backends.xmlrpc) [02:49] - it called the hct.backends.xmlrpc.get_manifest() function passing "hct:///dbus" to it [02:49] - the backend made an XML-RPC call to the trebuchet server on casey [02:49] (but with the "hct:///" bit stripped off) [02:49] - trebuchet made the same call to hctapi.get_manifest() [02:50] - which parsed the string, looked up the record in the database, and made a Manifest object [02:50] - trebuchet pickled the Manifest object by turning it into XML [02:50] - the xmlrpc backend unpickled it and returned it [02:50] -- [02:51] there's two backends in hct -- xmlrpc which handles the "hct" scheme and is the default [02:51] and xmlfiles which handles any other scheme [02:51] so, infact, you can do something like: [02:51] hct source file:///tmp/dbus/{hct}/++manifest [02:51] (I'm following.. keep going :) [02:52] that'll parse it as a URL, see the "file" scheme, use the hct.backends.xmlfiles.get_manifest() function which treats the rest of the string as a filename, and loads it directly [02:52] the logic for all of this is in hct.url [02:53] backend modules "plug" themselves into that [02:53] the top of hct.cli.command imports the xmlfiles and xmlrpc backends to make sure they're both available [02:53] the top of sourcerer.bubblewrap imports the hctapi backend from launchpad (which shares the API) [02:54] the hctapi backend is the "best" so the "lp:///" scheme it implements becomes the default [02:54] so using the hct code within sourcerer reads and writes directly to/from the database rather than going over xml-rpc [02:55] Who's the guy parsing the manifest [02:56] (and doing something useful with it) [02:56] ? [02:56] depends what you mean by parsing [02:56] if you're reading a database object, it's hctapi [02:56] Sorry.. rephrasing [02:56] if you're reading an xml file, it's xmlfiles [02:56] if you're reading an xml-rpc response, it's xmlrpc (which actually uses xmlfiles) [02:56] Who runs baz by looking at the manifest? [02:56] hct.manifest [02:56] and, partly, hct.sourcetree [02:58] Right === mpt [n=mpt@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [03:00] that stuff needs cleaning up a bit, I want to move a lot from sourcetree into manifest itself === mp1 [n=mpt@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === mpt [n=mpt@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [03:01] You mentioned that sourcerer reads/writes directly to/from the database. It looks like it asks the backend to do that, and the backend is xmlrpc. What piece am I missing? [03:01] at the top of bubblewrap it imports "canonical.launchpad.hctapi" [03:01] which is in launchpad/lib/canonical/launchpad/hctapi.py [03:02] that registers itself as a backend with a higher priority than the xmlrpc one [03:02] (and with the "lp:///" scheme) [03:02] Ah, ok [03:02] So it doesn't use xmlrpc when being run from launchpad [03:02] right [03:02] make a copy of your launchpad tree (or another get) [03:03] then: [03:03] baz switch -d launchpad scott@canonical.com--2005/launchpad--sourcerer-production--0 [03:03] baz switch -d launchpad/lib/hct scott@canonical.com--2005/hct--devel [03:03] baz switch -d launchpad/lib/sourcerer scott@canonical.com--2005/sourcerer--devel [03:03] -- [03:04] you'll then get a scripts/sourcerer-import.py [03:04] as this deals with the database directly, it cheats and uses the hct.where_am_i() function to construct a url with an "lp:///" scheme -- forcing the database backend to be used for the import === niemeyer cp -r launchpad launchpad-scott [03:07] Keybuk: I'd like to build a "package" from scratch (rather than asking sourcerer to import it). Is it possible? === niemeyer baz build-config coffee [03:09] nope [03:10] it will be, one day, but right now existing sources is much more important [03:13] Sure.. I'd just like to go through the process to understand it. [03:13] I'll try to follow it internally === niemeyer switching launchpad [03:18] Keybuk: Is there any dummy database backend which doesn't require launchpad/a xmlrpc server to be running? [03:19] no, unless you could the xmlfiles one [03:19] which only implements the get_manifest function [03:22] Keybuk: Is hct currently storing anything in the database, besides manifests? I mean, those entries mentioned in the manifest, they're all under a baz archive, right? [03:24] right [03:24] so there's a bunch of tables [03:24] Manifest -- which is the top-level table [03:24] ManifestEntry -- which is the record for each entry in the manifest, and linked to the top-level table [03:24] ManifestAncestry -- which records the descent of each manifest, which one it was based on and which were "merged in" [03:25] each ManifestEntry references Branch and Changeset, which in turn reference ArchNamespace and ArchArchive, etc. [03:25] those are the ones we write to [03:25] we read from quite a few, the Product, ProductSeries, ProductRelease descent [03:25] and the Distribution, DistroRelease, SourcePackagePublishingHistory, SourcePackageRelease descent [03:26] but we never create those, we rely on dyson and gina (respectively) to do that [03:27] Ok [03:29] What's PQM's situation currently? [03:29] there's a spec (DevelopmentManifests) for adding another table to link Person to Manifest (so you can have "my dbus") but that's still a spec [03:29] it's almost 10 minutes work, but depends on a bunch of stuff to be useful, so it's waiting in the wings [03:30] Kinnison: possibly it got lost with spiv's job at 8 AM [03:30] Understood [03:30] lifeless: or elmo: could you kick PQM ? [03:33] done === Keybuk goes for lunch === Nafallo [n=nafallo@unaffiliated/nafallo] has joined #launchpad [03:43] lifeless: thank you === sabdfl [n=mark@217.205.109.249] has joined #launchpad [04:05] mpt: are kiko and salgado around? [04:07] carlos: we have a problem [04:07] Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=spiv] something/enumvalue:VALUE for page templates (patch-2344: steve.alexander@canonical.com) [04:08] we should not have the review-foobar-1 templates building up like this [04:10] sabdfl: No, I'm not sure where they are [04:11] kiko came back from Rio last night, apparently [04:11] mpt: k thanks [04:11] and salgado left the apartment before I did, I think, but he's not here, so I'm not sure where he is [04:11] could you ask kiko to ping me when he gets in? [04:11] sure [04:11] thanks [04:11] how's it going over there? [04:11] the usual [04:12] Warm, windy, and not enough RAM for baz :-) [04:12] does anybody else have the ./makepagetest thing fail? SteveA? [04:12] assert (request and response) or not (request or response) [04:12] AssertionError [04:12] is the end of the traceback === Seveas [n=seveas@seveas.demon.nl] has joined #launchpad [04:13] sabdfl: interesting. there are a couple of open bugs on it. can you put the whole traceback in https://chinstrap.ubuntu.com/~dsilvers/paste ? [04:14] https://chinstrap.ubuntu.com/~dsilvers/paste/file7ljmEl.html [04:14] sabdfl: kiko just called me -- he's working on the monthly report for Jane, and he'll be in the office in about 1.5 hours [04:15] mpt: thanks [04:15] sabdfl: do you still have /tmp/page-test.2gvIFd around? [04:17] slinky% ls -al /tmp/page-test.2gvIFd ~/projects/ubuntu/launchpad [04:17] total 72 [04:17] drwx------ 2 mark mark 4096 2005-09-05 15:12 . [04:17] drwxrwxrwt 22 root root 12288 2005-09-05 15:16 .. [04:17] -rw-r--r-- 1 mark mark 1729 2005-09-05 15:11 watch0001.request [04:17] -rw-r--r-- 1 mark mark 24473 2005-09-05 15:11 watch0001.response [04:17] basically, there is some request data that did not meet with a response. the zope test creation stuff is bitching about that. [04:18] -rw-r--r-- 1 mark mark 1731 2005-09-05 15:12 watch0002.request [04:18] -rw-r--r-- 1 mark mark 24483 2005-09-05 15:12 watch0002.response [04:18] yes [04:18] interesting [04:18] okay, can you tar that directory up, and mail it to me [04:18] i'll be able to use that to see what's up [04:18] i've noticed it does some weird stuff, like reordering the pages sometimes [04:18] there are quite a few dirs like that [04:18] do you want the lot? [04:18] just the one called /tmp/page-test.2gvIFd [04:19] that's the one that caused it to fail [04:19] it was small [04:19] you got the lot [04:19] it's been failing quite a bit for me [04:20] right now it just will not handle the sequence of pages i am trying to record === mpt [n=mpt@200-171-140-32.dsl.telesp.net.br] has left #launchpad [] === mpt [n=mpt@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [04:23] there's nothing obviously suspicious about the captured data. i'll run it through the "create a page test from this" thing, and see why it is failing. === segfault1 [i=carlos@prognus.com.br] has joined #launchpad === zyga [n=zyga@2-mi2-1.acn.waw.pl] has joined #launchpad [04:33] okay, reproduced the error [04:36] phew [04:36] my hair loss is accelerating [04:36] SteveA: heya [04:36] not one of my attempts has worked :-) [04:36] i haven't fixed the error -- just reproduced the exact problem with the data you have sent to me [04:36] but, gimme a few minutes... [04:37] hi ddaa [04:37] SteveA: got a problem with the new Branch goo. [04:37] ddaa: can we talk in 15 mins? [04:37] SteveA: who else knows NotFoundError on attributes with new interfaces? [04:37] SteveA: we'll ask them [04:38] Bjorn may be able to help [04:38] BjornT: ping [04:38] hi lifeless [04:38] BjornT: we may have solved it, una momento [04:39] BjornT: we have, never mind [04:39] cool [04:39] did not save interfaces/pyarch.py after remove the IBranch from __all__ there... [04:42] Merge to rocketfuel@canonical.com/launchpad--devel--0: Added initial support to show suggestions for multiline entries r=kiko (patch-2345: carlos.perello@canonical.com) === dand [n=dand@gw.datagroup.ro] has joined #launchpad [04:51] sabdfl: want an instant totally hackish fix? [04:52] python -O makepagetest.py (usual args here) [04:58] hmm, I appear to have misunderstood the way Python's logging works [04:59] if I have Logger("foo") and Logger("foo.child") [04:59] and foo's level is 30, but foo.child's is 10 [04:59] I thought foo.child.debug(...) shouldn't appear, because it's parent level is higher === dand [n=dand@gw.datagroup.ro] has joined #launchpad [05:13] Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=spiv] Additions and some minor bug fixes to the email interface. (patch-2346: bjorn.tillenius@canonical.com) === Lovechild [n=dnielsen@0x50c71cc7.adsl-fixed.tele.dk] has joined #launchpad [05:18] SteveA: How's menus going? [05:19] mpt: very nicely! a little later today, you'll have some page<->menu assignment to do [05:19] but now, i must go out and collect a bicycle. [05:20] heh, cool [05:21] it's taking way too long to walk to the office [05:21] so, bjorn inspired me to get a bike [05:23] I have a bike, and I was going to spend this lunchtime getting a helmet [05:23] but I'm too hungry [05:25]