[11:01] <mpool> ddaa: hi, here?
[11:01] <ddaa> Hello
[11:02] <ddaa> https://launchpad.canonical.com/BazaarMeetingAgenda
[11:04] <mpool> hm, so?
[11:06] <ddaa> Meeting in 54 minutes
[11:06] <mpool> really?
[11:06] <ddaa> Well, like every week...
[11:06] <mpool> oh, i used to have another one at 7
[11:06] <mpool> ok, see you then
[12:00] <ddaa> Yay
[12:00] <ddaa> MEETING STARTS
[12:01] <ddaa> This is the launchpad-bazaar meeting, so there are more branches for use bazaar monkeys to hang about
[12:01] <ddaa> == Agenda ==
[12:01] <ddaa> Next meeting 2006-09-11, 10:00 UTC.
[12:01] <ddaa> mpool will be on leave.
[12:01] <ddaa> Say bzzzt if that does not fit.
[12:01] <ddaa>  * roll call
[12:01] <ddaa>  * production status
[12:01] <ddaa>  * invalid branches
[12:01] <ddaa>  * smart server
[12:01] <ddaa>  * advertising
[12:01] <ddaa>  * vcs-import knits
[12:01] <ddaa>  * release finder
[12:01] <ddaa>  * Python import
[12:01] <mpool> ddaa: both next week and the following week
[12:01] <ddaa>  * bzr lp://
[12:01] <ddaa>  * 1.0 targets
[12:01] <ddaa>  * critical bugs
[12:01] <ddaa>  * pending sysadmin tasks
[12:01] <ddaa>  * proritizing important tasks
[12:01] <ddaa>  * any other business
[12:02] <ddaa> == Roll call ==
[12:02] <ddaa> Spiv is on leave until September 10th.
[12:02] <SteveA> length of meeting is?
[12:02] <SteveA> (in minutes)
[12:02] <ddaa> 45 mins
[12:02] <SteveA> ok
[12:02] <jamesh> I'm here.
[12:02] <SteveA> i'm here
[12:02] <lifeless> my fingers are here
[12:02] <ddaa> good enough
[12:02] <ddaa> == Prodution status ==
[12:02] <ddaa> Early last week, abnormally long delay for mirroring sftp branches were reported. It was caused by a routing issue on escudero that caused time-outs for all vcs-imports branches.
[12:02] <ddaa> Once escudero was restored, normal service resumed.
[12:02] <ddaa> A discussion is in progress (CC Launchpad mailing list) on how to rearchiture the branch puller to minimize latency in a future-proof way.
[12:03] <ddaa> I'm having trouble understanding lifeless' last email, but that's off-topic for this meeting.
[12:04] <ddaa> == Invalid branches ==
[12:04] <ddaa> Last week actions:
[12:04] <ddaa>  * ddaa to bother jelmer about the bzr-svn bug
[12:04] <ddaa>  * ddaa and lifeless to discuss bzrlib data validation. Not done.
[12:04] <ddaa> Following up on last week. I ack bzr should prevent bad data from getting in, but since shit happens, the supermirror should be able to recover without needing administrator intervention.
[12:04] <ddaa> I'm not too sure about how to do that. Does somebody has a plan and want to start the discussion?
[12:04] <ddaa> I do not think I got it across to jelmer last week.
[12:04] <ddaa> lifeless and I did not have that discussion.
[12:05] <ddaa> jamesh: lifeless: any clue about "supermirror recovery from invalid data"?
[12:05] <lifeless> ddaa: like I said, I dont think there is a discussion to have
[12:05] <SteveA> is it a problem that is happening right now?
[12:05] <lifeless> I thought you had changed that as per the discussion we had *in last weeks meeting*
[12:06] <jamesh> ddaa: can the puller overwrite the invalid branch?
[12:06] <ddaa> jamesh: I do not expect so, that's the issue
[12:06] <ddaa> ACTION: ddaa to email to explain what he sees as a problem, since apparently it's not obvious
[12:06] <SteveA> if the problem is not occuring right now...
[12:06] <ddaa> SteveA: it's occuring right now
[12:07] <ddaa> let's move on
[12:07] <jamesh> ddaa: ideally we'd handle it in the same way as a branch format change: blow away the mirror and start again.  The question is whether we can differentiate between invalid data and bzrlib bugs
[12:07] <SteveA> how much is it occuring?
[12:07] <ddaa> SteveA: all samba branches produced by bzr-svn
[12:07] <jamesh> (i.e. do we get a specific exception or random failures inside bzrlib?)
[12:07] <ddaa> potentially random failures, although this specific problem causes a BzrError.
[12:08] <ddaa> == Smart server ==
[12:08] <ddaa> Last week spiv said: lifeless & mpool & I will be meeting in person tomorrow to continue work on the smart server.  lifeless has figured out some good goals w.r.t. supermirror integration and HTTP integration that's the next step.
[12:08] <ddaa> mpool: status?
[12:08] <mpool> we did meet,
[12:09] <mpool> lifeless: what was the last status you had from spiv before he left?
[12:09] <lifeless> he was part way through splitting those branches
[12:09] <lifeless> I hope/imagine he has pushed his current set to chinstrap/sodium
[12:10] <mpool> i hope we can merge at least part of it for 0.11, and have andrew merge the corresponding bits to the supermirror when he gets back
[12:10] <mpool> i'm not sure if this is realistiic
[12:11] <lifeless> hes back with a week to spare for 0.11
[12:11] <lifeless> some at least will land, I'm sure of it
[12:12] <ddaa> Do you think it's still on track for deployment before october 8th?
[12:12] <mpool> ddaa: not as much slack as i would like, but possible
[12:12] <ddaa> (I think that's the Launchpad 1.0 time)
[12:12] <lifeless> Full smart server deployment, no
[12:12] <ddaa> lifeless: as opposed to what?
[12:12] <lifeless> we're aiming for the RPC transport deployed into both the hosting and mirror environments
[12:12] <ddaa> I'm not clear on what is "full deployment" as opposed to "core support"
[12:13] <lifeless> the smart server will be a launchpad-code-free addition on top of that as it goes into bzr
[12:14] <ddaa> lifeless: so you mean that the smart server may be used for the publishing side, but the hosting side will be post 1.0?
[12:14] <lifeless> no
[12:14] <mpool> ddaa: i think we mean
[12:14] <mpool> all the launchpad-specific code will be done by then (dog willing)
[12:14] <mpool> but it need more pulls from bzrlib to be really exciting
[12:15] <ddaa> what is the risk level of those "extra pulls", is that just some tuning that needs to go through review and merge, or is there some tricky outstanding issues?
[12:16] <mpool> ddaa: where are you driving with these questions?
[12:16] <lifeless> sorry, thats *what*
[12:16] <mpool> heh
[12:16] <ddaa> trying to get a hang on the progress and Lauchpad 1.0 target delivery, since it seems I'm the one reporting on that
[12:16] <ddaa> and it's all very fuzzy to me
[12:17] <ddaa> but maybe it's a pointless excercice since it will be done when it's done and there is not anything we can do to make it happen faster
[12:17] <mpool> ok, so let's say it's likely we will have approximately alpha-level smart server support fielded by that date
[12:18] <mpool> the additional work in bzr will be to speed it up by doing higher-level operations
[12:18] <SteveA> i'm keen to be running a smart-server on the supermirror soon, even if it provides no benefit over regular sftp
[12:18] <mpool> it is not risky in an architectural sense, i am confident it will go according to plan
[12:18] <SteveA> so that we will know about how it works practically
[12:18] <mpool> SteveA: right, that's what we're aiming for first
[12:18] <mpool> right
[12:18] <mpool> and also to shake out any lp integration issues
[12:18] <lifeless> SteveA: thats exactly what we've mapped out
[12:18] <SteveA> and we can then add extra commands/calls or whatever you call it
[12:18] <mpool> i think we should get spiv on that as soon as we can when he returngs
[12:19] <lifeless> mpool: hes already on it
[12:19] <SteveA> later to incrementally improve it
[12:19] <mpool> cool
[12:19] <mpool> so can we call that closed?
[12:19] <lifeless> SteveA: yes exactly
[12:19] <ddaa> Yup. I feel enlightened.
[12:19] <SteveA> the 1.0 goal should be to have the smart server in operation
[12:19] <lifeless> how about we talk about something that has not changed in the last week
[12:19] <SteveA> not that it actually buys users anything immediately#
[12:19] <ddaa> == Advertising ==
[12:19] <ddaa> Last meeting actions:
[12:19] <ddaa>  * spiv: blog about similarities between SVN and bzr checkouts, in relation to Launchpad.
[12:19] <ddaa>  * ddaa: when rolled out, to blog about branch UI improvements.
[12:19] <ddaa>  * unassigned: when rolled out, blog about --create-prefix not being needed anymore.
[12:19] <ddaa> spiv on vacation
[12:20] <ddaa> ddaa and unassigned, waiting on rollout
[12:20] <ddaa> moving on
[12:20] <mpool> ddaa: i think we need in the medium term to do something more than blog to communicate about this
[12:20] <ddaa> The blog thing appears to be working well enough for new.
[12:20] <ddaa> for *now*
[12:20] <mpool> how do you assess that?
[12:21] <jamesh> but how do people find these scattered howtos 6 months from now?
[12:21] <ddaa> mpool: I throw some chicken bones and read in them
[12:21] <jamesh> It'd be good to get them in a central location (or at least linked from a central location)
[12:21] <lifeless> any post should be put on bazaar-vcs.org/Welcome
[12:21] <lifeless> in the news area
[12:21] <mpool> they should be reachable from launchpad in an organized way
[12:21] <ddaa> yeah, we need something more structured, maybe like the Malone/Rosetta docs, and link from that.
[12:21] <mpool> lifeless: somethin g kg like that
[12:21] <jamesh> help.launchpad.net maybe?
[12:21] <mpool> we don't need to sort that out now
[12:22] <mpool> indeeed it may be good to seek UI opinions from Uman or mpt or similar folks about where to put it
[12:22] <ddaa> action for someone?
[12:22] <mpool> yes
[12:22] <mpool> SteveA: agree? who should do it?
[12:23] <SteveA> I'd like you or ddaa to put it on help.launchpad.net
[12:23] <ddaa> mh... since mpool is working on critical things like the smart server, it might be a better idea to use my time for that
[12:24] <mpool> ddaa: that would be great
[12:24] <ddaa> ACTION: ddaa to start compiling blog data on help.launchpad.net
[12:24] <SteveA> to start with, it's just a matter of making a page, linking it to the front page
[12:24] <ddaa> SteveA: happy to do no more than that, then :)
[12:24] <mpool> ddaa: actually, to *really* start with, just write a very small spec for how this is documented, and seek comments on hat
[12:24] <SteveA> I'd go the other way
[12:25] <ddaa> SteveA++
[12:25] <SteveA> have a single place where we collect the documentation
[12:25] <mpool> SteveA: implement first, comments later?
[12:25] <SteveA> that is publicly accessible
[12:25] <SteveA> and then look for opportunities to better link it and put it on the bzr website or whatever
[12:25] <SteveA> but we need to have the resource before we can use it
[12:25] <ddaa> I like the idea of producing raw material as blog posts and integrate that material in a central place.
[12:26] <ddaa> but, hey, we have more critical stuff to do now
[12:26] <SteveA> and jamesh made a good point about how people find the articles N months from now
[12:26] <ddaa> Moving on?
[12:26] <SteveA> another option is having a "using bzr with launchpad" section on the bzr website
[12:26] <SteveA> done
[12:27] <ddaa> == vcs-imports knits ==
[12:27] <ddaa> It appears that the outstanding bzr patches have been merged to bzr.dev, what's needed now is a bzr update on rocketfuel.
[12:27] <ddaa> lifeless: can you sync/cherrypick rocketfuel's bzr?
[12:27] <ddaa> The last outstanding patch is launchpad/import-batch-progress. Should the BatchProgress code be submitted to bzr upstream, or should it stay in Launchpad?
[12:27] <ddaa> https://devpad.canonical.com/~jamesh/pending-reviews/david/launchpad/importd-batch-progress/full-diff
[12:27] <lifeless> we should just update to 0.10
[12:27] <lifeless> which has been released
[12:27] <ddaa> lifeless: by all means
[12:27] <lifeless> that may or may not include all the patches
[12:27] <lifeless> I think it has 1 of them
[12:27] <lifeless> its also much faster than the current bzr we're running
[12:28] <ddaa> can you cherrypick the missing bits as well?
[12:28] <jamesh> might even protect us from Jelmer's branches :)
[12:28] <ddaa> performance is not our big issue ATM
[12:28] <lifeless> you have already applied the fix to our branch right ?
[12:29] <ddaa> lifeless: I cannot commit to rocketfuel's bzr
[12:29] <lifeless> ok
[12:29] <ddaa> I rolled out a custom branch to importd when deploying the knits conversion code
[12:29] <lifeless> I suggest just updating to stock bzr 0.10 and keeping your extra fix whereever it is now
[12:29] <lifeless> the second fix will be in 0.11
[12:29] <lifeless> and AFAIK we've done all the knit conversions right
[12:29] <lifeless> ?
[12:30] <ddaa> lifeless: right, but it looks like there's a new upgrade to do soon.
[12:30] <lifeless> ddaa: ???
[12:30] <ddaa> about root id
[12:30] <lifeless> 0.11 at the earliest
[12:30] <ddaa> okay, then it should be okay to temporarily regress on format converision support
[12:31] <lifeless> and as that will come in via bzr, I dont see that theres any relevance for these fixes to 'our bzrlib' - them being in the bzr that comes is is all thats needed
[12:31] <ddaa> the relevance is avoiding deploying custom bzr code to importd
[12:31] <ddaa> but I guess it's no longer necessary, as you point out
[12:31] <ddaa> What about the BatchProgress thing?
[12:32] <lifeless> what thing ?
[12:32] <ddaa> it's the Progress class that gives heartbeat output for buildbot
[12:32] <ddaa> Bah, let's move on.
[12:32] <lifeless> I dont know anything about that, other than you wrote it
[12:32] <ddaa> ACTION: ddaa sort out what to do with BatchProgress with lifeless and mpool
[12:33] <jamesh> (we're 2/3 the way through the meeting timeslot, btw)
[12:33] <ddaa> == Release finder ==
[12:33] <ddaa> Last meeting action:
[12:33] <ddaa>  * jamesh: report on Dyson full test run.
[12:33] <ddaa> yeah, we're running late :(
[12:33] <lifeless> less discussion, more yes/no. DeferToList
[12:34] <SteveA> meta: the thing to do here is either to agree to trip certain agenda points from the meeting, or agree with attendees for an extended meeting.
[12:34] <jamesh> It is definitely working better than before, but we got a new exception in the HTTP walker class when trying to read docbook.org indexes
[12:34] <SteveA> s/trip/strip/
[12:35] <ddaa> SteveA: I can just speed up some status report items
[12:35] <jamesh> Looks like a simple mis-use of BeautifulSoup, so hopefully we'll have a better result next week
[12:35] <ddaa> okay, so still in the works, progress being made
[12:35] <jamesh> (I should be able to add tests for this failure pretty easily too)
[12:35] <ddaa> == Python import ==
[12:35] <ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/56360
[12:35] <ddaa> Was busy catching up, merging stuff and having design discussions via email. No progress on that. Need to decide on prioritization later this meeting.
[12:35] <lifeless> ya, I'm nagging on the release finder regularly ;)
[12:35] <ddaa> no need to discuss python import right now, later/post-meeting...
[12:36] <lifeless> didn't we have prioritisation discussions for it last week ?
[12:36] <SteveA> jamesh: note that I updated our BeautifulSoup in mainline launchpad
[12:36] <ddaa> == bzr lp:// ==
[12:36] <ddaa> Last meeting action:
[12:36] <ddaa>  * mpool: integrate comments to BranchIndirection
[12:36] <SteveA> ...to the latest release
[12:36] <ddaa> lifeless: not as such, as far as I recall
[12:36] <jamesh> SteveA: yeah.  The way the code was using beautiful soup seemed to bypass the encoding detection, leading to problems with the non-ASCII page data
[12:37] <ddaa> I think that spec has not changed since last week. mpool, can you spend some time on that? (yes/no)
[12:37] <SteveA> jamesh: latest B.S. is stricter about unicode output
[12:37] <SteveA> ddaa: mpool, mark and I talked a little about this today
[12:38] <SteveA> mpool said he'd update the spec
[12:38] <ddaa> okay, see you next week about BranchIndirection
[12:38] <jamesh> SteveA: the p-r-f code is doing "soup = BeautifulSoup(); soup.feed(data)", which fails.  Doing "soup = BeautifulSoup(data)" works.
[12:38] <ddaa> == 1.0 targets ==
[12:38] <ddaa> [stripping some stuff that needs no discussion]
[12:38] <ddaa> bzr-roundtrip-svn: not for 1.0, but discussion is in progress on the bazaar-ng mailing list about how to make bzr-svn acceptable to importd.
[12:38] <ddaa> mpool: SteveA wanted to know what you were thinking of the general direction of this discussion.
[12:39] <mpool> i have not updated the BranchIndirection spec
[12:39] <SteveA> feeding a soup is not usually adding things to a soup, but rather consuming the soup
[12:39] <mpool> the roundtripping discussion seemed ok to me...
[12:40] <ddaa> == Critical bugs ==
[12:40] <ddaa> [skipping that, simple status reporting, see the BazaarMeetingAgenda]
[12:40] <mpool> action: mbp: read up/tick off svn roundtripping discussion
[12:40] <lifeless> FWIW sivs latest work is missing stuff done thursday and friday
[12:40] <ddaa> mpool: that would be nice
[12:41] <ddaa> == Sysadmin tasks ==
[12:41] <ddaa> [skipping that, see BazaarMeetingAgenda]
[12:41] <ddaa> == Prioritizing important tasks ==
[12:41] <ddaa> There are several important new tasks competing for our time. Spiv is out being even more smart and serving than usual, so it's between jamesh and me.
[12:41] <ddaa>  * Removing Arch support. Low risk, relatively large (est. 16h ddaa). 1.0 target.
[12:41] <ddaa>  * Python import, currently bug 56360. High risk (may have other hidden blockers), unknown size (est. at least 6h, at most ???).
[12:41] <ddaa>  * Bug 31308 (native productseries branch) Low risk, medium sized (est. 8h).
[12:41] <ddaa> To that, I would like to add: bug 34540 (cannot delete a branch) which I think is the largest remaining barrier to adoption of the branch registry. Just allowing to disable branches, without implementing garbage collection should be relatively simple.
[12:41] <ddaa>  * Bug 34540 (cannot delete a branch). Low risk, medium sized (est. 8h).
[12:41] <ddaa> Since all those tasks look very important and urgent to me, I suggest:
[12:41] <ddaa>  * ddaa: removing arch support and python import.
[12:41] <ddaa>  * jamesh: productseries branch and deleting a branch.
[12:41] <ddaa> SteveA: what do you think?
[12:42] <ddaa> Okay, that's one item I want a decision on, but can be discussed post meeting (lifeless and mpool not really required for that)
[12:42] <jamesh> ddaa: I'm also working on automatic BugBranch link creation now, btw
[12:42] <SteveA> I'd like to see the python import set off, cos I want to see whether it will break and how.
[12:43] <ddaa> SteveA: IMO arch support removal takes priority as it's a 1.0 goal
[12:43] <SteveA> removing arch support doesn't cost us anything to delay a while
[12:43] <jamesh> "productseries branch" refers to switching to import_branch and user_branch, right?
[12:43] <ddaa> jamesh: yes
[12:43] <SteveA> ddaa: it doesn't buy us anything this week, but having a python import does
[12:43] <ddaa> SteveA: okay
[12:43] <lifeless> ddaa: removing arch support has been turned down by steve in the last 4-5 meetings I can recall
[12:44] <lifeless> ddaa: I'd really like it to stop being an agenda item, its wasting cycles
[12:44] <SteveA> ddaa proposed it as a task for him and tim p. to do together, which I rejected
[12:44] <SteveA> I think ddaa should do it, but I think it is better to do python first
[12:44] <SteveA> because it is estimated as less time
[12:44] <SteveA> and it has more overall benefit, imo
[12:45] <mpool> after that i'd like to suggest working on a firefox import
[12:45] <mpool> if there is not already one
[12:45] <mpool> they're looking at moving from cvs
[12:45] <mpool> SteveA: maybe you should add "before you go on leave" to the policies wiki?
[12:45] <lifeless> ok, piss-break before the review meeting
[12:45] <jamesh> mozilla/firefox makes heavy use of CVSROOT/modules aliases
[12:45] <ddaa> which is not really supported by importd
[12:45] <lifeless> mozilla will melt your brain
[12:46] <ddaa> anyway, that's offtopic for that discussion.
[12:46] <ddaa> SteveA: jamesh: I think native-branch-for-series and deleting-branch are more important than bug-branch stuff
[12:46] <ddaa> are they are important blockers in the existing system
[12:47] <ddaa> I'd like very much to see progress on those, but I do not think I will have the time soon.
[12:47] <SteveA> ddaa: let's talk about your priorities etc. later today
[12:47] <ddaa> Fine.
[12:47] <jamesh> I've only done some speccing for the bugbranch stuff, so I can easily move over to the productseries branch stuff
[12:47] <ddaa> == Any other business? ==
[12:48] <ddaa> One minute to say "hey!".
[12:48] <mpool> hey!
[12:48] <mpool> two things
[12:48] <jamesh> I wouldn't mind some comments on https://launchpad.canonical.com/AutomaticBugBranchLinks after I flesh it out a bit more
[12:48] <mpool> firstly, everyone in this meeting should read the 32/Bazaar spec
[12:48] <mpool> https://wiki.canonical.com/32/Bazaar
[12:49] <mpool> ddaa, thanks for your commens
[12:49] <mpool> if you have not, please do so before next week
[12:49] <ddaa> jamesh: post to the LP mailing list CC key people when you've done the fleshing out
[12:49] <SteveA> ddaa: jamesh, mpool and lifeless and I had a meeting earlier today about getting jamesh to do some work on the bug-branch stuff and lp://// stuff.
[12:49] <mpool> secondly, following on from what you just mentioned
[12:49] <mpool> there are a few bzr-lp features we need to focus on
[12:49] <mpool> - launchpad-url
[12:50] <mpool> aka branch indirection
[12:50] <mpool> - redirecting from a branch page to branch content
[12:50] <mpool> - native branches for products, as you just mentioned
[12:50] <mpool> and bug-branch connections
[12:50] <mpool> many of these require both bzr and lp changes
[12:50] <mpool> i think jamesh owns bug-branch connections now,
[12:51] <mpool> how about the others?  any comments on who's looking after them, or relative priority?
[12:51] <mpool> or whether they're for lp 1.0?
[12:51] <ddaa> my pet peeve ATM is branch-delete
[12:51] <ddaa> I really think it's an adoption blocker
[12:52] <SteveA> ddaa: i want to learn why you think that, but let's talk later today about it
[12:52] <jamesh> branch-delete may be in less demand when branch move/rename is available
[12:52] <mpool> not having any main branch for bzr is a peeve for me
[12:52] <jamesh> it is often a case of "I put the branch in the wrong place and now want it deleted"
[12:52] <ddaa> jamesh: certainly
[12:52] <mpool> ddaa, it sounded like you worked out with mark the changes that would be necessary to fix that, is that true?
[12:53] <ddaa> mpool: there was an email discussion between sabdfl and jamesh while I was on vacation
[12:53] <jamesh> mpool: ddaa proposed I look at this bug (see "productseries branch" earlier)
[12:53] <ddaa> sabdfl essentially approved the direction we are taking, without reservation, after a few explanations from jamesh
[12:53] <mpool> ok, so it's all good? not blocked?
[12:54] <ddaa> blocked on getting somebody to actually do it :)
[12:54] <ddaa> If jamesh can do it this week, I'm cool with that. Delete can wait another week or two.
[12:55] <ddaa> since it's not a technical prereq for anything else
[12:55] <mpool> ok, well, it's not for me to say who will do it
[12:55] <mpool> that's between you, stevea, jamesh & others
[12:55] <mpool> i just want to make sure it's flowing along
[12:56] <mpool> branch indirection is blocked on me fixing the spec
[12:56] <mpool> for example.
[12:56] <ddaa> Okay, I'll put it on the top of my "jamesh please" list :)
[12:56] <jamesh> okay
[12:56] <mpool> ok, how about redirecting from pages to brnahces?
[12:56] <SteveA> meta: should have agreed an extension to the meeting.
[12:56] <mpool> there are bugs open, i don't know their numbers.
[12:57] <jamesh> setting the productseries branch is a prereq for a bunch of other stuff, so I'll try and get it sorted this week
[12:57] <jamesh> (e.g. the branch indirection spec)
[12:57] <mpool> jamesh: that's true; doing it soon would be great
[12:57] <mpool> good point
[12:57] <ddaa> mpool: I sugges that you revive the discussion that on the mailing list, so we can take the time to dig up the bugs etc.
[12:57] <mpool> ok
[12:57] <mpool> ok, that's all then
[12:58] <ddaa> MEETING CLOSED
[12:58] <SteveA> thanks david
[12:58] <ddaa> Thank you all for your attention.
[12:58] <ddaa> Sorry for being late.
[12:58] <SteveA> after the review meeting, i'll be going for some lunch
[12:58] <SteveA> and when I get back, I'd like to talk with you about these tasks
[12:58] <ddaa> unless somebody wants to talk to me about something right now
[02:48] <ddaa> SteveA: ping
[03:29] <SteveA> hi ddaa
[03:35] <SteveA> ddaa: ping
[03:36] <ddaa> was workraving
[03:37] <ddaa> SteveA: you wanted to talk about the tasks for the next weeks
[03:38] <ddaa> first, I'd like to talk meta-meeting
[03:38] <SteveA> ok
[03:38] <SteveA> shall we have a voice call?
[03:39] <ddaa> please no
[03:39] <SteveA> porquoi?
[03:39] <SteveA> ^u
[03:39] <ddaa> I have some distraction at home, between the kittens and the gf who is having a one week sick leave
[03:40] <SteveA> that's not really a good reason
[03:40] <ddaa> well okay
[03:40] <ddaa> let's have voice
[03:40] <SteveA> skype okay?
[03:41] <ddaa> should work
[03:41] <ddaa> or ekiga if you prefer, works okay here
[03:42] <SteveA> i've had not much success with ekiga
[03:42] <SteveA> probably need to change my router
[03:42] <SteveA> so, let's do skype today
[03:43] <SteveA> i'm running skyep
[03:43] <ddaa> setting up
[03:43] <SteveA> but i don't seem to have you listed at all in my addressbook
[03:44] <ddaa> david.allouche
[03:45] <ddaa> I cannot seem to get online for some reason...
[03:45] <ddaa> It seems I cannot get online.
[03:47] <SteveA> well
[03:47] <SteveA> i just tried adding you to my skype contacts
[03:47] <SteveA> and I get an error
[03:47] <SteveA> "david.allouche was added to your Contacts, even though the Skype Name was not found
[03:47] <SteveA> The Skye Name does not exist or this person has not been online for a long time"
[03:48] <ddaa> I got online like a couple of moths ago
[03:48] <ddaa> but it does not work now
[03:48] <ddaa> let's try ekiga
[03:49] <SteveA> after a few months, they remove your account
[03:50] <SteveA> i'm running ekiga now
[03:50] <ddaa> one minute please
[03:50] <SteveA> https://wiki.canonical.com/VOIP/Extensions
[03:52] <ddaa> bingo, she got angry at me because I wanted to be alone for the call
[04:22] <ddaa> oops
[04:22] <SteveA> what happen?
[04:22] <SteveA> someone set up us the bomb?
[04:22] <ddaa> sound got scrambled, I reset the connection
[04:23] <SteveA> ok, i just hung up


[00:06] <airurando> hey moylan. how are you. It appears I've lost ShaneM.
[00:07] <airurando> moylan: apologies for the delay
[00:07] <moylan> mp worries.
[00:07] <moylan> no
[00:07] <airurando> I've been dealing with unusual but welcome activity on the mailing list
[00:07] <moylan> a good problem to have
[00:08] <airurando> indeed
[00:08] <airurando> very welsome
[00:08] <airurando> *welcome
[00:08] <moylan> and now it's good friday when the entire country goes mental to have a drink :-)
[00:09] <airurando> aye
[00:09] <airurando> good friday and christmas
[00:09] <airurando> what you can't have you desperately want
[00:09] <moylan> good friday is worse. worked in a corner shop. couldn't believe the amount of booze shifted
[00:10] <airurando> talked about this at work today.
[00:10] <moylan> same every year.  peoples prime concern is that they have a place to have a drink on good friday.
[00:10] <airurando> it is funny
[00:11] <airurando> moylan: will you make the release party?
[00:11] <moylan> should be able to.  trying to decide if i'll go to jimmy chungs or pub. one or the other as i'm on crutches.
[00:12] <airurando> yeah
[00:12] <airurando> do whats right for you
[00:12] <moylan> you betcha!
[00:12] <airurando> possibly Jimmy Chungs then skidadle
[00:13] <airurando> It would be great to meet you
[00:13] <airurando> at least civilised seats in Jimmy Chungs
[00:13] <moylan> probably more likely as that is earlier as i don't like to be in town too late. as i'm on public transport i always seem to end up in hand to hand combat after 9pm on dublin bus.
[00:14] <airurando> where are you based/
[00:14] <moylan> killiney
[00:14] <airurando> hmm
[00:15] <moylan> well i say killiney but 100ft away from junction that is ballybrack, sallynoggin and killiney.  so people say killiney
[00:15] <airurando> thought I might be able to offer a lift home but wrong direction
[00:15] <airurando> unfortunately
[00:15] <moylan> naw it's cool.  i like to keep myself mobile.
[00:17] <airurando> understand
[00:17] <airurando> look forward to meeting you at either!
[00:18] <moylan> should see you there.
[00:18] <airurando> must dash now as I'm heading to cork in the am
[00:18] <moylan> take care and drive safe
[00:18] <airurando> don't forget to sigh up at:
[00:19] <airurando> took me a while to get it......
[00:19] <airurando> http://loco.ubuntu.com/events/team/916/detail/
[00:20] <airurando> night moylan
[00:20] <airurando> nn all
[00:21] <ShaneM> Sorry, just didn't see the notification updates.
[00:21] <ShaneM> It's hard to notice it in Unity :P


[08:46] <davmor2> Morning All :)
[08:47] <darizzle> morning
[08:47] <darizzle> its night in australia though
[08:47] <mvo> hey davmor2
[14:49] <mvo> sbeattie: is there a chance that you (or someone from the sru-verfication team) could do some update-manager verifications soonish? its nothing major, but would be nice to make the experience more smooth
[17:24] <sbeattie> mvo: is there a way to verify bug 364620 via adept_updater instead of update_manager?
[17:24] <ubot4> Launchpad bug 364620 in update-manager "guidance-power-manager remains installed for 8.04 -> 9.04 Kubuntu Upgrade" [Undecided,Fix committed] https://launchpad.net/bugs/364620
[18:03] <mvo> sbeattie: is the TEST CASE description not working (or not good enough?)
[18:05] <sbeattie> mvo: I didn't realize you were asking to reset to intrepid rather than hardy; it doesn't particularly smell authentic to me; I am currently trying jriddell's 8.04->9.04 kubuntu upgrade script modified to pull jaunty.tar.gz from jaunty-proposed.
[18:05] <sbeattie> mvo: I am having problems reproducing the early exit of bug 363500
[18:05] <ubot4> Launchpad bug 363500 in update-manager "update-manager jaunty partial upgrade exists silently" [Undecided,In progress] https://launchpad.net/bugs/363500
[18:14] <mvo> sbeattie: it affects both intrepid and hardy, but testing intrepid should be enough, its the same code-path for both
[18:15] <mvo> sbeattie: (that was for 364620)
[18:18] <sbeattie> mvo: sure. I just, as a general rule, try to minimize variation in my before and after test runs so as to try to make sure I'm only seeing differences in behavior due to the change I'm trying to verify.
[18:19] <mvo> sbeattie: right, that makes sense of course
[18:19] <mvo> sbeattie: I'm checkiing 363500 now - trouble reproducing means it just works for you :) ? no crashes
[18:19] <sbeattie> mvo: yeah, it just goes ahead and does updates.
[18:20] <sbeattie> but then, this is in a vm with no detectable nvidia hardware.
[18:20] <sbeattie> not sure if that matters.
[18:21] <sbeattie> also, what's 'update-manager --dist-upgrade' doing differently than just plain 'update-manager'?
[18:22] <mvo> sbeattie: update-manager will never remove package (it will hold them back)
[18:22] <mvo> sbeattie: but --dist-upgrade will, its what u-m runs when it says "partial upgrade"
[18:23] <sbeattie> ah, okay.
[18:36] <mvo> sbeattie: I updated the bugreport, turns out the code is cleverer (for #363500) the code is clever than I thought and it uses the updated nvidia-common (that made it into jaunty-final)
[18:45] <sbeattie> bah, X crashed.
 sbeattie: I updated the bugreport, turns out the code is cleverer (for #363500) the code is clever than I thought and it uses the updated nvidia-common (that made it into jaunty-final)
[18:47] <sbeattie> mvo: thanks, I'll look
[19:28] <brooksbp> hello
[19:28] <brooksbp> can someone please help me with an issue in compiling the kernel?
[19:28] <brooksbp> I ran into this problem...
[19:28] <brooksbp> strip:/usr/src/ubuntu-intrepid/debian/linux-image-2.6.27-9server//lib/modules/2.6.27-9-server/kernel/drivers/atm/ambassador.ko: File format not recognized
[19:28] <brooksbp> make[3]: *** [drivers/atm/ambassador.ko] Error 1
[19:28] <brooksbp> make[2]: *** [_modinst_] Error 2
[19:28] <brooksbp> make[1]: *** [sub-make] Error 2
[19:28] <brooksbp> make[1]: Leaving directory '/usr/src/ubuntu-intrepid'
[19:28] <brooksbp> make: *** [install-server] Error 2
[19:28] <brooksbp> I don't even need this driver... so how can I get around this and finish my build?


[06:10] <knightwise> morning peeps
[06:24] <brobostigon> morning boys and girls.
[06:33] <zmoylan-pi> o/
[06:36] <brobostigon> o/
[07:40] <knightwise> hey guys
[07:40] <knightwise> how are tricks !
[08:10] <SuperMatt> bloomin twitter and github
[09:14]  * zmoylan-pi changes twitter password... a plain log file... how... dumb...
[09:16] <zmoylan-pi> had that password for 10 years... :-)
[09:42] <SuperMatt> I don't think it would have been a plain log file. I image they probably had a logging system that was capturing all the POST variables, and they probably forgot to leave out log in requests.
[09:43] <SuperMatt> But I've now I've been through my passwords and changed all the ones that matter, I.E those which could potentially cost me money
[09:43] <SuperMatt> I'm using a password manager now, so I'm just using fully random passwords for everything
[18:00] <DJones> daftykins: We have phone lines, but at the end of the day, no matter which ISP I use, they're using the same hard wired cables, so to me, I don't think it'd make a difference
[18:03] <daftykins> DJones: yeah i just meant (that i think) it doesn't immediately mean Virgin can't offer you anything if you have no coax in your area
[18:12] <DJones> daftykins: Agreed, BT & Sky are the biggest suppliers in the area, so presumably have the largest infrastructure, which is why I'm not changing
[18:13] <DJones> Must admit, Sky haven't been a problem, decent speeds, no downtime etc, so can't complain about them
[18:14] <daftykins> i think if you don't push much data they're probably a good choice yeah, as i think Sky have caps?
[18:15] <daftykins> down here in the islands we don't have BT, there are three ISPs but two small ones just resell the same service of the main one
[18:33] <DJones> No caps that I'm aware of, although I'm not downloading anything that would hit a cap anyway
[18:57] <nucc1> does anyone consider it a bug that open-scsi installs a service which waits *indefinitely* for network connection at startup?
[18:58] <daftykins> !info open-scsi
[18:58] <daftykins> more like just not a sane default? can't say i know what that is though
[19:02] <nucc1> sorry, i meant open-iscsi
[19:02] <nucc1> yes, it's an un-sane default :)
[19:03] <nucc1> ships by default in the 18.04 server (or it installs by default) can never tell nowadays :)
[19:03] <nucc1> anyway, even the installer refused to progress without a network connection
[19:03] <nucc1> I don't know if I somehow ended up with a "cloud" spin of bionic or something
[19:04] <nucc1> also, this is Bionic Beaver
[19:04] <nucc1> !info open-iscsi
[19:04] <daftykins> kinda had a feeling it could've been iSCSI but didn't want to spam the bot too much more without being sure :>
[19:05] <daftykins> standard server image then huh? i can't remember if subiquity had much of a step for picking software
[19:05] <nucc1> yes, it's the standard server image
[19:05] <daftykins> such as the older server LTS releases had tasksel
[19:05] <nucc1> Yea, the whole thing seems to assume that I'm deploying to a public cloud
[19:06] <nucc1> i'm now manually undoing all the unwanted things it caused that i can find
[19:06] <daftykins> well apparently it is coming with this cloud-image rubbish on it now
[19:06] <nucc1> yea, it's called cloud-init (kinda wanna call it cloud-innit?)
[19:06] <daftykins> honestly i'm a bit hesitant to make use of bionic with all the junk it comes with - i think it has a 3GB default install size even on digitalocean
[19:06] <daftykins> that's the one - i keep forgetting its name as i haven't put much time into bionic yet
[19:07] <nucc1> hmmm, i'm building a router, and i just wanted the latest-greatest so i could poke into the innards
[19:07] <daftykins> i don't like the new method for static IP addressing either
[19:07] <nucc1> well, that was a surprise, but i think it makes sense
[19:07] <daftykins> is that all it's going to do? think i'd rather run pfsense
[19:07] <nucc1> YAML is i assume good for scripts
[19:07] <nucc1> i am more comfy in ubuntu
[19:08] <daftykins> thing is i don't think i'll be memorising that yaml config format anytime soon versus i knew the /etc/network/interfaces file inside out
[19:08] <daftykins> right but it's general purpose, you have to reinvent the wheel to run *buntu as a router rather than something specifically designed to be a router
[19:08] <nucc1> yes, the re-inventing the wheel part is the only way I think i'll update my knowledge.
[19:09] <daftykins> oh ok so more of a test setup rather than live system? :>
[19:09] <nucc1> it will become my main router, and then i want to use it to learn about traffic accounting in linux
[19:11] <daftykins> what's the hardware? curious as i recently did a big overhaul of my main home server and cut power draw hugely \o/
[19:12] <nucc1> i got a jetway jbc 365
[19:12] <nucc1> and a 2GB stick of RAM.
[19:13] <nucc1> https://www.mini-itx.com/store/~JBC365
[19:13] <nucc1> it turns out that all developers apparently run Xeon CPUs with PCiE SSDs
[19:13] <nucc1> because I couldn't use a good old spinning disk inside this machine.
[19:13] <daftykins> ooh neat
[19:13] <nucc1> The bios assumes that the disk is bad because it's slow at POST
[19:13] <nucc1> so i only got it to boot successfully about 50% of the time
[19:14] <daftykins> yeah you don't wanna go running spinning rust in low power kit anyway
[19:14] <daftykins> does it have a BIOS with spectre mitigations available?
[19:14] <nucc1> well, it had a lot of capacity so i figured perhaps i could set up a cifs share on it too
[19:14] <nucc1> he he, i have not bothered about spectre
[19:15] <daftykins> granted the newer one just came out in the news, but it's not something that should be ignored
[19:15] <nucc1> i don't think merely crafting packets is enough to exploit it, but well, i'm being cavalier about it
[19:15] <daftykins> i'm moving away from all the old core 2 systems i had since intel abandoned patching them
[19:15] <nucc1> that's paranoid :)
[19:16] <nucc1> keeping my good old sandybridge
[19:16] <nucc1> haven't even bothered to check for fixes.
[19:16] <nucc1> it's not a cloud machine
[19:17] <daftykins> it's not the primary reason i'm dumping them, like i said i cut power on my home server by dumping a core 2 duo and moving to a low TDP i5 haswell
[19:18] <daftykins> i've a Sony sandybridge laptop here that'll never get patched
[19:18] <nucc1> Yea, I have generally avoided re-purposing old hardware to use as a router...
[19:19] <nucc1> even though getting a low-power machine as I did costs more probably than old hardware would use in electricity, it sits better with me mentally.
[19:19] <daftykins> too much power for a router yeah - i have a couple of those AMD APU2 systems from linitx.com for pfsense routers
[19:25] <nucc1> this isn't a bad machine: https://linitx.com/product/pc-engines-apu2-c4-system-board-with-4gb-ram/14822
[19:30] <daftykins> yeah that's the one
[19:30] <daftykins> 16GB mSATA SSD
[19:33] <daftykins> good company too
[20:30] <diddledan> why fireworks?
[20:45] <daftykins> fireworks?
[20:52] <diddledan> fireworks!
[20:53] <daftykins> in amazingstoke?
[20:53] <diddledan> yup
[20:54] <daftykins> :D
[20:55] <zmoylan-pi> celebrating 40 years of spam email? :-)


[00:07] <sigv> what does incoming to focal mean exactly in `rls-ff-incoming` tag? trying to figure out status of https://bugs.launchpad.net/ubuntu/+source/debmirror/+bug/1821251 considering the bug has been fixed in upstream (debian) repository.
[03:55] <eoli3n_> Hi
[03:56] <eoli3n_> since python2 is not supported anymore, how to deal with tools using as shebang /usr/bin/env python ?
[04:18] <Unit193> Either port to python3, or change that 'python' to 'python2' and ensure it's installed for the time being?
[04:24] <eoli3n_> Unit193 that's a set fo scripts for science, i didn't write them
[04:24] <eoli3n_> https://www.pci.uni-heidelberg.de/cms/mctdh.html
[04:24] <eoli3n_> i sent a mail
[04:24] <eoli3n_> Thanks Unit193
[10:54] <cjwatson> seb128: Re langpack-o-matic (from #launchpad), I don't *object* to removing eoan here but I'd rather that be a separate step taken by people who more normally maintain langpack stuff than me - I don't know what cleanup it requires
[10:55] <cjwatson> seb128: Are you able to merge this or should I poke sil2100?  I don't think there's an automatic mergebot here
[11:10] <mdeslaur> mwhudson: oh, sorry about that, I didn't notice the merge proposal
[11:11] <mwhudson> mdeslaur: it was hardly complicated :)
[11:11] <mdeslaur> hehe
[11:46] <seb128> cjwatson, hey, ack for 19.10, and I've merged the change now
[11:52] <cjwatson> seb128: Thanks
[11:53] <seb128> cjwatson, np, thank you for helping with the groovy translations opening!
[11:53] <cjwatson> seb128: So we haven't had a langpack yet of course, but I don't think that needs to block unhiding translations for groovy at this point - do you agree?
[11:53] <seb128> yes, agreed
[11:53] <cjwatson> seb128: Oh, maybe you already did so?  Somebody did
[11:54] <seb128> though the unhiding might be done already, I think Gunnar mentioned changing a setting yesterday
[11:54] <seb128> the contributor who was pinging around did talk to him as well it seems
[11:55] <cjwatson> Yeah, it all seems to be open now
[11:55] <cjwatson> So I think we're done here
[11:55] <seb128> \o/
[11:55] <seb128> thanks again!
[12:42] <rbasak> RAOF: vala is another GNOME MRE request. And it's special, so I have greater concern on this one that we make the right call. Details in https://bugs.launchpad.net/ubuntu/+source/vala/+bug/1891318/comments/2
[13:33] <kenvandine> I've was working on the libhinawa transtion, which i thought would be done this morning however libhinawa ended up on the dep list this morning with an unknown status
[13:33] <kenvandine> https://people.canonical.com/~ubuntu-archive/transitions/html/auto-libhinawa.html
[13:33] <kenvandine> can anyone help me understand what's up with it?
[13:35] <kenvandine> libhinawa has migrated to release, so just why it's still showing up.  Maybe just a tooling issue
[15:39] <mitya57> Hi! If a source is in main but one of its binaries is in universe, will it be automatically moved to main if I start depending on it from a main package? Or I should file a MIR for binary?
[15:40] <mitya57> (Dependency in question is python3-sphinx → python3-snowballstemmer, from src:snowball)
[15:46] <Laney> mitya57: no to both, but it will block in proposed until someone fixes it
[15:46] <Laney> but can be done without an MIR
[15:47] <mitya57> Laney: ack, so I should ping an archive admin?
[15:47] <Laney> is it already blocking?
[16:05] <mitya57> Laney: no, not uploaded yet
[16:05] <Laney> mitya57: ah, ok, ping me or someone when it is showing as blocking in update_excuses and it can be fixed then
[16:09] <mitya57> Ok, thanks
[17:04] <rafaeldtinoco> vorlon: just saw libopeniscsiusr being rejected for groovy. you want me to fix it to match sonames in Ubuntu and re-propose it do Debian or you prefer to give up on this merge for this cycle ?
[17:04] <rafaeldtinoco> i've done many tests to it, it looks good (apart from this new binary package and soname mismatch)
[17:10] <rafaeldtinoco> Ill give it a try with correct lib name
[17:56] <mitya57> LocutusOfBorg: https://tracker.debian.org/news/1170138/accepted-recommonmark-060ds-1-source-into-unstable/
[18:06] <LocutusOfBorg> mitya57, please upload also in Ubuntu, or sync whenever possible
[18:06] <mitya57> LocutusOfBorg: it will be auto-synced I guess
[18:07] <LocutusOfBorg> so, tomorrow I'll retry llvm_* stuff
[18:23] <vorlon> rafaeldtinoco: yeah, with a proper name for the runtime lib package, that should be fine to resubmit