=== jinty [n=jinty@115.Red-80-24-9.staticIP.rima-tde.net] has joined #launchpad === jinty [n=jinty@115.Red-80-24-9.staticIP.rima-tde.net] has joined #launchpad === mdke_ is now known as mdke === Tonio_ [n=tonio@tonio.planetemu.net] has joined #launchpad === Tonio_ [n=tonio@tonio.planetemu.net] has left #launchpad [] === stub [i=stub@sweep.bur.st] has joined #launchpad [02:21] spiv: I'm pushing a fix for bug 4852 [02:21] Malone bug #4852: Cannot add a comment to a bug using only the keyboard (with epiphany) In: launchpad (upstream), Severity: Normal, Assigned to: James Henstridge, Status: Accepted https://launchpad.net/bugs/4852 [02:23] jamesh: Thanks! === salgado [n=salgado@201-27-7-12.dsl.telesp.net.br] has joined #launchpad === Nafallo is now known as Nafallo_away [03:29] lifeless: I'm creating the next production config. Is there an consensus yet on the 'double slash after the hostname means absolute path' issue? [03:29] stub: yes, that is bogus. its %2f that makes it absolute [03:29] // was never legit === stub vomits [03:30] right [03:30] this has swayed my case hugely :) [03:34] Is there a bzr command that does 'cat .bzr/parent' ? [03:41] nope [03:41] api branch.get_parent() [03:42] Bug 5775 [03:42] Malone bug #5775: viewing magic file only way to determine default pull location In: bzr (upstream), Severity: Normal, Assigned to: Nobody, Status: New https://launchpad.net/bugs/5775 [03:43] stub: not sure thats a bug [03:43] stub: whats the use case [03:43] Me wanting to know what 'bzr pull' is going to do [03:45] then I suggest the bug report would be better with that context :) [03:45] i.e. 'I cannot tell what bzr pull is going to do' [03:50] lifeless: I suppose the whole "//" vs. "/%2F" thing could be avoided for the Launchpad supermirror by making all users' home directories the root directory [03:50] so sftp://host/foo is the same as sftp://host/%2Ffoo [03:51] jamesh: yes. we could do that [04:11] pqm is going down after the current merge === ..[topic/#launchpad:lifeless] : PQM is being upgraded, patience please! | launchpad.net | developer meeting: Thur 15 Dec, 1200UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Channel logs are here: http://tinyurl.com/72w39 [04:18] Merge to devel/launchpad: [r=BjornT] add missing breadcrumbs for Souyz pages (r2914: Dafydd Harries) [04:26] launchpad will be going down in 10 mins, which will also put the wiki's into read only mode. Estimated down time is 45 mins. [04:38] jamesh: That's precisely what the launchpad supermirror does. [04:39] spiv: cool. [04:42] jamesh: Or rather, the current working dir upon login is the root of the virtual filesystem. [04:42] spiv: So both interpretations of "sftp://host/foo" are the same, which is good [04:42] "home directory" is a possibly confusing term for the supermirror sftp server :) [04:43] It doesn't do anything clever with ~, so e.g. "cd ~" will fail. [04:43] well, sftp doesn't have a "cd" command, right? [04:44] The openssh client does, not sure about the protocol level. [04:44] what the client does is different to what happens over the wire [04:44] Indeed. [04:45] I'm not as familiar with what happens over the wire, though :) [04:45] But you appear to be right, at glance. [04:45] I didn't see anything about changing directories in the spec :) [04:46] So, pretend I said "stat ~" rather than "cd ~" ;) [04:47] Anyway, "foo" and "/foo" are the same as far as the supermirror sftp is concerned :) [04:50] I think you refer to the starting directory as "", actually [04:50] IIRC wire level considers ~ to be abomination [04:50] but foo is ~/foo [04:50] and .. is ~/foo/.. [04:51] etc [04:56] lifeless: is the pqm upgrade for moving it to another box? [04:56] yes [05:04] lifeless: Would rewriting sftp://chinstrap.ubuntu.com/foo to sftp://stub@chinstrap.ubuntu.com/foo be the responsibility of config manager, or an external tool that produces a munged config that is then passed to config manager? [05:05] I think that that might be a useful feature for config manager [05:07] stub: Or echo -e "Host chinstrap.ubuntu.com\n User stub" > .ssh/config ;) [05:07] spiv: Doesn't work for bzr yet, because paramiko doesn't support it [05:08] stub: paramiko can use openssh [05:08] but there is a general issue [05:08] it can? .ssh/config meets my current use cases then if you are prioritizing features [05:11] configs need to be changed, to be able to list multiple locastions that *might* be aliased, along with some verification means [05:12] then we can list the local address in pqm as an alias to the official location, and the revid (either the tip we should get, or a prefix we once saw) [05:12] maybe overxmas === netjoined: irc.freenode.net -> brown.freenode.net === stub [i=stub@sweep.bur.st] has joined #launchpad [05:13] jamesh: do you know the revid that your patch was merged in in? [05:18] Production is live, with new layout [05:29] wow thats, different [05:29] lifeless: you mean the redirection() one? [05:30] jamesh: the openssh using patch [05:30] oh [05:30] id, not revno ;) [05:31] mbp@sourcefrog.net-20051130064100-50469cf3ee5f42b2 [05:32] lifeless: you probably want a newer version though. there was an error in fixing a merge conflict when mbp merged my branch [05:33] perhaps john@arbash-meinel.com-20051130145503-95fed0de893c86a1 (the revision after, which includes John's fixes) [05:35] stub: ^^^ to get bzr using sshd [05:35] erm ssh [05:36] This is for production rollouts - I'll wait until the patch filters through. [05:38] so I've been thinking [05:38] why not build the tree on chinstrap and rsync it outwards [05:39] better for security anyway [05:55] lifeless: I thought pulling signed revisions straight from the RCS would be better for security. Building the tree on chinstrap and rsyncing worked well though when I did it that way last week. This week cm.py update did the trick happily. [05:56] stub: well if we push from chinstrap we can disable ssh *from* galapagos to chinstrap [05:56] so the vector of compromise launchpad, then attack inwards is reduced [06:00] I see [06:01] the new layout looks really weird until you reload the CSS === BjornT [n=bjorn@84.32.140.183] has joined #launchpad [07:08] stub: ping [07:08] lifeless: pong [07:09] should we run the lp tests as amd 64 or i386 ? [07:09] we have chroots for both [07:10] I think amd64 would be good - production systems tend to be moving in that direction and we are more likely to get glitches on that architecture we need to be aware of than i386 [07:11] ok. When I get pqm grokking dchroot commands, I shall make that happen :) [08:02] bah stub [08:02] I'm still getting LP junk [08:04] what on? [08:09] epiphany-browser at least [08:09] evolution [08:09] pppoeconf [08:13] yay nessus [08:13] GPL->proprietary [08:13] fuckers === matid [n=matid@195.116.35.246] has joined #launchpad [08:20] Are the changes or launchpad that I've noticed today a bug or is it just a little redesign? [08:21] I think you may need to reload the css [08:21] it is meant to look different, but not weird [08:21] Maybe, 'cause my IS a bit weird... [08:24] matid: if it appears that everything is squeezed into a thin column on the left, do a shift+reload [08:25] No, that's not the problem [08:25] http://developer.slashgeek.net/files/launchpad.png [08:25] That's how it looks like [08:25] matid: that's the new design [08:25] Is the column on the right supposed to be highlighted? [08:26] matid: there are still some changes being made (e.g. making the first box in the left column a bit more dynamic) [08:27] jamesh: I'd say that the left column is ok, but the white highlight on the right just doesn't look good [08:27] matid: the exact styling will probably change a bit [08:27] matid: the idea is that the tabs along the top of pages have been moved to the menu on the right [08:28] and the stuff that was in the menu on the right is now a "submenu" of the selected tab [08:28] (although it isn't a tab anymore ..) [08:28] jamesh: was the previous design considered less usable? [08:28] jamesh: 'cuase I find this one a bit hard to navigate [08:29] jamesh: Or maybe I'm just used to previous one [08:29] matid: the details of the changes, including some of the rationale, can be found here: https://wiki.launchpad.canonical.com/NewPageLayout [08:31] jamesh: BTW - is this change releated to upgrading Launchpad or is it just design change? [08:33] matid: it is related to upgrading Launchpad, in the sense that this is the first production rollout since the redesign was merged. [08:33] jamesh: Oh, ok [08:33] matid: it weirds me out [08:34] matid: but I figure we give it 3-4 weeks [08:34] jamesh: Just one more question, 'cuase you seem to know quite a lot about launchpad ;) [08:34] jamesh: When is the karma updated? === jamesh thinks mpt needs to do a little more CSS tweaking [08:34] matid: once a day, but I'm not sure what time [08:34] and we should get keybuk and the other architects of the new design to give feedback/etc [08:34] jamesh: I already know that, but anyway, thx for help [08:35] lifeless: yes, but, when this design has completely landed [08:35] there's still more to do [08:35] jamesh has some work pending, and so does mpt [08:36] SteveA: of course. thats why I said 3-4 weeks :) [08:37] SteveA: do you have some time to talk about the site map stuff a little? === matid [n=matid@195.116.35.246] has joined #launchpad [08:50] SteveA: one of the issues I noticed was that some of the interfaces I wanted to check for in traversed_objects were not getting added. This was because only types with registered Navigation classes ran the code path that appended things to traversed_objects [08:50] I'm not sure if that means the hook needs to be placed elsewhere, or to register an empty navigation class for the interface [08:56] SteveA: anyone getting pqm errors [08:56] bah [08:56] *all*: anyone getting pqm errors please forward them to me [08:57] jamesh: the hook actually needs to go elsewhere, but i'm surprised it doesn't work in the navigation class [08:57] which empty Navigation class would be needed? [08:57] SteveA: it does work in the navigation class [08:57] SteveA: one of the subpillars mpt listed for products was "milestones" [08:58] and IMilestone has no Navigation class, so I couldn't check to see if a milestone had been traversed [08:58] i see [08:58] can you add a Navigation for IMilestone then, but mark it XXX for me to remove when i've done the other refactoring [08:58] for the cases where things work, they work quite well [08:58] that's good [08:58] okay [09:01] SteveA: I also ran into one subpillar whose only page is a view too: the "branches" subpillar for products [09:02] there are content objects for branches, but they sit under the owner person in the URL space [09:03] It is possible that the subpillar should be removed though, since it duplicates a facet link [09:04] so, this is a subpillar for a collection of branches [09:04] that is represented by a page that displays that collection [09:05] can we get the sitemap landed without that "branches" map item, and add it later if we still need it? === bradb [n=bradb@195.182.78.95] has joined #launchpad [09:07] sure. I've got a few minor changes to make, and I'll stick it up on the review page [09:17] i guess you could make it work for a page, if that turned out to be important === stub [i=stub@sweep.bur.st] has joined #launchpad [09:31] Morning, my favorite channel :) === stub goes for a swim [10:01] don't we have a meeting now? [10:01] jamesh: you are about to get a test failure [10:01] salgado: yes [10:01] lets DoIt [10:01] reviews meeting [10:01] agenda: [10:01] * [10:01] Roll call [10:01] * [10:01] Agenda [10:01] * [10:01] Next meeting [10:01] lifeless: do you want a copy of the email? [10:01] wow that pastes bad. I shall fix for the next meeting [10:01] jamesh: please [10:02] So, whos a reviewer, or interested, and here ? [10:02] me [10:02] i'm here [10:02] me [10:03] I appear to be [10:03] lifeless: did you see that i added a proposed item on ReviewerMeetingAgenda? [10:03] ahha, I needed a reload. [10:03] yes. [10:04] one second [10:05] ok [10:05] SteveA: are you 'here' ? [10:05] BjornT: thats on the agenda for today. [10:06] cool [10:06] right. so we have jamesh, BjornT, salgado, me. [10:06] next meeting - same time, one week ? [10:06] yes [10:06] i won't be here next wednesday, i'll be flying to sweden [10:06] okay [10:07] BjornT: thats fine [10:07] these are best effort anyway [10:07] ok. BjornT your topoic [10:07] ok [10:08] so, the general queue still (since the last meeting) seems to be a place where branches get dumped until some of the reviewers is nagged to review it. [10:08] that defeats the purpose of the general queue, since you're way better off putting your branch in the reviewer's queue directly, no need to let it rot in the general queue first. [10:08] i think we either need to get rid of the general queue, or find a way of getting it processed quicker. i would prefer the latter. [10:08] for example, lifeless, as head of the review team, could daily move branches from the general queue to a suitable reviewer. this would make it more obvious for the reviewer that he has some branches to review. [10:08] thoughts? [10:08] I committed to doing what I had percieved kiko as doing, which was directly nagging, but I've not been around *at the right time* as people to be effective at that [10:09] so your suggestion works for me, if you guys will 'own' your own queues, I'm happy to schedule stuff from general to you. [10:09] jamesh, salgado - opinions ? [10:10] i think actually moving the branches to queues will work better than just nagging. [10:10] lifeless: okay. [10:10] that sounds reasonable, but I can see some cases where we may need to reject (not review) some of these assigned branches [10:11] for instance, if you're on a tight deadline, like I was some time ago with shipit [10:11] salgado: that will make it explicit which is better than the catch all [10:11] so lets do two things. [10:11] I don't expect that to happen often, but wanted to raise the point [10:12] if you are busy, put a /!\ I am busy, queue closed except for prior arrangement [10:12] in your queue [10:12] that will tell me, and anyone else, that you are busy. [10:12] and if everyone is like that, its an obvious problem :) [10:13] secondly, if you have to reject something, put it in a new queue I'll create called 'needs reassignment' with an explanantion [10:13] I can imagine several: too busy, feel uncomfortable reviewing the specific code touched etc [10:14] salgado: does that fit ? [10:14] yes, I think so [10:14] jamesh, BjornT - objections ? thoughts ? [10:15] lifeless: sounds okay. What about the case of branches that a particular reviewer is best qualified to review, but are assigned to someone else? [10:15] just coordinate with the other reviewer to take over? [10:16] jamesh: yeah, common sense applies for 'normal' issues. [10:16] lifeless: sounds good to me [10:16] please tell me about specialities like that. [10:16] *both when you reassign* [10:16] and when you realise they exist. [10:17] I ask this because one of the things we need as a team is a certain degree of cross training, so that we dont have areas of code suddenly unreviewable when one person is unwell [10:17] or busy [10:17] so I may assign outside of the specialities deliberately, for small reviews to built knowledge. [10:17] sounds sensible [10:17] lifeless: hello [10:17] SteveA: hi. [10:17] what's up? [10:18] i'll be working on malone stuff with brad [10:18] SteveA: reviewers meeting, was wondering if you where here for it ;) [10:18] not really [10:18] ok, read the minutes then :) [10:18] thanks [10:18] ok [10:19] so thats the last agenda item [10:19] we have time if theres new business, otherwise doom-it-twill-be [10:19] 5 [10:19] oh, I'll be allocating items daily [10:19] as a 'todo item' in my task list [10:20] 4 [10:21] 3 [10:21] 2 [10:21] 1 [10:21] meeting over, thanks for playing === carlos [n=carlos@71.Red-83-53-49.dynamicIP.rima-tde.net] has joined #launchpad [10:26] morning [10:30] morning [10:32] hola [10:33] carlos: so translation uploads is merged, will it show up in the next updatE? [10:33] jordi, is it? [10:33] jordi, I'm fighting with PQM [10:34] stub: around? [10:34] because it's rejecting the merge [10:34] i dunno [10:34] jordi, If I'm able to get it merged before tomorrow... it should land next week === lbm [n=lbm@cpe.atm4-0-1301006.0x50a0824e.vgnxx6.customer.tele.dk] has joined #launchpad [11:11] carlos: see topic === GoRoDeK [n=gorodek@p5083FC3D.dip.t-dialin.net] has joined #launchpad [11:13] lifeless, well, the rejects come from more than one week ago [11:13] lifeless, most of them conflicts with the other merges [11:13] lifeless, and now, because problems with pqm that I suppose you are fixing now [11:19] jamesh: ping === koke [n=koke@ubuntu/member/koke] has joined #launchpad [11:23] daf: https://launchpad.net/projects/launchpad, go to the "specifications" menu, and get an oops page! [11:23] daf: can you add that to your list to look into? [11:25] done [11:25] thanks [11:25] also [11:26] on https://launchpad.net/projects/launchpad/+specs, i'm logged in [11:26] but i see no traceback [11:26] noted === spiv [n=andrew@adsl-66-203.swiftdsl.com.au] has joined #launchpad [11:33] lifeless: ping [11:33] pong [11:33] > Right. They *should not use rsync to push*. But the place they are [11:33] > specifying is done via *rsync syntax*. [11:33] I'm very confused now. [11:33] ok [11:33] tell me where you are at [11:33] Rsync is dangerous. Its safe. No, its actually dangerous. But its not rsync at all, just rsync syntax. [11:34] ok [11:34] two cases [11:34] push [11:34] pull [11:34] many use cases [11:34] 1 use case is 'making a mirror of something someone else works on' [11:34] safe. [11:34] rsync is safe for this, but it will TRASH local data. by design. [11:35] Ok. I think I get you now. [11:35] specify that we're using rsync. Here's the places you need to be careful? [11:35] another use case 'copy a tree from A to B'. rsync will preserve trees - it wont corrupt or anything. But it will overwrite data without warning. [11:36] one specific case is 'publishing a branch'. Rsync is particularly bad for this, because its easy to overwrite a remote branch without warning using rsync directly. [11:36] bzrtools has a rsync-under-the-hood 'push' plugin [11:36] yup. I use it [11:36] that kicks in when you specify a branch using rsync syntax rather than url syntex. [11:37] so we want people to use that rsync-using-bzrtools-push plugin [11:37] rsync syntax; not using rsync directly. [11:37] the bzrtools plugin is safe because it checks the revision-history first. [11:38] unconfused now ? [11:38] Yup. clear as a bell. [11:38] cool [11:38] Thanks [11:39] jamesh: ping [11:41] hi stub [11:41] i sent you email [11:42] also, brad and i want to work on the whiteboard stuff in 4-5 hours [11:42] SteveA: The lpnotification branch is still in your review queue [11:42] oh, poo [11:42] can you put it into someone else's ? [11:42] i'm working with brad this week [11:43] maybe bjorn or jamesh can look at it? [11:43] Sure. General or are you designating a victim? [11:43] stub: does it need someone specific ? [11:43] lifeless: Nope. [11:44] stub: please put it in any empty queue, or in the shortest non empty queue === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [11:45] lifeless: punted to your queue [11:45] heh. b'stard [11:49] hey lifeless [11:49] could you remind me when I can find the bzr branch to make launchpad to like [11:49] hey stub [11:50] Hi [11:50] did sending you the email to ask for the db access for bzrsyncd was the right way to get it? [11:51] Sure. I just was incompetent and forgot. [11:52] Bah... can't find the email now :-( [11:52] Want me to forward it again? [11:53] stub: can you forward me the pqm failure you had [11:53] ddaa: /home/warthogs/archives/robertc/bzr/importd [11:54] lifeless: I don't recall a PQM failure recently... you thinking of someone else? [11:54] nope [11:54] you [11:54] lifeless: pong [11:55] jamesh: got that failure yet ? [11:55] lifeless: no [11:55] hmm [11:56] Can't find bzrsyncd in my mail archive. Please resend. [11:56] ddaa: ^^^ [11:56] I've got roberts emails [11:57] sent [11:58] lifeless: the last pqm message I've received was from yesterday [12:00] stub: you should have had mail from balleny [12:00] elmo: ping - help needed [12:00] lifeless: Nope. No mail. [12:01] stub: garh [12:01] 5/7 pqmjobs tested on balleny have failed [12:01] and neither you nor jamesh have recieved email [12:03] lifeless : Can I help you? [12:03] Znarl: please [12:03] 5 emails should have been sent from pqm on ballent [12:03] *balleny* [12:03] in the last 10 hours [12:03] but noone has recieved any AFAICT [12:03] I need to track them down for starters. [12:04] ddaa: Haven't seen that email yet. I'm receiving messages from other sources though. === ddaa checks his mailqueue [12:04] ha ... ha... === niemeyer [n=niemeyer@200-140-204-123.ctame7004.dsl.brasiltelecom.net.br] has joined #launchpad [12:05] Dec 14 09:55:36 balleny postfix/smtp[30173] : 48088201D1B: to=, relay=none, delay=3198, status=deferred (connect to mail4.bur.st[218.214.5.115] : Co) [12:05] Znarl: thats a good start! thanks [12:05] Looks like our fault, give me a minute to fix this. === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === stub goes hunting for crap on rice [12:09] morning all === SteveA + brad --> lunch [12:09] morning [12:11] stub: _really_ sent [12:12] Fixed. [12:14] lifeless: hi, is there anything wrong with PQM ? is is processing a job of mine from yesterday 12:20. Is it blocked ? === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:16] good morning! === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has left #launchpad [] [12:17] cprov: he's been moving it to its own machine [12:20] jamesh: uhm, ok then, PQM has a better home now ... === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === niemeyer [n=niemeyer@200-140-204-123.ctame7004.dsl.brasiltelecom.net.br] has joined #launchpad [12:27] cprov: /topic [12:27] stub: please forward me that email :) [12:30] ddaa: ping [12:30] lifeless: pouet [12:30] morning [12:30] lifeless: no pqm mail yet [12:30] lifeless: ok [12:30] and, to save replying to a bunch of emails, I wanted to chat quickly about private branches === StevenK [n=stevenk@14.5.233.220.exetel.com.au] has left #launchpad [] [12:31] we (Mark and I and various others) explicity considered private branches throughout Sao Carlos [12:31] in that we wanted graceful degradation when branches aren't accessible, such as being behind a firewall [12:32] but we did not want a 'checkbox to make it private' as that really suggests the wrong thing to users [12:32] thats not explicitly stated as we spent a huge amount of time talking branches over 5 different ways, all the way through to the last week [12:33] so only the end result really got written up - sorry. [12:34] lifeless: I'm listening [12:34] ddaa: thats the key === mpt [n=mpt@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:35] I'm sure that raises questions and corollaries for you [12:35] Goooooooooooooooooooooooooooooooooood morning Launchpadders [12:35] so lets talk those through [12:37] stub: jamesh: Znarl is kicking the mail queue [12:37] as soon as you get a pqm error please forward it to me [12:38] lifeless: I'm still listening. [12:39] ddaa: I've said my bit [12:39] lifeless, do you want my failure message too? [12:39] salgado: that would be great [12:39] sent [12:39] thanks === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad [12:40] okay, first thing (in order in the mail) is branch pulling [12:41] Znarl: ping [12:41] lifeless : Yep? [12:41] stub: * Installing PL/PythonU [12:41] createlang: language installation failed: ERROR: could not access file "$libdir/plpython": No such file or directory [12:41] there are some provisions for error reporting, though I consider them incomplete (I would like something like access to error logs through the librarian) [12:42] Znarl: thats a missing launchpad dependency on balleny [12:42] but in the short term they are just not implemented [12:42] Znarl: probably I missed saying 'and the DatabaseSetup wiki pages requirements [12:42] short term, I think any error in jblack cronscript should send error spam to launchpad-errors [12:42] Znarl: can we get that pages pre-reqs in the base os, and in both chroots ? [12:42] the base is of immediate importance [12:42] then, switch to something more "compact" when it's implemented [12:43] lifeless : ok. [12:43] lifeless: is there a disagreement on that? [12:43]