[00:01] losa ping! [00:01] mwhudson: yo! [00:01] spm: it's the pick-a-staging-import-slave and run http://pastebin.ubuntu.com/411296/ time [00:02] (hopefully with correct urls this time) [00:02] * thumper heads for coffee [00:02] mwhudson: nah; just make em up; urls are overrated [00:03] mwhudson: that doesn't store the git tree properly though [00:03] spm: :) [00:03] thumper: oh yes, you're right [00:03] * thumper really heads for coffee [00:03] mwhudson: so raspberry again? [00:03] * mwhudson adjusts his iron-o-meter [00:03] spm: no? [00:04] that was a joke - at myself.. but :-) [00:04] oh good [00:04] * mwhudson turns the gain back down [00:04] :-) [00:04] spm: i'll need to whip up another patch first so no hurry [00:05] mwhudson: hrm. yes cause the apply patch in that paste is telling me it's applied already [00:06] mwhudson: the otehr steps are done; fwiw [00:06] oh heh [00:23] thumper: I guessing this is realted to the rt we discussed yesterday? https://pastebin.canonical.com/30326/ [00:34] jelmer: does bzr-git now depend on bzr 2.2? [00:35] jelmer: http://pastebin.ubuntu.com/411354/ [00:35] mwhudson: Have you recompiled dulwich? [00:36] ah [00:36] yes, but probably only with python 2.6 [01:09] spm: can you apply this patch to strawberry's launchpad tree: http://pastebin.ubuntu.com/411369/ [01:11] raspberry? [01:11] some kind of fruit [01:11] not an antartic base [01:11] sweet, that narrows it down fopr me to ~ 80% of our servers... ;-) [01:12] mwhudson: patched [01:14] mwhudson: well that saved me some work for today :) [01:14] mwhudson: testing the kernel? [01:15] thumper: the bzr-git thing? [01:15] thumper: yeah, just hit go like a minute ago [01:15] * thumper watches [01:17] oh, I didn't know you were going to try the kernel again [01:18] the unusual modes thing isn't fixed yet [01:18] although if the batch size is 5k you might not notice it [01:20] Is it faster now? [01:22] wgrant: a full kernel import should be less than 6 hours now [01:22] Wow. [01:23] mwhudson: and not a penguin? [01:23] Isn't that almost three orders of magnitude faster? [01:23] I think we should just use the last 4 hex digits of their IP address [01:24] wgrant: two things made it fast - there was a bug in the sqlite cache that made it store a few billion rows rather than less than a million [01:24] Haha. [01:24] jelmer: ! [01:24] wgrant: and InventoryDirectory.children in Bazaar should be -Devil [01:24] jelmer: in 2a it should be tolerable. [01:24] jelmer: what was it doing that sucked? We can tune it further... [01:24] lifeless: it's still very slow in 2a - I haven't compared it to pack-0.92 [01:25] mwhudson: hi [01:25] jelmer: pack based is full inventory load [01:25] jelmer: so editing one dir is definitely cheaper in 2a :> [01:25] bbs [01:25] lifeless: I'm now walking the git tree objects rather than InventoryDirectory.children [01:25] jelmer: I notice that you have a branch to move upload processing into buildd-manager itself -- why that rather than letting a separate daemon handle upload processing, thus making buildd-manager less horribly slow? [01:26] mwhudson: r u going create guide for launchpad.dev usage as remote access + code_hosting [01:26] We are wasting a *huge* amount of buildd time at the moment because of the synchronous upload processing. [01:26] lifeless: that works well too so there's no need to tweak anymore from bzr-git's POV [01:27] wgrant: It's the first step towards doing things in a more asynchronous manner [01:27] wgrant: and it at least avoids the overhead of importing all of launchpad each time [01:27] jelmer: I'm not sure I see how embedding the synchronous process further into buildd-manager helps with asynchronicity. [01:27] But yes, removing that overhead is a good step. [01:28] pals, could u say how much stuff will be run under 'make run_all' [01:37] You know, that import does seem to be going a little more quickly. [01:42] wgrant: :-) [01:49] SlonUA: I doubt a guide for production use of launchpad.dev will be made - it doesn't make sense :) [01:49] SlonUA: as for what is started by make, you can look at the makefile; or is there some reason you care about what stuff starts ? [01:50] lifeless: thanks for notice ... just interesting about targets in make .. yup i will look [01:51] lifeless: about guide .... yes we have two ... remote access and code-hosting ... but for use together we hadn't ... but i done already ... i just use vm for launchpad.dev [01:52] SlonUA: what do you mean by remote access? [01:53] lifeless: access to launchpad.dev from another host [01:54] mwhudson: I'm curious how fast the second batch will be, since it will have to reconstruct some of the base texts [01:55] It doesn't look like the initial 'finding revisions to fetch:generating index' is any faster. [01:55] wgrant: that really can't be optimized much further, at least not in bzr-git [01:55] no, so maybe we should import even more than 5000 revisions in one go [01:56] mwhudson: yeah, that'd make sense [01:56] It looks like only half the import time was actual rev imports. [01:56] Impressive. [01:58] lifeless: git imports now actually spend most of their time in add_inventory_by_delta() [01:58] jelmer: interesting [01:58] jelmer: how well does that perform for you ? [02:02] lifeless: reasonably [02:03] lifeless: it just happens to be the main bottleneck left [02:17] it seems like the second kernel import is quite a lot slower [02:18] still 100 times faster than what's in production, mind... [02:21] will be interesting to watch how it slows [02:22] hmm, I wonder why postgresql 8.4 didn't restart automatically on restart [02:28] mwhudson: I'm removing the is_personal_branch from IBranch and adding supports_short_identities to BranchTarget [02:28] mwhudson: after a talk with jml this morning [02:28] thumper: +1 [02:48] * mwhudson afk for lunch/emma collection [04:51] mwhudson: watching the git import speed on strawberry [04:51] thumper: it seems to be doing about 150 revs a minute? [04:51] it spends < 50% of the time doing the import [04:52] 25min for 5000 [04:52] so about 200 per minute I guess [04:52] the rest is determining revisions, packing et al [04:52] and overhead [04:52] do you think 5k is big enough? [04:53] mm [04:53] 10k maybe? [04:53] 10k sounds about right [04:53] could even go higher i guess [04:53] lemme check the memory usage [04:56] is the same number used by bzr-svn for the incremental imports? [04:57] currently yes [04:58] but that'll be very easy to change to something separate [04:58] actually the number per minute seems to vary wildly [04:59] Hm, it's already up to 50 minutes per run? [04:59] wgrant: but seems relatively constant [04:59] wgrant: and I'm not sure that strawberry is particularly fast [04:59] IIRC the production import started at ~3 hours, and is now >20. [05:00] wgrant: much of that we think is dealing with the gazillion row sqlite db [05:00] wgrant: let it run for a day and see where we are [05:00] when select count(*) from trees; takes an hour... [05:00] Right, but I'm just saying that initial looks can be deceiving. [05:00] Heh. [05:01] mwhudson: want to get those bzr-git changes into a branch for me to review? [05:01] And it's already taking almost twice as the first couple... [05:01] thumper: yeah ok [05:01] wgrant: don't panic [05:02] mwhudson: how's the non-git work going? [05:03] I guess even at this speed it will be done in two or so days. [05:03] A tad better than production! [05:04] thumper: i think the first pipe that changes codehosting is basically done, barring the fact that most of the new docstrings are "XXX" [05:04] :) [05:05] this import run is down to 50/minute [05:05] for the last 10 minutes anyway [05:07] thumper: It looks like around 200 from here... [05:08] variable... [05:12] How do production's DB indices compare to the distributed schema? [05:12] what do you mean ? [05:13] Is the dev schema kept up to date with index changes that presumably occur first on production? [05:14] usually yes; [05:14] every now and then you'll see stub add a db patch saying 'already done' [05:14] but usually they are done in dev and cp'd to prod [05:14] Aha. [05:15] They have to be the same - the same tools used to upgrade dev databases are used to upgrade production databases. [06:17] Is the destination select in the PPA copy form broken? I'm trying to copy packages to Lucid but getting told "The The following sources cannot be copied: slony1 1.2.20-1~launchpad.hardy1 in hardy (same version already has published binaries in the destination archive)" [06:19] stub: Where are you copying to/from? [06:20] Both archive and series are important. [06:22] mwhudson: Landed; thanks. [06:32] wgrant: I'm trying to copy from https://edge.launchpad.net/~maxb/+archive/launchpad/+copy-packages [06:33] I need to get the packages rebuilt for lucid [06:34] stub: You can't use an intra-PPA copy to do a rebuild. [06:34] That would result in different binaries with the same name. [06:34] Which makes me think the form is bogus, since it is asking me for the series. === jtv is now known as jtv-afk [06:34] That's useful for when you want to copy to another PPA. [06:35] But yes, it should more obviously forbid source-only copies to the same PPA. [06:35] So I can copy it to my PPA with the same series, and then rebuild it in my PPA? [06:35] You could do that, but you won't be able to copy it back in. [06:36] This all seems terribly arbitrary and confusing to an outsider. [06:39] Garh.... deleted the previous copy (for karmic, now useless), and still get the same error message. [06:39] I think I need to delete the PPA [06:40] You cannot ever have different binaries of the same name again. [06:40] The restriction is not arbitrary and confusing -- you cannot have multiple distinct files of the same name in the same PPA, because that is a lie and is very confusing. [06:41] However, we may eventually have a facility for requesting binary rebuilds which append some as-yet-undecided string to the version. [06:43] (note, however, that this is the Soyuz definition of 'eventually') [07:05] good morning [07:29] morning adeuring! [07:30] thumper: ref that configs merge proposal. 1. +1, 2. unless I hear otherwise in the next 2-3 mins :-) I'll submit the merge for you [07:57] thumper: scratch that merge via me - appear to be having key issues between me/bzr/pqm dued to a new key of mine; so will need to fix that. aka yak shaving. probably quicker if you submit when ready. [08:15] noodles775: Can I move lp.soyuz.browser.archive.traverse_distro_archive to Distribution.getArchive and export it? It does violate the separation a little more than now, but such is life with the webservice... [08:16] mwhudson: did you see this earlier? staging codehost: https://pastebin.canonical.com/30326/ appears to be a diff one to your other patch I've been using. [08:17] spm: that one's thumper's fault! [08:18] spm: i guess hacking out the update_preview_diff section from the config will let it start it up [08:20] mwhudson: oh fun :-) [08:21] mwhudson: semi seriously tho - is it problematic that these sorts of changes can get past the test suite to blow up staging? ie is this testable and hence do I need to bug report? [08:21] Speaking of configs... is edge going to update at some point? [08:21] heh; not if staging blows up. [08:21] But I thought the config key removals were reverted :( [08:21] the updates typically run; crash; so we roll back. [08:23] spm: i guess buildbot/ec2-when-run-by-a-launchpad-dev could test that all the configs in the lp:lp-production-configs branch load [08:24] interesting. the edge updates aren't actually disabled atm; and should be running right now. [08:24] mwhudson: You mean like is suggested in bug #557271? [08:24] Bug #557271: Unable to remove config entries from the schema [08:24] spm: at least thumper's branch is only on db-devel [08:24] haha. failing to build/sync. blech. [08:25] stub: Hi. It would be rather horridly confusing if "1.2.20-1~launchpad.hardy1" was to be rebuilt in lucid, no? :-) [08:25] maxb: (mock indignation for stub) I Fail To See The Problem (but privately hahahaha oops) [08:26] wgrant: great mind's think alike! [08:27] (or fools never differ, depending on your pov) [08:29] maxb: What are we going to do about Python 2.6's changed output (tarfile trailing slashes, "[111] Connection refused" vs "(111, 'Connection refused')", that sort of thing)? Should we adjust tests to cope with both, or just fix them in the 2.6 branch and do another mass merge on migration day? [08:31] Given doctests don't allow for "this or that", I think fix-in-branch-and-mass-merge for those [08:32] Well, we can easily and somewhat safely ellipsise the latter case. [08:32] But I guess since we're going to have to mass-merge some stuff, we might as well fix it properly in the mass-merge. [08:32] The tarfile madness might be more amenable to making compatible, I'm not sure [08:32] use better assertions ;) [08:33] Also, are you going to finish off your assertion SyntaxWarning branch? [08:33] assertThat is your friend [08:33] initialise-from-parent.py is the only 2.6 Soyuz-related failure that isn't trivially fixable. [08:34] wgrant: I'm a bit blocked on what to do re initialise-from-parent.py. Creating an entire distroseries in the test is beyond my skill level at present [08:34] I was thinking of just seeing if the test works if I make it init from warty instead of hoary in the present sampledata [08:37] maxb: The error is with the pending builds, right? [08:37] If so, as a quick fix I would just make the builds no longer pending. [08:37] Until we can replace most of these abominable tests. [08:38] i.e. modify the sampledata hoary in the test setup? [08:38] Exactly. [08:39] We already do similar things in other places. [08:39] Just flip the builds to FAILEDTOBUILD or similar. [08:40] And the test harness will magically notice that I've dirtied the DB, and reinit it after my test? [08:40] Right. [08:41] If you commit, the DB will be torn down and recreated when your test finishes. If you don't commit, there's no problem with not tearing it down. [08:42] And in this case I shall need to commit, since it needs to exec a separate initialise-from-parent.py [08:42] True. [08:42] It probably already explicitly commits. [08:42] Since otherwise the DB wouldn't be marked dirty, even though i-f-p.py alters it. [08:43] oh, actually yes, it already commits to actually create the to-be-inited series [08:44] wgrant: re. the move of traverse_distro_archive, perhaps the bug would be a good spot for the conversation? (that way Julian can see the history etc.)? [08:44] noodles775: Probably true. [08:44] maxb: So, two lines of code should fix it... [08:45] adeuring: I'm confused. Why should the bug page have to deal with missing LFCs? garbo-daily shouldn't be removing files that are in use, right? [08:46] wgrant: in theory, you are right. But we had the case that LFC records were missing, see the bug mentioned in the commit message. [08:46] adeuring: Right, i reported that bug. [08:46] But it was more of a "why is garbo-daily removing these at all?" bug. [08:47] wgrant: Ah, I see. Admittedly, I don't have a definitive answer. My guess is that a LOSA deleted the LFCs because the files contained private data [08:48] Regarding the code: Only those bug attachments are deleted that are useless anyway because thes don't have an LFC record. So, no harm done, I think [08:48] s/thes/they/ [08:49] If the LFCs are deleted for a good reason, that's fine. [08:54] maxb: There's no modern 2.6 branch beyond salgado's? [08:54] Not at present, no [08:54] * wgrant wonders if we want a fresh ~launchpad-committers one soon. [09:03] given salgado is going leave according to the wiki page - yes! [09:06] * maxb runs tests on a tweaked initialise-from-parent.txt [09:07] * wgrant is collecting some fixes that are safe for devel. [09:15] mwhudson: also lazr.config.interfaces.ConfigErrors: ConfigErrors: schema-lazr.conf does not have a mpcreationjobs section. <== edited away both this and the prior and it started [09:16] https://code.staging.launchpad.net/~mwhudson/linux/trunk <- slowly slowing down, but mostly i think it's the bits before and after (eg packing) that are getting slower [09:16] spm: woo [09:16] https://pastebin.canonical.com/30343/ for the now obvious details [09:17] mwhudson: Yeah, but I don't think it's going to slow down to even the initial production time. [09:17] spm: um, i guess someone (tm) should land a lp-production-configs branch [09:17] Danilos: are you there? [09:17] wgrant: yeah [09:17] mwhudson: https://code.edge.launchpad.net/~thumper/lp-production-configs/merge-proposal-jobs/+merge/22995 perhaps? I tried, but apper to be having key fail atm [09:17] It'll overtake production in 7 hours. [09:17] Morning all [09:17] hey mrevell! [09:17] Howdy spm :) [09:18] spm: well that doesn't appear to delete the old sections [09:22] wgrant: also i think pear is ~twice as fast as strawberry [09:22] mwhudson: oh thumpers branch? oh right. yes. bleh. [09:22] mwhudson: Handy. [09:22] Interesting. [09:22] Latest import was only 48 minutes. [09:29] So how do I get the hardy packages at https://edge.launchpad.net/~stub/+archive/launchpad2 rebuilt for Lucid? [09:44] stub: currently, assuming they require rebuilding, you'll need to change the target in the changes file and re-upload. [09:44] So I can't do that with the Launchpad UI? Ok. [09:46] I seem to be able to do the copy without a rebuild, so maybe that will work. [09:46] I'm certainly being offered way too many choices that appear to be impossible due to deb packaging limitations. [09:50] good morning [09:50] stub: you can indeed copy to another series including the binaries, but it's only safe *if* you are certain they do not need to be rebuilt. See https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#Versioning [09:50] and yes, it is confusing. [10:44] stub: Why are you rebuilding slony1 in lucid at all? [10:49] maxb: So I can test the staging rebuild procedure locally [10:50] So, you want a pg8.3 version? [10:50] Yes [10:50] I can't recall right now why I couldn't use the 8.4 version... [10:51] Well, 1.2.20 is already in lucid for 8.4, so you shouldn't need the plain slony1 source from my PPA at all (as you can see it's greyed out "Newer version available" in your PPA) [10:53] What you probably want to do is take the slony1pg83 source, and increment its version to 1.2.20-1launchpad~stub1, and build that in lucid [10:59] Morning, all. [11:04] maxb: I should learn how to do that one day :-) [11:06] stub: It'll take me 30 seconds, shall I just do it? [11:06] maxb: That would be nice, ta :-) [11:06] oh waitaminute, didn't I already put a pg83 slony1 for lucid into ~launchpad/ppa ? [11:07] yes, yes I did :-) === stub1 is now known as stub [12:07] maxb: Ahh... yes. I'm going around in circles. Unfortunately, those packages are broken. postgresql-8.3-slony1 contains nothing but the documentation, and is missing the important stuff in /usr/lib. [12:07] ! [12:07] oops [12:07] https://bugs.edge.launchpad.net/launchpad-foundations/+bug/559046 (which I opened before getting distracted) [12:07] Bug #559046: Slony-I 1.2.20 for pg8.3 package missing critical files [12:08] I was going to try the rebuild in my ppa to see if it was a simple fix :) [12:15] stub: Oops, I suck. Fix uploaded. [12:16] * maxb glares at the build queues with loathing [12:19] maxb: Most of that is just an archive rebuild. [12:19] The amd64 queue is still 2 hours for fresh single uploads :-( [12:19] But it looks like i386/amd64 could actually be 40ish minutes behind. [12:19] Oh :/ [12:19] Fortunately you have quite a few buildd admins around. [12:22] stub wants the packages more than I, and he's a rubber ducky :-) [12:24] Very true. [12:38] from lp.soyuz.interfaces.build import BuildStatus [12:38] ImportError: cannot import name BuildStatus [12:38] ^ That's in a doctest I'm trying to modify. Anyone have any idea why that breaks? [12:38] especially given I copied the import line from the code I'm testing! [12:39] maxb: I think BuildStatus was moved recently [12:39] it might also just be a glitch because of circular imports.. [12:40] ugh, I must have copied it from one branch and then merged devel.... [12:40] maxb: I moved it to lp.buildmaster.interfaces.buildbase a month or so ago. [12:52] "make schema" seems to fail on API doc generation for me... looks like a fairly shallow makefile bug: [12:52] mv lib/canonical/launchpad/apidoc.tmp/* lib/canonical/launchpad/apidoc [12:53] mv: target `lib/canonical/launchpad/apidoc' is not a directory [12:53] make: *** [lib/canonical/launchpad/apidoc/index.html] Error 1 [12:53] is this a known issue? [12:54] You've resolved the conflict that occurred when you pulled? [12:54] I've not seen that in any of my branches. [12:54] I resolved the conflict by deleting lib/canonical/launchpad/apidoc [12:55] maybe I did it the wrong way [12:55] * jml tries against stable [12:55] I think that's the right solution. [12:57] yeah, it happens with stable [12:58] "make clean; make schema" to reproduce the error [12:58] Oh, does schema not depend on build? [12:58] Hm, it does. [13:02] I'll fix it now. https://bugs.edge.launchpad.net/launchpad-foundations/+bug/559159 for reference [13:02] Bug #559159: "make clean; make schema" fails with API doc error [13:03] oh hmm [13:03] lib/canonical/launchpad/apidoc _is_ supposed to be versioned and present [13:04] and empty :\ [13:04] Oh, right, that's why it conflicted. [13:04] I misremembered :( [13:05] it's kind of weird that it's not just created on build [13:05] It used to have content. [13:05] but only weird, not actually bad [13:07] crap [13:07] that's messed up a lot of my branches [13:09] ok. now that I've got a working build, I'm going offline to code & eat lunch === matsubara-afk is now known as matsubara [13:36] abentley: hope you may be able to help with this... fun & games trying to run a codehosting cron job on dogfood: https://pastebin.canonical.com/30356/ [13:36] abentley: might that indicate that I'm running it on the wrong server, or on a branch that's on the wrong server? [13:38] dogfood doesn't have codehosting... [13:42] jtv: ^^ [13:42] dogfood uses production codehosting. [13:43] Ah, so I guess I'd need to run the script there, against the dogfood config. :/ [13:44] Which script? [13:45] rosetta-branches [13:46] Ah. [13:46] That sounds disastrous. [13:47] You'll probably need to stuff with DB perms to let yo urun it from crowberr and blah blah. [13:48] That too, probably—but at least that part is familiar. [13:48] dogfood isn't. [13:48] dogfood isn't really familiar to anyone. [13:49] I'm not quite sure of the point of dogfood now that most stuff is reasonably testable locally. It seems like staging could be given a build farm for the rarer production-like test cases. staging has codehosting. [13:52] And the work we're doing right now involves buildfarm, codehosting, and translations—so maybe per-team islands are not an effective way to test this any more. [13:52] I would think not. [13:52] dogfood seems to mostly be used for QA now, which could be done on staging. [13:53] If staging had a build farm. [13:53] AIUI it was often used for development or pre-merge testing previously. [13:53] Right. [13:53] There's also the easy, fast-turnaround patching, database access etc. I wouldn't discount that—but then we all need that AFAICS. [13:53] True. [14:01] hi pals ... could u help me ... =) [14:01] i have redirection to https://launchpad.dev from http://bazaar.launchpad.dev/~bla/vla/devel/files [14:03] so, just redirection from http://bazaar.launchpad.dev to https://launchpad.dev [14:03] i can't 'View the branch content' [14:05] SlonUA: Please report what the command `getent hosts bazaar.launchpad.dev` prints for you [14:05] The problem is probably that branch-rewrite.py isn't running. [14:05] maxb: 1sec [14:06] 192.168.241.11 bazaar.launchpad.dev ... i use remote access [14:06] Remote access in incompatible with bazaar.launchpad.dev [14:06] *is [14:07] "A full Launchpad development setup requires two IP addresses on the local machine, on which to run two HTTPS listeners - one for main Launchpad, and one for Loggerhead (code browsing) of private branches. As most developer workstations have only one non-local IP address, and as the second one is only required for Loggerhead on private branches, you may well not bother to set up an additional IP address. If you do want to do this, identif [14:07] y a suitable IP address, and add it to your machine's network configuration now. " [14:07] quoted from Running/RemoteAccess [14:08] jtv, sorry, just starting work now. Looks like wgrant helped you? [14:08] wgrant, +10 on staging buildfarm [14:08] abentley: helped me realize what depths of shit I'm in, but yes. :-) [14:09] abentley: It shouldn't actually be hard to get just a build farm up and running. A full archive is harder, though. [14:09] SlonUA: Oh, sorry, except that's only required for *private* branches. [14:09] maxb: i see .. thanks .. so .. [14:10] SlonUA: Anyway, you should read Running/RemoteAccess again carefully, because I think you've not quite performed the tweaking described there correctly [14:10] In particular, the "Amending the Apache configuration" part [14:10] maxb: ohh .. thanks .. i will read again [14:11] wgrant, Do you mean that it's hard to get a full copy of an archive on disk, or do you mean that building to archive is harder? [14:12] abentley: Lots of config. [14:12] The former, though. [14:13] Hmm, I guess we really need on-disk archives for SPRBs, since they need build-deps. [14:13] But for jtv's purposes it doesn't matter. [14:14] jtv just needs codehosting and a buildd-manager. [14:14] Well... and a build slave, and the Translations db. Not asking for much. :) [14:41] error while make run: http://paste.ubuntu.com/411614/ [14:54] noodles775: New buildfarm project? Yes please... [14:55] They are sort of split between Soyuz, Code and slightly Translations now... [14:56] Yep. [14:57] * wgrant wonders who needs to be convinced. === salgado is now known as salgado-off [15:01] wgrant: we can point Julian to the bug next week, I think he'll be keen too. === matsubara is now known as matsubara-lunch === matsubara-lunch is now known as matsubara [17:23] maxb: hi again [17:23] hello [17:24] maxb: i have to ip on my vm ... but https://bazaar.launchpad.dev/ work perfect ... but http://bazaar.launchpad.dev/ still redirect to https:/launchpad.dev [17:25] i mean 2 ips [17:25] pastebin your apache configuration [17:28] maxb: http://pastebin.com/Qe3VpmHp === deryck is now known as deryck[lunch] [17:37] SlonUA: huh. looks ok to me. Sorry, I'm not sure what to check next [17:38] maxb: thank for look in .. i think i will hack launchpad-lazr.conf [17:38] maxb: btw .... in section [codehosting] [17:38] it will be correct: port: tcp:5022:interface=bazaar.launchpad.dev [17:39] instead port: tcp:5022:interface=127.0.0.88 === beuno is now known as beuno-lunch [18:06] g'night all === bjf is now known as bjf-afk === beuno-lunch is now known as beuno === gary_poster is now known as gary_lunch === deryck[lunch] is now known as deryck === gary_lunch is now known as gary_poster [19:58] flacoste, ping [19:59] hi sinzui [19:59] flacoste, I discovered the cause of the adaption insanity. We use provideAdapter() in the browser.pillar module, import that module cause the registrations to be wrong [20:00] flacoste, I fixed the issue by switching to ZCML [20:01] sinzui: provideAdapter in the browser.pillar modules sounds like a bad idea [20:01] we have a few navigation menus registered that way. It is all fine until you intend to subclass [20:02] sinzui: you mean registered using an annotation? or a call to provideAdapter direclty? [20:03] directly [20:03] directly in the module is never a good idea [20:03] so I have learned [20:03] well, unless gary disagrees [20:03] reading back [20:04] provideAdapter(InvolvedMenu, [IInvolved], INavigationMenu, name="overview") was the code [20:04] * sinzui wrote it [20:05] in any case, I have accidentally fixed an issue for EdwinGrubbs. [20:05]