[12:04] lifeless: ok, bzr transition will start when you are settled in montreal [12:04] sabdfl:sure. [12:05] sabdfl: I'd like to have all the subprojects *except* launchpad transitioned in fact, before I fly. [12:05] kiko: i want to go live on soyuz on monday, but only if we can test it properly [12:05] lifeless, btw, I'm happy to take the pie if we end UBZ on bzr and I manage a successful merge. [12:05] we've been through that rocky part already. [12:05] sabdfl, okay. my parts will be in place tomorrow [12:05] lifeless: are you absolutely sure about the other parts [12:05] ? [12:05] is the theory that those change less often? [12:05] but launchpad is what people hack on, so transitioning that is what will give most tubulence [12:05] yes [12:05] is it possible to fall back once you start transitionint? [12:06] lifeless, at the moment PQM is failing to process 100% of my merge requests with failures in some of the other trees [12:06] non-launchpad [12:06] sabdfl: yes, just remove the merged stuff from the tip of the branches and switch the pqm config back [12:06] lifeless, can you check if there's something wrong there? [12:07] kiko: looking at it [12:07] thanks dude [12:07] I see one merge at 1am and one emrge at 141am my time [12:07] I can resubmit a merge if you like [12:07] they both worked, one to prod, one to devel [12:07] mine both failed [12:07] please submit one now [12:07] will do. [12:08] when it fails, forward me the log. [12:08] I'll go get breakfast [12:08] done. [12:08] and hang around to debug. [12:08] I need to go home, lifeless :-( [12:08] kiko: *I* will hang around to debug. [12:08] it is saturday :) [12:09] lifeless, I need to work on gina, and I'm starved [12:09] kiko: so go get some food. [12:09] kiko: we're in hurry up and wait mode now anyway [12:09] what's happening? [12:09] kiko has had two merges fail [12:10] oh not much [12:10] lifeless, okay, I'll wait === carlos -> dinner [12:10] stubs and bjorns went through though [12:10] i've had two or three fail [12:10] bye (sleep) [12:10] SteveA_, what's the symptom? [12:10] something about contention on launchpad_ftest database === nanouck_ [n=nanouck@32.215.100-84.rev.gaoland.net] has left #launchpad ["Leaving"] [12:11] I got that too earlier [12:11] now I got something else [12:11] i need to land this before the next production update [12:11] kiko: the request is processing [12:11] cos it has been cherrypicked [12:11] cool [12:11] kiko: so go, get food. [12:11] kiko: come back in ~20 to forward me the detailed error [12:12] sabdfl, note that testing soyuz also involves pushing all package uploads through the uploader [12:12] if you dont eat, you wont' be effective anyway. [12:12] sabdfl, through the build system [12:12] sabdfl, and then republishing [12:12] by all package uploads I'd mean all breezy package uploads [12:12] SteveA_: I have all of the rocketfuel archives active branches converted - zope, sqlos, sqlobject etc etc etc [12:13] sabdfl, if we don't do that it's likely we will see problems in production [12:13] SteveA_: we can convert any of these to getting commits from bzr at any point. [12:13] SteveA_: but I think we should let your and kikos pending merges get through the queue first. [12:13] lifeless, can you kill my merge? [12:13] I hosed it [12:14] I knew I should have gone home :-) [12:14] lifeless, I just submitted the right one [12:14] sure thing [12:14] jordi, do you need anything else? [12:15] kiko: no [12:15] I need to leave actually [12:15] wonderful [12:15] or I'll be late [12:15] kiko: better ? [12:15] and that means PROBLEMS with the gf [12:15] yes [12:15] much [12:15] jordi, even if you're not late, gfs are trouble :) [12:15] but such wonderful trouble [12:16] kiko: YOU SAID IT [12:17] lifeless: so, want me to submit to pqm again? [12:23] SteveA_: please === lbm [n=lbm@x1-6-00-13-10-7a-d1-e4.k233.webspeed.dk] has joined #launchpad [12:33] where's my failure goddammit [12:33] lifeless: sent [12:35] lifeless, sent failure [12:35] see ya [12:47] kiko-zzz: File "/home/pqm/arch/queue/workdir/rocketfuel@canonical.com/---launchpad--devel--0/launchpad/lib/canonical/ftests/pgsql.py", line 114, in installFakeConnect [12:47] assert _org_connect is None [12:47] AssertionError [12:47] kiko-zzz: nothing to do with pqm AFAICT [12:48] SteveA_: is that what you were seeing ? [12:51] lifeless: yes [12:51] I have not touched postgresql config nor launchpad config for postgresql use [12:52] the last commit, from bjornt, does, but should be ricght [12:52] odd [12:52] both you and kiko are failing in the same way at the same time [12:53] after no config changes relative to the last working commits [12:53] so : [12:53] we should check with stub, and the admins, about changes re chinstrap [12:53] but it aint bzr, nor pqm. sorry. [12:53] ok [12:54] (sorry, cause if it was, I could fix it) [12:55] ring me if there is something you need doing [12:56] i'm going to sleep now, but i'll try tomorrow [12:57] ok [12:57] I'll email the list [01:04] ok [01:10] SteveA_: something has left the db open === mdz [n=mdz@ca-studio-bsr1o-251.vnnyca.adelphia.net] has joined #launchpad === stub [i=stub@sweep.bur.st] has joined #launchpad [02:22] lifeless: so, run me through this half-baz, half-bzr idea [02:23] should i be able to do: [02:23] cd lib [02:23] rm -rf zope3 [02:23] bzr get sftp://wadawada/path/to/zope3/dev zope3 [02:23] and it will just work? [02:24] bzr branch sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/zope/3.0/test zope3 [02:24] yes [02:24] or rsync [02:24] stub: so, postgresql had a stale backend open on launchpad_ftesting :[ [02:24] Bah. I can't see any daily builds since the broken 20th ones. Which is blocking me. Anyone got some older ones lying around that have baz push? [02:25] stub: use http://people.ubuntu.com/~robertc/baz2.0/bzrtools-baz2bzr [02:25] stub: it has the fix [02:26] uninstall the bzrtools package, mkdir -p ~/.bazaar/plugins; bzr branch http://people.ubuntu.com/~robertc/baz2.0/bzrtools-baz2bzr ~/.bazaar/plugins/bzrtools [02:27] wtf is paramiko? [02:28] lifeless: This is for use with breezy bzr? [02:29] stub: ah. I see whats up [02:29] sabdfl: paramiko is a sync sftp implementation, its a temporary sftp protocol for us [02:29] ok, cool [02:29] to be replaced with twisted? [02:29] stub: you'll need to use jbaileys bzr [02:29] sabdfl: yes, its looking very much like that. [02:30] ok. some reservations from the crowd, i saw [02:30] martin dived in and played heavily yesterday [02:30] and rung me up very positive about it [02:31] ok. that was the crowd i was thinking of ;-) [02:31] :) [02:31] Async would be cool [02:31] * Contacting sftp://chinstrap/..... [02:31] * Still waiting.... [02:31] * Goddamn your network is slow.... [02:31] * Ooh! An ack! [02:31] * .... [02:31] yes [02:31] sounds like my connection right now [02:31] making the core async is a big step though. [02:32] so, while its been frustrating having a looooooong conversation about it [02:32] I think its important that all the key devs have time to experiment, and buy in [02:33] my format-4 experimental branch was 7 times faster with twisted on http, and I expect similar returns with format 5 [02:34] wow. 7 times faster for an initial pull, for example? [02:34] question - if we write code to improve pipelining etc as we use twisted, can we contribute that back to twisted ? They use MIT licencing. [02:34] yes, 7 times faster [02:35] my pulls here of bzr.dev took ~12 minutes, down from ~90 [02:36] what's the merging like in bzr right now? [02:36] especially mesh merging? [02:36] much better than baz, it does not shortcut history [02:36] not as good as codeville yet, we do not have weave merge in place today. [02:37] can we expect fewer surprises in the conflict department? [02:37] yes [02:37] wonderful === Severian_ [n=ralph@adsl-68-95-254-147.dsl.rcsntx.swbell.net] has joined #launchpad [02:39] Howdy, I keep gettting "str: Signature has invalid format" when I try to sign the Code of Conduct. I searched Malone, but did not find anything. Any ideas? My signed document looks good. [02:40] sabdfl: question - if we write code to improve pipelining etc as we use twisted, can we contribute that back to twisted ? They use MIT licencing. [02:40] lifeless: i would rather we focused on features than peformance [02:41] sabdfl: We are - but there is a balance. Below a certain threshold of performance, we lose folk. [02:41] As much as time delays Rosetta in accepting a po file? I'm waiting all day! [02:42] sabdfl: for instance, we have some big-O scaling issues for big trees (launchpad isn't a big tree), that we need to address, and thats arguably performance [02:42] Severian_: I don't think there is anyone around at the moment who can help with that (I think you want cprov of jamesh). I would suggest filing a bug with your signed document attached. I know there are issues with sign-only GPG keys, but apart from that I can't help. [02:42] lifeless: yes, but it's not in twisted, is it [02:43] sabdfl: that one isn't. [02:43] Thanks, stub. I'll do that. I thought I should ask here before submitting a bug. [02:43] we'll be writing whatever we need in bzr. [02:43] its just after writing it, some things would be good to feed back [02:44] lifeless: i don't think i've often declined that, but you know i prefer defined requests after the fact [02:44] true [02:44] rather than vague open-ended invitations to be nice [02:44] do [02:44] so I will do that when if we have specifics [02:44] I dont recall you declining ever, as it happens. [02:44] rather focus on bzr itself, leverage 3rd party bits as they stand [02:45] i've been bitten before by "just a little bit more work on buildbot" [02:45] will I ever be free of that ? [02:45] :) [02:46] yes === elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has left #launchpad ["."] [02:46] of course :-) === lifeless awaits the day :) [02:46] so. [02:46] have you pulled out zope yet ? === camilotelles [n=Camilo@20132194128.user.veloxzone.com.br] has joined #launchpad [02:46] :) [02:47] slinky% du -csh /tmp/zope3 [02:47] 33M . [02:47] 33M total [02:47] heh, still pulling :0 [02:47] slinky% du -csh ubuntu/launchpad/sourcecode/zope [02:47] 56M . [02:47] 56M total [02:48] I'm writing some of the bzr things I'm doing as plugins, so they can be easily used while their final location is not decided (they can be used with different banches etc) [02:49] I presume the same licence as bzr is appropriate? (This is a no-brainer, but checking) [02:49] Is there a bzr cache if I need the same remote resource twice, or should I try an minimize remote gets by keeping a local branch of interesting rocketfuel stuff? [02:49] specifics - email after commit, mirror after commit, switch. [02:49] stub: there is no cache. but you can say 'bzr branch --basis LOCALBRANCH REMOTEBRANCH [02:50] stub: which will use localbranch for history, then remotebranch for anything missing. Except its not currently doing that for weaves. [02:50] stub: so I suggest you use 'bzr branch local-branch new-local-branch; cd new-local-branch; bzr pull --clobber remote-branch' [02:50] ok. [02:52] lifeless: sure, though, if you find it takes much longer to pluginize... [02:52] yes, well aware of the tradeoffs [02:52] cool [02:52] thanks [02:52] np, and thanks [02:52] damn, i'm excited about bzr! [02:53] it is looking very nice [02:53] me too, be nice to get it released, and then really ramp up the supermirror stuff === ajmitch enjoys using it, which is a change from some other tools :) [02:54] very high quality design and engineering. it feels really... smooth [02:55] interesting. lifeless, the zope3 tree in arch was 56mb. the bzr one is up to 56 before it even builds the working dir [02:57] sabdfl: this is expected - remember you have a full copy of the tree in your .bzr subdir [02:58] ok. so it will be bigger, but faster, cleaner [02:58] sabdfl: so in arch you have 56mb from source + commit metadata, in bzr you have 56mb from source + commit metadata + history-of-files [02:58] the lp tree gets smaller because we nuke a bad-O algorithm in the logs [02:58] right. and i suppose that as the number of branches and commits goes up, arch became pathological while bzr scales more cleanly [02:58] right [02:58] bad-O is bad :) [02:59] bzr: ERROR: 'tuple' object has no attribute 'last_revision' [02:59] command: '/usr/bin/bzr' 'viz' [02:59] pwd: /tmp/zope3 [02:59] at /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrk/__init__.py line 41, in run() [03:00] bzrk needs an update :0 [03:01] 'k. sure it will come tomorrow :-) [03:01] night all [03:01] gnight === sabdfl [n=mark@pdpc/supporter/silver/sabdfl] has left #launchpad [] [03:07] Urgh. push uses rsync location syntax, bzr uses URL. [03:07] yes [03:07] that will be fixed soon [03:08] back in 10 [03:09] suck that pqm [03:10] So I've converted my archive (well - the first half of it) as per the RocketfuelSetup page, made a branch of my converted dists--devel, pulled updates from the bzr rocketfuel/dists/devel, updated the staging config, committed, pushed and now should have a pqm request in the system [03:12] I gots me a 'success' email but no detail [03:16] mailman ate it [03:17] una momento [03:19] ok, should have hit the list now [03:19] dilys needs an update to recognise it === Severian_ [n=ralph@adsl-68-95-254-147.dsl.rcsntx.swbell.net] has left #launchpad ["Leaving"] === micro_girl [n=ss@82.155.202.188] has joined #launchpad [03:37] hi everyone [03:37] listen, I joined yesterday and I have some questions, can anyone please help me with them? [03:38] first, I wanted to know... how do I know if a translation got accepted or not? [03:41] 08:41:10~/production $ cm.py build configs/canonical.com/launchpad/production [03:41] Traceback (most recent call last): [03:41] File "/usr/bin/cm.py", line 24, in ? [03:41] main(sys.argv) [03:41] File "/usr/lib/python2.4/site-packages/config_manager/__init__.py", line 211, in main [03:41] config.build(os.path.abspath(os.curdir)) [03:41] File "/usr/lib/python2.4/site-packages/config_manager/__init__.py", line 57, in build [03:41] entry.build(dir) [03:41] File "/usr/lib/python2.4/site-packages/config_manager/__init__.py", line 102, in build [03:42] import pybaz [03:42] ImportError: No module named pybaz [03:42] lifeless: Is there a pybaz .deb needing installing that isn't mentioned? [03:42] lifeless: your test bzr branch went through pending-reviews fine. It would be good to test a branch that differs from mainline and one with conflicts though. [03:42] o_O [03:43] can anyone help me, please? [03:43] micro_girl: jordi is best for rosetta queries [03:43] what's that? [03:44] jordi is a who rather than a what [03:44] A person on this channel. On spanish time so he might not be around yet. Most of the Rosetta people are on Spanish time [03:44] o_O is he from Spain? [03:44] 'cause I am from Portugal, so the time is not very different... [03:45] jordi is in Spain [03:46] lifeless: Ahh... i see. [03:46] nobody else knows what to answer me? [03:49] micro_girl: I don't know the answer off hand, no. [03:49] jamesh: sweet [03:50] ok... [03:50] I was really wondering about it, I don't have problems in translating lots of stuff, but I wanted to be sure they would use it! [03:51] lifeless: it took a few goes -- first off the branch was being recognised as a baz branch (the regexp was essentially taking anything with an "@" in it) [03:51] lifeless: after tightening that up and fixing a few other small issues it went through [03:52] ok [03:52] I'll do a trivial change now [03:52] and we can see what it looks like [03:52] but some of the code is short circuited if it detects that the branch has been merged, so it would be good to see what happens [03:53] ok, I have done that and pushed. [03:53] jamesh: have you changed the 'is merged' test as I described ? [03:53] micro_girl: If you don't want to hang around for Jordi or Carlos there is a rosetta-users mailing list you can send your query to [03:53] no. I probably missed your description [03:54] lifeless: what should the test do? [03:54] hum, so, where should I mail it to? [03:54] micro_girl: information on signing up to the mailing list is here: http://lists.ubuntu.com/mailman/listinfo/rosetta-users [03:55] to see if REMOTE is merged into THIS, 'if remote.last_revision in this.get_ancestry(this.last_revision())' [03:56] lifeless: that's what it is doing right now, isn't it? [03:56] ok, thanks [03:56] jamesh: the code I wrote did 'if remote.last_revision in this' [03:56] it grabs the revid of the given revision number, and checks to see if that revision is in the branch in the given directory [03:57] 'in branch' and 'in ancestry' are different [03:57] the former is 'can the snapshot be constructed', the latter is 'is it merged' [03:57] wah... more unsigned .debs to install over insecure protocols :-( [03:58] hum.... I get an error [03:58] Technical details of permanent failure: [03:58] PERM_FAILURE: SMTP Error (state 9): 501 : domain missing or malformed [03:58] lifeless: the new one does get_rev_id() on the branch to be merged, then get_revision() with that ID on the mainline [03:58] micro_girl: no trailing dot. [03:58] jamesh: thats wrong [03:58] jamesh: rather than get_revision with that id on the mainline, it should do 'in mainline.get_ancestry(mainline.last_revision)' [03:59] okay [03:59] erm, in mainline.get_ancestry(mainline.last_revision()) [03:59] lifeless, what do you mean by that? [04:00] micro_girl: you have a '.' at the end of lists.ubuntu.com. While its technically valid, it looks like your mail setup rejects it, so just use 'rosetaa-users@lists.ubuntu.com' instead. [04:00] erm, spelling rosetta correctly of course [04:00] jamesh: I've pushed a branch with a pending change, care to kick a run off ? [04:01] hym, ok... [04:03] lifeless: will in a sec. [04:09] So breezy bzr is good enough for the production systems, and will happily sftp branches from chinstrap and work with cm.py etc.? === stub is about to send a request to rt detailing what is needed [04:10] lifeless: Unless you want me to defer that until things are more solid [04:10] stub: we should run bzr from source [04:11] lifeless: okay. it seems to be doing the right thing, but the output is missing some bits [04:11] for end users, they can use jbaileys packages [04:11] lifeless: I'll update the script and do a full run [04:11] but for our systems, we just unpack it and put a symlink to .../bzr on our path [04:11] stub: there are lots of changes still coming, we will have grief if we do otherwise [04:12] ok. [04:12] So just config-manager and python-bazaar are the new things needed [04:12] pycrypto is the only dependency (at the moment) that debs are needed for [04:12] and pycrypto [04:12] pybaz we should get installed via debs I think [04:12] its quite stable and not churning much [04:13] config-manager can run from source, or from debs. [04:13] 0.1p123 in sid works with current bzr [04:14] Running stuff from source rather than snapshots means we will end up with inconsistencies between what we are running on staging and what is used for rollouts and updates. [04:15] So I think anything that won't need updating weekly can come from a deb [04:15] ok [04:15] though I worry it will give us gried [04:15] *grief* [04:15] cm.py from sid rather than the wget url on the wiki? [04:16] I'd really rather we have a tarball of what we need in source, for production/staging/dogfood and we use that [04:16] we can update that from rsync [04:16] i.e. the /home/warthogs/source subdir [04:16] That sounds fine. [04:16] We should push it from emperor though [04:16] yes, cm.py from sid is usable now [04:16] emperor ? [04:17] It is at the highest point in our attack tree (apart from our laptops) [04:17] And any proxy servers and dns server since we are installing unsigned debs :-( [04:19] uhm [04:20] ok [04:20] but I warn you, I'll be getting it onto emperor from chinstrap and people.u.c [04:21] the source it is pulling should all be signed [04:21] what are you trying to guard against? what vector [04:22] If I'm pulling a tarball from, say, chinstrap and installing it onto emperor then anyone who can modify that tarball has access to the postgres user on emperor (which is everything important) [04:24] right [04:24] so we lock down who can modify that directory [04:25] chinstrap is an insecure box, so locking down isn't that meaningful [04:25] all of our source is stored and considered canonical on chinstrap [04:25] lock down better bloody be meaningful [04:25] or we are all already up the poo [04:25] stored GPG signed so can't be futzed with I hope [04:26] its signed by a key ON CHINSTRAP [04:27] ok. which makes our whole network a flat security space as insecure as our general access box with lots of accounts with literally hundreds of attack vectors :-( [04:27] a key that if lockdown works, you, me, elmo and znarl are the only people with access to [04:27] yes it does [04:27] I'm not defending that [04:27] I'm just arguing against false-security sense [04:28] Yup. That makes my life easier anyway. Less pointless bending over backwards. [04:28] putting this on emperor would not increase security, only increase difficulty. [04:28] right [04:34] Is PQM already sheduled to move to a different box? [04:37] I recall someone mentioning a dedicated box for running tests which might go towards solving this too. [04:37] no, its not [04:38] lifeless: you've got conflicts! https://chinstrap.ubuntu.com/~jamesh/pending-reviews/ [04:39] (which probably means everything should work correctly now) [04:42] cool [04:42] https://launchpad.net/products/launchpad/+spec/securing-rocketfuel/ [04:43] compomized [04:44] thats a technical term [04:47] AIUI the plan was to move users off chinstrao [04:47] not to move pqm [04:50] ok. We can discuss it at ubz anyway. The Zombie Hordes scenario isn't possible yet. === robitaille [n=robitail@d154-5-117-228.bchsia.telus.net] has joined #launchpad === |Lord_Zoo| [i=ircap8b@OL192-128.fibertel.com.ar] has joined #launchpad === stub [i=stub@sweep.bur.st] has joined #launchpad === hawkaloogie [n=doug@static-72-1-4-143.ntd.net] has joined #launchpad === sankar [n=sankar@202.144.95.244] has joined #launchpad === hawkaloogie [n=doug@static-72-1-4-143.ntd.net] has left #launchpad ["Leaving"] === stub [i=stub@sweep.bur.st] has joined #launchpad === GoRoDeK [n=gorodek@p5083E09B.dip.t-dialin.net] has joined #launchpad === robitaille [n=robitail@d154-5-117-228.bchsia.telus.net] has joined #launchpad === Keybuk [n=scott@syndicate.netsplit.com] has joined #launchpad === zyga [n=zyga@2-mi2-1.acn.waw.pl] has joined #launchpad [09:43] morning === GoRoDeK [n=gorodek@p5083E09B.dip.t-dialin.net] has joined #launchpad === Burgundavia [n=corey@S0106000000cc07fc.gv.shawcable.net] has joined #launchpad [11:01] MOrning all === pkunk [n=pkunk@a84-231-2-45.elisa-laajakaista.fi] has joined #launchpad === mfuentes [n=mario@200.54.6.10] has joined #launchpad === sabdfl [n=mark@host217-37-231-22.in-addr.btopenworld.com] has joined #launchpad === stub [i=stub@sweep.bur.st] has joined #launchpad === sivang [n=sivang@box79162.elkhouse.de] has joined #launchpad [11:39] hey stub. so how's thailand treating you? [11:40] Keybuk: bzr viz is not liking me right now [11:40] hey sabdfl , how's saturday? [11:40] Good enough so far. Been relaxing and enjoying Thai food in the main ;) [11:40] Keybuk: bzr: ERROR: 'tuple' object has no attribute 'last_revision' [11:40] lucky man [11:40] update both [11:40] sivang: off to a good start, but rather a lot of work to be done on the spec tracker :-) [11:40] there should be a new snapshot of both bzr and bzrk [11:40] Keybuk: i did, about an hour ago [11:41] from jbailey's daileys [11:41] you using jeff's daily snapshots? [11:41] sabdfl: :) [11:42] sabdfl: dpkg-query -W bzr bzrk [11:43] hmm, actually, doesn't look like Jeff's packages are really up to date [11:43] when ping him when he's up [11:44] This push? Lifeless had a new bundle of bzrtools that fixed that error in push for me [11:45] in his people.ubuntu.com site somewhere... [11:45] stub: actually, bzrtools is fixed on jbaileys site [11:45] stub: but this is bzrk instead [11:46] so stub, rollout stuff is now running with bzr ? [11:46] sabdfl: use http://people.ubuntu.com/~scott/packages/bzrk_0.1+20051022-1_all.deb for now [11:46] Havn't got beyond my laptop yet [11:48] I'll probably need help on getting bzr et. al. built from source. In particular where all the source trees for bzr, bzrtools, that other thing starting with p... [11:53] Keybuk: ah, rocks [11:54] stub: ok, just ping/sms me === Kinnison yawns [12:01] hey dudes [12:01] Kinnison: morning :) [12:02] Was I meant to be reviewing something for kiko? === Kinnison has an hour now [12:07] ciao dudes === Kinnison will check back in a bit [12:10] sabdfl: does it have anything in common with the katie tool? === WaterSevenUb [n=WaterSev@195-23-220-120.net.novis.pt] has joined #launchpad === sivang_ [i=sivan@muse.19inch.net] has joined #launchpad === sivang [i=sivan@muse.19inch.net] has joined #launchpad === sivang [i=sivan@muse.19inch.net] has joined #launchpad [12:28]