[07:21] <howfixbadubuntu> howfixbadubuntu?
[07:21] <howfixbadubuntu> howfixbadubuntu?
[07:21] <howfixbadubuntu> howfixbadubuntu?
[07:22] <howfixbadubuntu> howfixbadubuntu?
[07:22] <howfixbadubuntu> plz?
[07:24] <gpocentek> Hobbsee: could you do the same on -motu ? :)
[07:26] <Hobbsee> gpocentek: for the love of anythign good, use !ops when wanting something from an op, like a kickban.  or /query me
[07:26]  * Hobbsee sees lots of red everywhere, and so has no idea if that's current, or was from hours ago
[07:28] <Mithrandir> Hobbsee: /lastlog -h is nice.
[07:28] <Hobbsee> Mithrandir: that's true, but i tend to read most of it anyway
[07:29]  * Hobbsee needs nalioth's irssi ban script
[07:37] <kraut> moin
[07:37] <Hobbsee> damned tor
[07:37] <Hobbsee> if he comes up anywhere else, call !ops
[07:40] <dholbach> Hobbsee: #ubuntu-bugs #ubuntu-desktop #ubuntu-mobile
[08:23] <Hobbsee> dholbach: only has ops in 1, no staffer to kline beyond that
[08:37] <dholbach> Hobbsee: OK
[11:42] <soren> @schedule Copenhagen
[11:42]  * soren kicks ubotu
[12:58] <dholbach> heya
[12:58] <Fujitsu> Evening.
[12:59] <TheMuso> Hey folks.
[12:59] <nxvl> good morning
[12:59] <dholbach> #startmeeting
[12:59] <MootBot> Meeting started at 12:59. The chair is dholbach.
[12:59] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[12:59]  * TheMuso will do minutes/announcements, if nobody else wants to.
[12:59] <dholbach> Welcome to the MOTU Meeting
[12:59] <dholbach> thanks a lot TheMuso
[12:59] <dholbach> we have an agenda at: https://wiki.ubuntu.com/MOTU/Meetings
[12:59] <dholbach> First up is persia
[13:00] <dholbach> [TOPIC] Hardy Freeze Schedule. Discussion to consider the merits of earlier UVFUniverse and NewPackagesFreezeUniverse to allow greater time for QA for the LTS.
[13:00] <MootBot> New Topic:  Hardy Freeze Schedule. Discussion to consider the merits of earlier UVFUniverse and NewPackagesFreezeUniverse to allow greater time for QA for the LTS.
[13:00] <dholbach> [LINK] https://wiki.ubuntu.com/HardyReleaseSchedule
[13:00] <MootBot> LINK received:  https://wiki.ubuntu.com/HardyReleaseSchedule
[13:00] <Hobbsee> morning.  now is the meeting?
[13:00] <ScottK> Hobbsee: Yes.
[13:00] <persia> In August (specifically the meeting of the 10th), we were discussing the possible freeze schedules for Hardy, in light of it being an LTS release.  We didn't gome to a conclusion, but some ideas were presented, including:
[13:00] <persia> 1) Not allowing any new packages
[13:01] <persia> 2) Matching UVF / NPUF with DIF
[13:01] <persia> 3) Requiring specs for everything
[13:01] <persia> I wanted to revisit this discussion as Hardy is opening, and build some consensus if we wanted to adjust any freeze dates for Universe, so these could be communicated when the official schedule was developed at UDS.
[13:02] <dholbach> a shame we don't have slangasek here
[13:02] <dholbach> let's try to get another few release team members
[13:02] <ScottK> I'd like to add manage a way to do Universe rebuilds and actually do them.
[13:02] <persia> Ah.  Found it.  Previous meeting log:
[13:02] <TheMuso> 1) I understand the meaning, but I am not for it, only because UbuntuStudio is likely to push new packages in, but at the same time, we will keep them updated.
[13:02] <ScottK> on a schedule.
[13:02] <Fujitsu> ScottK: Well, we're reliant on lucas for those.
[13:02] <persia> [LINK] https://wiki.ubuntu.com/MeetingLogs/MOTU/20070810
[13:02] <MootBot> LINK received:  https://wiki.ubuntu.com/MeetingLogs/MOTU/20070810
[13:03] <TheMuso> 2) Agreed.
[13:03] <TheMuso> 3) Not sure if we need to go that far.
[13:03] <persia> ScottK: That sounds really good, and fits well with the idea of earlier freezes for Universe.
[13:03] <ScottK> Fujitsu: Do they actually get done?  Maybe need one earlier?
[13:03] <Fujitsu> ScottK: We normally have one or two, fairly late.
[13:03] <persia> Fujitsu: Did we have one for gutsy?
[13:03] <dholbach> Ok, what is the problem we want to solve generally?
[13:03] <Fujitsu> persia: I believe so, but I don't think bugs were filed.
[13:04] <persia> The general issue is that if LTS is to be supported, it ought to be fairly QA clean to start: no FTBFS, no unmetdeps, no plain doesn't work, etc.
[13:04] <ScottK> dholbach: Have Universe not suck for LTS support.
[13:04] <TheMuso> persia: agreed.
[13:04] <persia> Fujitsu: Ah.  I didn't hear about it :(
[13:04] <TheMuso> persia: me neither
[13:04] <dholbach> persia, ScottK: I could think of other measures to get that done: QA lists announced regularly and early, good efforts coordinated with QA team members, etc
[13:05]  * ScottK adds "and have better communications about it".
[13:05] <dholbach> Is that part of the solution?
[13:05]  * Hobbsee ignores the meeting, and plays with red fire
[13:05] <persia> dholbach: Those are great measures, sure, and a good thing, but I think they are orthagonal to the question of whether we want to adjust freezes.
[13:06] <dholbach> persia: I think they are solutions to the problem.
[13:06]  * norsetto thinks that if he hears orthogonal again will join Hobbsee
[13:06] <dholbach> I'm not directly opposed to introducing freezes earlier, but to me these seem more obvious solutions
[13:06] <ScottK> Where I was leading up to is I think moving New Package Freeze back to Feature Freeze/UVF and doing a rebuild then is a good start to transition for development to fixing.
[13:06] <TheMuso> dholbach: But it gives us more time to clean up.
[13:07] <dholbach> early rebuilds sounds good
[13:07] <TheMuso> And get things in deacent shape.
[13:07] <persia> dholbach: OK.  I'm just wanting to re-raise the previous discussion, as there seemed to be interest, but no conclusion.  I'm not convinced about freeze dates, but didn't want it to be lost.  Other measures are useful, but separate.
[13:08] <dholbach> more and earlier freezes will put more pressure on the UVF team and I'm sure there will be stuff we want to get in before release
[13:08] <ScottK> I thought pitti's thread on revised freezed dates dumped all that into one date anyway?
[13:08] <persia> ScottK: As a UVF member from the last cycle, how much more load do you think that would be?
[13:09] <persia> ScottK: Pitti proposed that, but it's not represented on the current draft schedule.
[13:09] <ScottK> Depends on what we're talkign about.
[13:09] <ScottK> If it's move New package freeze to Feb 14, no big deal.
[13:09] <persia> ScottK; Moving UVF earlier = more pressure for UVF
[13:09] <ScottK> If it's much more than that, it'll get to be painful.
[13:10] <dholbach> ScottK: should we discuss raising the number of people in the -uvf team?
[13:10] <ScottK> I think we also ought to consider mapping out the endgame of the final freeze on more detail.
[13:10] <ScottK> dholbach: No, I don't think so.
[13:10] <TheMuso> ScottK: Seconded.
[13:10] <Fujitsu> ScottK: Yeah, rather than sort of... working it out as we go, a day in advance.
[13:10] <dholbach> ScottK: what does  mapping out the endgame of the final freeze on more detail  mean?
[13:10] <persia> Does anyone feel we need more that six weeks between upstream / feature / new freeze and beta?
[13:10] <TheMuso> persia: no
[13:11] <TheMuso> dholbach: As in, when does universe go into hard freeze.
[13:11] <ScottK> dholbach: This time I was working with the RM a day or two before to figure out when the last chance to upload for Gutsy would be.
[13:11] <dholbach> ScottK, TheMuso: ok thanks
[13:11] <ScottK> I think it was reasonably well communicated as it happened, so no last minute suprises, but there were last day or two suprsises.
[13:12] <dholbach> so the discussion right now is: move NPF from 28.2. to 14.2.?
[13:12] <dholbach> do you think that's going to help a lot with our QA efforts?
[13:12] <ScottK> That's the minimalist solution.
[13:12] <ScottK> I think it's a 2 part problem.
[13:12] <ScottK> That's one.
[13:12] <persia> I'm happy with no change or minimal change.  There doesn't seem to be the interest in freeze adjustment there was in August, so perhaps it was only a perceived issue, rather than a real issue.
[13:13] <ScottK> Part two is it seemed like there wasn't a big bug fix push until the very end, but of course that's often not visible, so I"m not sure.
[13:13] <dholbach> I'm happy to discuss tools and measures to make Universe QA better
[13:13] <persia> ScottK: I think part 2 is just us preparing a push plan earlier (and at least me reviewing the RC list prior to beta freeze)
[13:13] <Fujitsu> dholbach: Is there any timeline for universe rebuilds?
[13:13] <ScottK> persia: I think it might be a good idea to identify some bug fix internal milestones too
[13:14] <dholbach> Fujitsu: I don't know about it, but I can ask.
[13:14] <ScottK> persia: Along the lines of what you just said.
[13:14] <TheMuso> I think we need to pus the RC list more as well.
[13:14] <TheMuso> push
[13:14] <persia> ScottK: Agreed, but I don't think that's clearly dependent on freeze dates.
[13:14] <ScottK> TheMuso: Agreed.
[13:14] <dholbach> There's enough bugs in the bug tracker already - are we merely aiming for ftbfs/unmetdeps?
[13:14] <ScottK> persia: No, more of goals.
[13:14] <persia> TheMuso: Absolutely.  Debcheck as well.
[13:14] <TheMuso> persia: Whats debcheck?
[13:14] <ScottK> dholbach: If we had none of that at release, that'd be a huge victory.
[13:15] <persia> dholbach: No.  More than that, but it's not something we need to decide now, and it's also not something we need to stuff in the bugtracker.
[13:15] <dholbach> ok, let's try to come to a conclusion on freeze dates before we drift away
[13:15] <persia> TheMuso: http://alt.qeuni.net/~william/debcheck/
[13:15] <TheMuso> oh that
[13:15]  * Fujitsu should update that for hardy soon.
[13:16] <TheMuso> Is it in the TODO?
[13:16] <TheMuso> at the least, so its findable?
[13:16] <persia> Based on discussion, for my agenda item, I'd like to hear votes on whether anyone thinks it would be useful to adjust NewPackagesForUniverseFreeze to match UpstreamVersionFreeze.  I didn't hear any other proposals today.
[13:16] <ScottK> +1
[13:16] <dholbach> ok, let's vote
[13:16] <TheMuso> persia: I'd say yes, as it means we can do more bugfixing.
[13:16] <TheMuso> so +1
[13:16] <dholbach> [VOTE] NPF matching with UVF
[13:16] <MootBot> Please vote on:  NPF matching with UVF.
[13:16] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[13:16] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[13:17] <Fujitsu> +1
[13:17] <MootBot> +1 received from Fujitsu. 1 for, 0 against. 0 have abstained. Count is now 1
[13:17] <persia> +1
[13:17] <MootBot> +1 received from persia. 2 for, 0 against. 0 have abstained. Count is now 2
[13:17] <ScottK> +1
[13:17] <MootBot> +1 received from ScottK. 3 for, 0 against. 0 have abstained. Count is now 3
[13:17] <nxvl> +1
[13:17] <MootBot> +1 received from nxvl. 4 for, 0 against. 0 have abstained. Count is now 4
[13:17] <TheMuso> +1
[13:17] <MootBot> +1 received from TheMuso. 5 for, 0 against. 0 have abstained. Count is now 5
[13:17] <geser> +1
[13:17] <MootBot> +1 received from geser. 6 for, 0 against. 0 have abstained. Count is now 6
[13:17] <dholbach> 0
[13:17] <Fujitsu> dholbach: +0
[13:17] <dholbach> +0
[13:17] <MootBot> Abstention received from dholbach. 6 for, 0 against. 1 have abstained. Count is now 6
[13:17] <dholbach> Ok, I'll pass this on to the ubuntu-release team
[13:17] <persia> dholbach: Thanks.
[13:17] <dholbach> so it gets included in the UDS release scheduling session
[13:18] <dholbach> [TOPIC] Universe rebuilds
[13:18] <MootBot> Vote is in progress. Finishing now.
[13:18] <MootBot> Final result is 6 for, 0 against. 1 abstained. Total: 6
[13:18] <MootBot> New Topic:  Universe rebuilds
[13:18] <dholbach> ScottK: do you know who our contacts are for that?
[13:18] <ScottK> dholbach: No I don't, but Fujitsu was saying lucas earlier
[13:19] <dholbach> Ok, I'll make sure to get an answer from IS people on that and report on the list
[13:19] <dholbach> it'd be good to have results early
[13:19] <Fujitsu> dholbach: Thanks, yeah.
[13:19] <geser> lucas did the last rebuilds
[13:19] <persia> I'd like to see rebuilds at least after DIF and UVF.
[13:19] <persia> (if there are resources)
[13:19] <ScottK> Sounds good.
[13:19] <Fujitsu> And probably around beta too.
[13:19] <TheMuso> agreed.
[13:19] <dholbach> iwj's autopkgtest dug up some of them too
[13:19] <ScottK> Fujitsu: Yes.
[13:19] <dholbach> I'm not sure when it runs
[13:19] <persia> Fujitsu: That'd be nice, but there's not much time, and 10,000 packages
[13:20] <dholbach> [ACTION] dholbach to pass on NPF decision
[13:20] <MootBot> ACTION received:  dholbach to pass on NPF decision
[13:20] <dholbach> [ACTION] dholbach to ask IS people about universe rebuilds
[13:20] <MootBot> ACTION received:  dholbach to ask IS people about universe rebuilds
[13:20] <ScottK> persia: But if it's the 3rd one it shouldn't turn much up, so the results should be actionable.
[13:20] <dholbach> I'll also coordinate that with release managers to get it on the schedule
[13:20] <persia> ScottK: True.  Saves me running rebuilds locally :)
[13:21] <Fujitsu> If we can keep things sane early on, it'll be easier to manage at the end.
[13:21] <Fujitsu> Same with the RC bugs.
[13:21] <dholbach> can we move on to Universe QA efforts?
[13:21] <geser> what should happen (and when) to packages where don't manage to fix the FTBFS?
[13:21] <ScottK> It also saves us chasing Debian FTBFS bugs that don't affect us.
[13:21] <persia> ScottK: only to a certain degree: we still need to check dates on dependencies, rebuilds, and bug filing, but it makes it easier.
[13:21] <ScottK> geser: That's a good way to move into removal policy.
[13:21] <dholbach> [TOPIC] Universe QA measures for Hardy
[13:21] <MootBot> New Topic:  Universe QA measures for Hardy
[13:21] <Fujitsu> geser: Erm, you hit them harder to make it work :P
[13:22] <ScottK> dholbach: I'd say be aggressive about removals is one thing.
[13:22] <dholbach> so what's on our list apart from FTBFSes and unmetdeps?
[13:22] <ScottK> Expunging ancient cruft before release.
[13:22] <TheMuso> Deskto pfiles
[13:22] <TheMuso> desktop files even
[13:22] <dholbach> I'm wary about desktop files
[13:22] <persia> Is there anything special or new for Hardy?  If we have rebuilds, and advertise debcheck, RCbugs, automated FTBFS list, and the like, won't we be in good shape?
[13:23] <dholbach> seb128: ^ (desktop files)
[13:23] <ScottK> We managed to get openssl097 killed finally only on Monday before release.
[13:23] <persia> TheMuso: What about .desktop files?
[13:23] <seb128> dholbach: thanks, reading
[13:23] <dholbach> persia: people want menu entries for packages they install
[13:23] <TheMuso> dholbach was asking what else for Q
[13:23] <TheMuso> QA and they come up a lot in bugs
[13:23] <persia> ScottK: That's entirely my fault: I need to read my mail more.
[13:23] <seb128> stop adding desktop files until there is a proper way to translate those
[13:23] <ScottK> persia: But the key thing is we killed it.
[13:23] <seb128> there is a rosetta spec about that
[13:23] <TheMuso> I don't think its important, but thought it was worth mentioning
[13:23] <Fujitsu> Do we have a policy at all about removals?
[13:24] <persia> dholbach: Ah.  Yes.  I don't really consider that a QA issue, given the contention between poor translations & coverage.
[13:24] <TheMuso> seb128: Makes sense.
[13:24] <dholbach> ok good
[13:24] <dholbach> thanks seb128 :)
[13:24] <dholbach> ok, who will work on getting regular lists of things like unmetdeps? how do we maintain them?
[13:24] <Fujitsu> seb128: Has it been around for the requisite 2 years yet?
[13:24] <ScottK> Fujitsu: I think the defacto removal policy is file a bug if a package annoys you enough.
[13:24] <Fujitsu> dholbach: unmetdeps is done by debcheck.
[13:25] <seb128> Fujitsu: I don't understand your "requisite 2 years"
[13:25] <dholbach> Fujitsu: so the list is actively updated and we can work from using it?
[13:25] <persia> seb128: Is implementation in rosetta planned during the Hardy cycle?
[13:25] <Fujitsu> dholbach: Updated every six hours.
[13:25] <dholbach> Fujitsu: care to add to MOTU/TODO?
[13:25] <Fujitsu> dholbach: Sure.
[13:25] <dholbach> good
[13:25] <seb128> persia: no idea, but I would doubt of it, rosetta doesn't move really quickly
[13:25] <persia> seb128: That's about what I thought.
[13:25] <dholbach> one thing I'd really like to see for hardy is: more bugs tagged as bitesize and packaging
[13:26] <dholbach> we really want to have huge lists we can show to new contributors to get working on them
[13:26] <Fujitsu> seb128: Just noting that LP moves slower than a glacier often.
[13:26]  * TheMuso tends to fix such bugs if he comes accross them.
[13:26] <dholbach> does anybody have an idea, how we can get more of our universe bugs fixed?
[13:26] <persia> dholbach: I don't see that as a useful QA thing.  It's a good way to feed contributors, but there's heaps of bugs that got tagged, but not fixed for gutsy, which just indicates that people use tagging as a proxy for actually doing the work,.
[13:27] <TheMuso> persia: Hense my just fixing them.
[13:27] <persia> TheMuso: Right.
[13:27] <Hobbsee> dholbach: of course, it's hard to do QA when people keep requesting billions of new packages into the archive, or updated versions, just because they can
[13:27] <dholbach> I have lots of people who ask me which tasks they can start working on
[13:27] <dholbach> and lots of those easy bugs GOT fixed
[13:27] <dholbach> Hobbsee: those are not bitesize tasks
[13:28] <dholbach> or often enough are not
[13:28] <TheMuso> I generally trawl bug lists if I have time. So if thats the case, they get fixed.
[13:28] <persia> dholbach: For getting more bugs closed, there are two main things: firstly better coordination with the bug team, and secondly more focus on actually reviewing packages completely before uploading, rather than just fixing a bug.
[13:28] <Hobbsee> dholbach: sorry, related to earlier, with the NPF
[13:28] <dholbach> Hobbsee: ah ok
[13:28] <dholbach> persia: how would you like to see the coordination happening? whom to talk to? what do you expect of the team?
[13:29] <Fujitsu> persia: What do you mean by reviewing packages completely?
[13:29] <dholbach> Fujitsu: reviewing the bugs of a package you're about to upload
[13:29] <dholbach> the desktop team does that a lot
[13:29] <ScottK> dholbach: I'd suggest, in terms of actual work getting done, it's as, if not more, important to look into why MOTUs become less active and seeing what can be done to get ones that have gone inactive back.
[13:29] <dholbach> (at least looking at 'fix committed' bugs of the package, that have patches attached)
[13:29] <persia> dholbach: That's the issue.  I don't know.  I don't have the feeling that MOTU and bugsquad are working closely to close things, but I don't know how to fix that.  I do think tagging is best done by bugsquad (including MOTUs wearing a bugsquad hat)
[13:30] <Fujitsu> dholbach: Right, everybody should be doing that.
[13:30] <TheMuso> ScottK: aye
[13:30] <TheMuso> But mostly its life getting in the way
[13:30] <dholbach> ScottK: market research on inactive MOTUs is a good idea, but I feel we need  easy todo list items for new contributors to reach out to people who are not MOTUs yet too
[13:30] <persia> Fujitsu: Right.  Lots of people don't.  I read all my changelogs, and often see three updates by three different people in three days, all for simple things.
[13:30] <dholbach> persia: so you think that something like universe bug days would be a good measure?
[13:30] <ScottK> dholbach: I've noticed a lot of experience contributors drop off.
[13:31] <persia> dholbach: Recruiting is good, but not really a QA topic, no?  New contributors need to learn, and the orphan packages are not always the best place.
[13:32] <dholbach> I'm just saying that as we work on universe bugs (not all universe packages are orphaned ones), we should make sure to keep the list of easy and manageable tasks for new contributors growing
[13:32] <persia> dholbach: Universe bug days only work if someone runs them, and we've had no volunteers for all of Gutsy.  That might change, but I'd rather see someone who wants to tackle interaction with bugsquad come up with a solution, rather than imposing one.
[13:32] <dholbach> I think that's already going to help (as one part of the puzzle)
[13:32] <ScottK> dholbach: I don't think getting the easy bugs fixed is our major problem.  It's the hard one.
[13:32] <dholbach> persia: maybe we should discuss this on the bugsquad lists, if we can come up with some ideas for it
[13:33] <ScottK> one/ones
[13:33] <persia> As one part.  Not having lots of people reach for the MOTU bar, get it, and look for another challenge is the other side of the coin.
[13:33] <dholbach> ScottK: right, I said it's one part of the puzzle
[13:33] <persia> dholbach: Perhaps.  I don't yet have enough ideas to feed such a discussion well.
[13:33] <dholbach> right
[13:33] <ScottK> I just think it's an incredibly small one.
[13:33] <dholbach> it'll get them involved, but OK, let's leave the tagging discussion out for now
[13:34] <dholbach> any more measures we can think of
[13:34] <dholbach> ?
[13:34] <ScottK> Agressive removal policy
[13:34] <dholbach> we've had problems with that before and it should be discussed on ubuntu-devel@
[13:34] <persia> So, in summary, for QA, we'll focus on debcheck, RC bugs, and whole-package-maintenance.  We'll agressively remove cruft, and do a couple whole-archive rebuild runs.
[13:34] <dholbach> you always have people among the 8 million ubuntu users who still use the package you'Re removing
[13:34] <ScottK> Early look at transistions and seeing what can be done to accelerate them.
[13:34] <dholbach> all sounds good, yes
[13:35] <dholbach> can we transform some of them into action items?
[13:35] <ScottK> In the openssl097 case we only finished the transition because I accidentally noticed it was almost done.
[13:35] <persia> dholbach: There are lots of packages that are safe to remove with some investigation.  Old versions of libraries with 10 packages that need porting, debmake, etc.
[13:35] <dholbach> ScottK: nice :)
[13:35] <ScottK> We need a sustained look at that kind of thing.
[13:35] <geser> ScottK: I guess the archive admins won't be happpy to review the removed packages again for hardy+1 when they get synced again
[13:35] <persia> ScottK: Back in Just we ported 7 or 8 packages that hadn't been recompiled since Dapper :)
[13:35] <ScottK> geser: They can blacklist them.
[13:35] <persia> s/Just/June/
[13:36] <ScottK> persia: One of which is about to be subject to a removal request
[13:36] <persia> geser: The blacklist persists across cycles
[13:36] <geser> ScottK: so you want to remove packages for ever because we didn't fix a ftbfs?
[13:36] <dholbach> still, I'd like to have something like guidelines for removal discussed, "agressive removal" does not sound very inviting
[13:36] <ScottK> geser: I didn't say what the agressive removal policy should be.  Just that we should have one.
[13:37] <ScottK> dholbach: Agreed, it needs to be defined.
[13:37]  * persia proposes "oldlibs review & porting" in place of "agressive removal"
[13:37] <dholbach> who wants to start the discussion on ubuntu-devel?
[13:37] <ScottK> One other issue is supporting Dapper --> Gutsy upgrades.
[13:37] <persia> I don't think it needs ubuntu-devel discussion, except perhaps for leaf apps.  Most of the good targets are infrastructure, and not contentious.
[13:38] <persia> ScottK: Dapper -> Gutsy?  Dapper -> Hardy?
[13:38] <dholbach> persia: not for every package, but for something policy-like
[13:38] <ScottK> There are things that may need to be done with replaces/conflicts that we wouldn't normally think of
[13:38] <ScottK> Gutsy/Hardy yes
[13:38] <dholbach> ScottK: mvo will run test upgrades and file bugs for them
[13:38] <Fujitsu> dholbach: On universe too?
[13:38] <dholbach> Fujitsu: yes, AFAIK
[13:38] <Fujitsu> OK.
[13:38] <ScottK> dholbach: When will he start?
[13:38] <persia> dholbach: Do we need a policy?  If people have time, getting rid of oldlibs, etc. seems to be in line with NBS stuff.
[13:38] <dholbach> who will talk to him about that?
[13:39] <dholbach> persia: still, "agressive removal" should be defined somewhere
[13:39] <ScottK> dholbach: Agreed and probably not right now.
[13:39] <dholbach> ScottK: I think it runs in the datacenter every now and then
[13:39]  * persia doesn't really like the term "aggressive removal" anyway.
[13:39] <dholbach> ok, so who will talk to mvo about that?
[13:39] <dholbach> who will start the removal discussion?
[13:39] <ScottK> persia: Pick one.
[13:40] <ScottK> dholbach: I'll conspire with StevenK and try to come up with something to start the removal discussion.
[13:40] <dholbach> ScottK: thanks
[13:40] <dholbach> [ACTION] ScottK to start discussion about removal policy together with ScottK
[13:40] <MootBot> ACTION received:  ScottK to start discussion about removal policy together with ScottK
[13:40] <ajmitch> :)
[13:40] <dholbach> oops
[13:40] <ScottK> Heh.
[13:40] <ScottK> At least coordination will be easy.
[13:40] <dholbach> well the other S*K :)
[13:41] <dholbach> lalala
[13:41] <dholbach> ok, I'll talk to mvo
[13:41] <dholbach> [ACTION] dholbach to talk to mvo about upgrade tests including Universe
[13:41] <MootBot> ACTION received:  dholbach to talk to mvo about upgrade tests including Universe
[13:41]  * ajmitch will sit back on a beach & relax
[13:41] <dholbach> anything else before we move on?
[13:41] <TheMuso> dholbach: Is there going to be anything at UDS to do with MOTU? i.e do you have any specs planned?
[13:41] <ScottK> ajmitch is one of the people dholbach should work on remotivating.
[13:41] <persia> ajmitch: I thought you were going to update & revise the RC buglist?
[13:41] <dholbach> [TOPIC] UDS Specs
[13:41] <MootBot> New Topic:  UDS Specs
[13:41] <dholbach> ScottK: Ok, I'll try my best. :-)
[13:42] <ajmitch> persia: that too
[13:42] <ScottK> Who is going?
[13:42]  * TheMuso is.
[13:42] <persia> \o/
[13:42] <ajmitch> ScottK: I'm a lost cause, sorry
[13:42]  * ScottK will be there Sunday/Monday (probably)
[13:42] <dholbach> sistpoty and siretart, superm1 are
[13:42] <seb128> dholbach: you will make mvo cry ;-)
[13:42] <TheMuso> And at least one hopeful will also be there.
[13:42] <TheMuso> I'm mentoring him.
[13:42] <dholbach> and a couple of others I can't remember right now
[13:42] <siretart> sorry?
[13:42] <dholbach> siretart: you'll be at UDS
[13:42] <siretart> yes! :)
[13:43] <dholbach> things I wanted to do at UDS are:
[13:43] <siretart> and you can't imagine how much I'm looking forward to that
[13:43] <dholbach> review bzr best practices
[13:43] <dholbach> revisit packaging guide on the wiki
[13:43] <ScottK> dholbach: How does that relate to MOTU?
[13:43] <dholbach> revisit ubuntu process docs on the wiki
[13:43] <ScottK> The bzr thing?
[13:44] <dholbach> ScottK: it concerns ubuntu developers in general
[13:44]  * ScottK isn't sure how.
[13:44] <geser> ScottK: I guess for packaging with bzr
[13:44] <dholbach> exactly
[13:44]  * proppy wonders how expensive is paris-boston
[13:45]  * Hobbsee is not going to UDS
[13:45] <ajmitch> proppy: cheaper than flying from NZ
[13:45]  * norsetto tells proppy that the flight is nothing compared to the hotel .....
[13:45] <dholbach> any other business before we move on to fixed items?
[13:46] <dholbach> ok, next meeting time?
[13:46] <persia> +344 hours
[13:46] <ScottK> dholbach: Was that your personal list or list of stuff you think it MOTU related?
[13:46] <dholbach> persia: erm? :)
[13:46] <TheMuso> persia: smart alec.
[13:47] <persia> Fri, November 2nd, 20:00 UTC
[13:47] <geser> isn't that during UDS?
[13:47] <persia> TheMuso: It was handy from the 10th August meeting :)
[13:47] <dholbach> ScottK: oh, also revisit motu processes and see if we have any bottlenecks we should try to fix
[13:47] <persia> geser: Yes.
[13:47] <ajmitch> geser: that's happened before
[13:47] <TheMuso> geser: yes
[13:47] <TheMuso> that will be interesting for those of us at UDS.
[13:47] <TheMuso> We may not be able to attend.
[13:48] <TheMuso> depending on the goings on at the time.
[13:48] <dholbach> right
[13:48] <persia> Ah.  Right.  0:00 UTC?  4:00 UTC?
[13:48] <dholbach> maybe we should defer the discussion to the mailing list?
[13:48] <dholbach> and ask who would come to the meeting anyway (UDS or not)?
[13:49] <persia> I think we should schedule for a time convenient from UDS that doesn't conflict with the sessions.
[13:49] <persia> (on Friday)
[13:49] <dholbach> 20:00 UTC would be what? 16:00 local?
[13:49] <ScottK> dholbach: Yes
[13:49] <TheMuso> dholbach: I agree. Chances are we'll be so exhausted that we won't want to attend.
[13:49] <persia> Something like that.  Maybe a little later?
[13:49] <TheMuso> dholbach: Yes. 00 is also out of the question.
[13:50] <dholbach> I think that'll be the time the event closes
[13:50] <TheMuso> UTC that is
[13:50] <ajmitch> persia: later would not work
[13:50] <dholbach> not sure if that makes much sense :-/
[13:50] <TheMuso> dholbach: IT does to me.
[13:50] <ajmitch> once UDS is wrapped up, everyone goes out & gets drunk
[13:50]  * ScottK would say push it a week.
[13:50] <ajmitch> from what I've heard, at least :)
[13:50] <TheMuso> ScottK: Aye, I'm enclined to agree.
[13:50]  * persia defers
[13:51] <TheMuso> Let us get back, and recover. :)
[13:51] <Fujitsu> ScottK: Agreed.
[13:51] <persia> 9th November.  What time?
[13:51] <dholbach> I can't promise I can make it there, because I'll be at another conference, but that should be fine
[13:52] <dholbach> 13:00 UTC? (same time)
[13:52] <TheMuso> this was at 12:00
[13:52] <persia> (This started 12;00 UTC)
[13:52] <TheMuso> And afaik the mentoring meeting starts soon
[13:53] <dholbach> right, 12:00 UTC seems to be a good time for a bunch of us, it seems
[13:53]  * persia likes shifting times for people in other timezones, but finds 12:00 very convenient.
[13:53]  * geser can't before 14 UTC
[13:53] <persia> 20:00?
[13:53] <TheMuso> I could do 20:00
[13:53] <persia> (before that is too early here)
[13:53] <dholbach> (regarding the next agenda item: I'll figure something out regarding the Q&A sessions)
[13:54] <dholbach> oops
[13:54] <geser> 20 UTC WFM
[13:54] <Fujitsu> TheMuso: We'll be in AEDT by then, won't we?
[13:54] <persia> I thought Open Week would handle the Q&A session bits.
[13:54] <TheMuso> Fujitsu: Yes indeed.
[13:54] <persia> Fujitsu: Should be.
[13:54] <Fujitsu> So not too bad.
[13:54] <TheMuso> 7AM
[13:54] <dholbach> persia: right - just for the week after that
[13:54] <persia> Anyone bad for 9th November, 20:00 UTC?
[13:54] <Fujitsu> Yeah.
[13:55] <dholbach> sounds good
[13:55]  * ajmitch might even turn up
[13:56]  * persia proposes first REVU days as 6th November
[13:56]  * ajmitch should sleep now, really
[13:56] <persia> Umm.  5th (Monday)
[13:56] <TheMuso> persia: SOunds good.
[13:56] <TheMuso> Mind you, I get back that day, so I will probably be rather out to it.
[13:57] <persia> TheMuso: Understood.  I just can't imagine anyone wants to REVU at UDS, and the archive won't open much earlier.
[13:57] <TheMuso> oh of course
[13:57]  * TheMuso will likely do merges in any spare time he has at UDS anyway. :p
[13:57] <ScottK> One QA idea I just had is to mention that New packages can be backported to get early user exposure when there's still time to fix them.
[13:58] <TheMuso> ScottK: I like that.
[13:58]  * Fujitsu notes we have some 500 merges at this point.
[13:58] <persia> ScottK: Could you expand a little (not that there's really time)
[13:58] <ScottK> The backport is easy since there is absolutely no regression risk.
[13:58] <TheMuso> ScottK: I guess more help on the backports team would be desirable if thats the case?
[13:58]  * persia celebrates only 500 merges
[13:58] <dholbach> ok, let's move all the other discussions to #ubuntu-motu
[13:58] <ScottK> TheMuso: Definitely
[13:58] <dholbach> who will announce the dates on the mailing list?
[13:58] <Fujitsu> dholbach: Sounds good.
[13:58] <TheMuso> ok will do minutes and announcements and have them out in next 48 hours or so
[13:59] <dholbach> thanks a lot TheMuso
[13:59] <dholbach> #endmeeting
[13:59] <MootBot> Meeting finished at 13:59.
[13:59] <dholbach> Thanks everybody
[13:59] <TheMuso> np
[13:59] <persia> Thanks dholbach for chairing
[13:59] <dholbach> logs available at: http://kryten.incognitus.net/mootbot/meetings/
[13:59] <dholbach> shall we have a 5 minutes break before the next meeting?
[13:59] <dholbach> norsetto: ?
[13:59] <TheMuso> sounds good
[13:59] <norsetto> dholbach: sure
[13:59] <dholbach> great
[13:59] <dholbach> see you in 5
[14:05] <dholbach> OK
[14:05] <dholbach> Welcome everybody to the MOTU Mentoring meeting
[14:05] <dholbach> #startmeeting
[14:05] <MootBot> Meeting started at 14:05. The chair is dholbach.
[14:05] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[14:06] <dholbach> we're all here to discuss the future of the project that is described here: https://wiki.ubuntu.com/MOTU/Mentoring
[14:06] <dholbach> the aim of the project is to help getting one on one time with experienced developers to new contributors who just start to contribute
[14:07] <dholbach> by no means is this supposed the definite and only way to help new contributors
[14:07] <dholbach> it's meant to be a framework to help getting most out of that one on one time
[14:07]  * TheMuso is likely to only be around for another 20 mins or so.
[14:07] <dholbach> norsetto: was that OK as an introduction?
[14:07] <dholbach> norsetto: you had a few proposals or ideas to present
[14:08] <norsetto> dholbach: you doing great :-)
[14:08] <norsetto> first of all, I think we should make the point on the actual situation
[14:08]  * persia also has a proposal, for later
[14:08] <dholbach> [LINK] https://wiki.ubuntu.com/MOTU/Mentoring
[14:08] <MootBot> LINK received:  https://wiki.ubuntu.com/MOTU/Mentoring
[14:09] <norsetto> we have quite a number of participants, and the number is increasing faster and faster
[14:09] <norsetto> however, as a member of the reception, the feedback we have is very poor
[14:10] <norsetto> its very difficult to judge how many contributors are still active , to start with
[14:10] <TheMuso> From me at least, theres practically nothing to give, as my apprentices have a lot of real life stuff atm, so don't have a lot of time for MOTU.
[14:10] <TheMuso> But are doing bits here and there.
[14:10] <bluekuja> hi all
[14:11] <norsetto> themuso: but this is the point, perhaps you could do more with other contributors, as of now we know that you are fully occupied with your contributors and don't consider you for new ones
[14:12] <TheMuso> norsetto: Well, I am actually thinking of offering one or two more slots.
[14:12] <TheMuso> And my guys have already got a little experience.
[14:12] <TheMuso> Not ready to move on without me, but certainly have done their fair share of bits.
[14:13] <norsetto> anyhow, to make the point of the situation, we have 26 contributors now, adn 33 slots overall
[14:13] <dholbach> TheMuso: you raise an interesting point: when is the point where they can "move on on their own"
[14:13]  * persia asks to interject my proposal in response to that question
[14:13] <dholbach> what should the objective of the mentor be
[14:13] <dholbach> persia: fire away
[14:13] <TheMuso> I think its when the mentor thinks they are.
[14:13] <persia> Currently, we assign a contributor to a MOTU, and occasionally query both to see how the relationship is progressing.  I think it would be good to split this into two separate arrangements.
[14:13] <persia> The first would be for brand new people, and the mentor would help them decide what they want to do, how to get information to do it, and help develop a road plan for packaging-based Ubuntu membership.
[14:13] <persia> The second would be for established contributors who wish to become MOTU, and would involve suggestions on the preparation of their application, assistance in developing a roadmap for concentrations of interest, and help / recommendations to collect sponsors that match those interests.
[14:13] <persia> Ideally, I think the two mentors should be different individuals, and different from primary sponsors, but that may not be appropriate if the interests of the two are closely aligned.
[14:14] <persia> The idea being it's much easier to determine when someone is ready to move forward, and slot rotation happens faster (albeit for two classes of slots)
[14:15] <norsetto> persia: the first mentor you are talking about, how many MOTU do you think will be willing to do that?
[14:15] <TheMuso> I would be.
[14:15] <dholbach> me too
[14:16] <fernando> persia, sound like a motu graduation (level)? motu01 is a newest on motu progress? motu02 is a pre-motu?
[14:16] <dholbach> I get lots of mails asking for more information etc anyway :)
[14:16] <persia> norsetto: I think a lot of the people interested in sponsoring and mentoring would be happy to help someone move from basic patching through becoming an active contributor.  For those I was assigned, all made that transition, but none are ready to go further yet (although one is likely to try during Hardy)
[14:16] <norsetto> persia: the key is this: "help someone move from basic patching through becoming an active contributor"
[14:16] <persia> fernando: I'm rather thinking that the first represents help becoming a Contributor, if people need pointers to the docs, process guidance, etc.  The second is MOTU.
[14:17] <norsetto> 99% of the request we get are: "Hey, I want to help, give ve a mentor"
[14:17] <dholbach> persia has a point: I believe we lose many contributors between (what persia describes as) stage 1 and 2
[14:17] <persia> norsetto: Sure.  I just think there's a time gap, where people are contributing, and still need support from #ubuntu-motu and motu-mentors@, but don't need a dedicated mentor.
[14:17] <TheMuso> dholbach: agreed.
[14:17] <huats> persia: may be, it is possible to merge yo contributors idea with the membership one ?
[14:18] <dholbach> huats: can you explain?
[14:18] <persia> huats: I like to think that mentoring would help people who wished to do packaging contributions to become members if they were not already members, but I don't want to impose a hard like.
[14:18] <persia> s/like/link/
[14:18] <huats> I mean, the first stage that persia  exposed, can be seen as the membership acceptance...
[14:19] <huats> persia: it was just a suggestion that identify clearly the various stage with something already exists...
[14:19] <persia> huats: Right.  That's the basic idea.  People want to help.    At this point, they work at their own pace until they want more.  Moving straight to MOTU quickly isn't for everyone.
[14:20] <huats> the downside of the "merge" is that someone who is a member, is not necesseraly someone interested in packaging...
[14:21] <norsetto> perhaps we should change the name of the program then, its not MOTU mentoring we are talking about
[14:21] <dholbach> I think we'd only want to deal with people who express an interest in packaging or development work, or am I wrong?
[14:21] <persia> huats: Right.  That's why I don't want a hard link.  More that membership consists of lots of things, but packaging is one way to achieve it.  A mentor can help there, but the member is usually capable at that point to move forward.  Some time later, that person is ready to start becoming MOTU.
[14:21] <persia> dholbach: I completely agree that we should limit to packaging/development.
[14:22] <TheMuso> +1
[14:22] <bluekuja> dholbach, I totally agree
[14:22] <persia> norsetto: I like the name:  it's still MOTUs being the mentors, and about packaging/development.  It's just that there are two learning phases involved.
[14:22] <huats> dholbach: I totally agree too (+0.5 as I am just neither a member or a MOTU, just a MOTU hopefull)
[14:22] <persia> First "How can I help".  Second "I'm interested in problem foo, and want a generalised solution, but without upload, I can't do it.  How can I get upload rights?"
[14:22] <dholbach> huats: you will be soon enough :-)))
[14:23] <huats> But it is true, that for instance my self, I always like to figure out whereI stand... and everyone likes to see a progression...
[14:23] <norsetto> I must admit, I really don't see what the first phase has to do with packaging (even though I can see its merits)
[14:23] <dholbach> can we try to define objectives for those two stages? to define the role of the mentor?
[14:24] <huats> so the various stages can be a way to see that progression... Once you are after stage one, you have achieved something....
[14:24] <norsetto> its definetively something that the majority of the users are looking for
[14:24] <bluekuja> dholbach, would be nice to know which results should a mentor have after a mentoring period of work
[14:24] <persia> norsetto: I was initially given three people to mentor.  None of them were familiar with any of our tools or processes.  They now are.  One is working on things, and plans to become a MOTU in the future.  It was all packaging/bugfix stuff, but neither they nor I think they should have unreviewed upload yet.
[14:24] <dholbach> bluekuja: and the mentoree :)
[14:25] <bluekuja> dholbach, exactly :)
[14:25] <persia> bluekuja: Exactly.
[14:25] <dholbach> at the moment the separation of those stages is a bit undistinguished and nebulous to me
[14:26] <norsetto> persia: so, that would be like a 101 course? An introduction?
[14:26] <persia> dholbach: Stage 0: wants to help.  Stage 1: can do things, but wants / needs review & support.  Stage 2: MOTU
[14:26] <dholbach> ok, where's the thin line between 0 and 1?
[14:27] <persia> norsetto: Currently, my mentees needed a 101 course, and now there's a holding pattern.  Soon, they'll need definitions for becoming MOTU.
[14:27] <TheMuso> Sorry to run guys, but I must be off. Hope the rest of this meeting works out.
[14:27] <dholbach> thanks TheMuso, have a great rest of the day
[14:27] <persia> dholbach: Um.  Let me try again.  Stage 1 is the transition between someone who wants to help and someone who can help.  Stage 2 is the transition between someone who is helping and MOTU
[14:27] <norsetto> thx TheMuso
[14:27] <TheMuso> dholbach: Thanks. Its straight to bed for me. :p
[14:27] <fernando> maybe motus can "increase" points to new motu candidates (after XXX points it get motu). objectives don't sound good for me. a motu can help more with package instead devel.
[14:27] <dholbach> TheMuso: sleep tight :)
[14:27] <TheMuso> will do. :)
[14:27] <huats> TheMuso: sleep well
[14:28] <persia> fernando: I don't think it's about points.  More about trust and ability.
[14:28] <fernando> like a motu karma
[14:28] <dholbach> . o O { for example fernando should be a MOTU :-) }
[14:28] <huats> persia: I tend to agree with you...
[14:28] <bluekuja> dholbach, norsetto: one more thing. What are the requirements to ask for a mentor? I mean I wish to contribute but I've never tried to package anything. Can I ask to get a mentor assigned? or I have to read some guides/HOWTOs before?
[14:29]  * fernando is a newbie
[14:29] <bluekuja> dholbach, norsetto: In my opinion, ppl should have a small base of work before asking for a mentor
[14:29] <dholbach> bluekuja: I generally ask people to play with the tools a bit (like in MOTU/Recipes) and ask them for ideas what they'd like to work on
[14:29] <bluekuja> dholbach, nice starting point
[14:30] <norsetto> bluekuja: thats a crucial point to me, because we are now asking ppl to show some bug work they have done
[14:30] <bluekuja> norsetto, great. I think a mentoree should start doing something alone before asking for an official mentor
[14:30] <norsetto> bluekuja: exactly becuase its too easy now; you just pop in, hey nice, ask for a mentor and then forget about it
[14:30] <persia> Ah.  If we're asking to show work done, then I think there needs to be a new place, where brand new people can get basic help.  Someone to do personal one on one review of the first few debdiffs, and help understand the basic processes.
[14:31] <bluekuja> persia, I agree with you here
[14:31] <norsetto> persia: I'm not against one-on-one, its just that the amount of manpower required is too much
[14:31] <bluekuja> persia, there should be someone who starts reviewing first debdiffs/packages
[14:32] <dholbach> yes and asking for a mentor is asking for effort done by others (mailing information out, finding easy tasks, etc)
[14:32] <norsetto> persia, bluekuja: which is what the u-u-s is doing
[14:32] <bluekuja> and then move the contributor to a mentor
[14:32] <BugMaN> if i can do an opinion, stage 0 and stage 1 must have to different "mentoring program"
[14:32] <persia> norsetto: I think that's because we've defined it too broadly.  I've been basically inactive with my mentees aside from casual email since June, but neither of the two who haven't disappeared are ready yet.  I've been moonlighting with senior contributors who want to become MOTU, but that doesn't help your paperwork.
[14:33] <persia> BugMaN: Do we need a separate program?  That sounds like administration overhead to me (although if we've volunteers, I'm not opposed)
[14:33] <norsetto> persia: its not paperwork, is distributing the manpower where there is need
[14:33] <norsetto> persia: there is a tremendous waste right now
[14:33] <BugMaN> persia: not separate, but one thing is study how make packaging and one is make few bitesize bug
[14:34] <persia> norsetto: u-u-s isn't a good place to start.  How do people learn about U-U-S?  Without that bridge, we don't get enough in the pipeline.
[14:34] <huats> Just a side opinion, I think it is better to call them : stage1 and stage2... it is more appealing than 0 and 1...
[14:34] <dholbach> let's think a bit about getting people from stage 0 to stage 1 - I think it's good to assign mentors after first contributions
[14:34] <persia> norsetto: I agree about the waste.
[14:34] <norsetto> persia: do we have to force feed wiki pages in their throats?   For all those I took personally, we discussed things, and built understanding.  The wiki was part of that, but knowing which pages to read, and getting a second opinion on understanding was more important.
[14:35] <norsetto> dholbach: the problem is that the majority of ppl just don't read
[14:36] <huats> I do think that without that 1-on-1 relathionship it is quite hard to start....
[14:36] <persia> dholbach: That's emphatically not enough.  That doesn't help people who are willing, but not yet able.
[14:36] <dholbach> persia: what can we improve?
[14:36] <norsetto> dholbach: we can write as much as we want, we can't force ppl to read, and many just don't
[14:36] <bluekuja> dholbach, yes, should be clear that a contributor have to start with something like bitesize bugs (MOTU/Recipes) and then ask for a mentor. So would be nice to have that as necessary requisite
[14:36] <dholbach> (I agree with persia.)
[14:36] <huats> norsetto: you did a tremendous work with myself with the flightgear bug... way beyond what you should have.... but I am still there....
[14:37] <norsetto> huats: what you mean you still there?
[14:37] <persia> dholbach: I think we need two stages.  One to get people involved and to have a basic understanding, and a second later to help them develop a plan for long-term contribution.
[14:37] <huats> norsetto: I mean I haven't quit...
[14:37] <dholbach> is there something we can do to streamline that process?
[14:37] <huats> norsetto: thanks to your patience, advices....
[14:37] <norsetto> huats: I didn't manage to scare you off eh? ;-)
[14:38] <huats> norsetto: well, you almost did when you metionned that you know my place, but not yet :-)
[14:38] <persia> dholbach: norsetto: highvoltage: could you share a little about the current workflow for registration?  I'm curious how separating stages might interface with that.
[14:39] <norsetto> persia: highvoltage is not here, he had a personal matter to attend unfortunately
[14:39] <dholbach> persia: people ask "can I get a mentor?" we ask them "what would you like to work on? did you read ....?", they reply and we assign somebody who might fit
[14:39] <persia> norsetto: Ah.  nick present, so gets included :)
[14:39] <norsetto> persia: well, he mentioned using his mobile :-)
[14:39] <dholbach> norsetto seems to have started for first contributions already
[14:39] <persia> dholbach: Thanks.  That sounds like too much work to me.
[14:40] <norsetto> persia: it is, but the problem is really a lot of people asking without a real interest
[14:41] <norsetto> persia; just because they can
[14:41] <persia> For a two-stage approach, I'd suggest looking at the LP page for the querant, and if they are already contributing, send them to a Mentor with a note that they're active.  If they aren't, send them to a Mentor with a note that they are new.  Expect the MOTU to help them with guidance, but introduce to the team for help with actual work.
[14:42] <norsetto> persia: let me repeat .... 99% of the requesters have not done anything ... nothing
[14:42] <persia> norsetto: If I was assigned someone, and that person didn't respond to emails / IRC for a bit, I'd notify you that the person disappeared.  I expect other mentors would do the same.  Why not share the workload?
[14:42] <huats> may be it could be a good starting point that people interested in stage0 have to start with bug where someone has offer to mentor on that bug....
[14:42] <persia> norsetto: That's fine.  None of the mentees I was initially assigned had done anything :)
[14:43] <persia> huats: True, but I think it usually takes 3-5 bugs to feel comfortable.
[14:43] <norsetto> persia: I can't name names, but the feedback we are geeting is really poor, in some cases non-existant
[14:43] <BugMaN> persia: but set time limit to do something?
[14:43] <persia> norsetto: Ah.  That's not ideal :(
[14:43] <huats> so may be the first stage could be start with 1 bug with a mentor attached to this bug, and than a couple more with a mentor around....
[14:44] <norsetto> huats: thats a good point, I think we should push MOTUs to mentor bugs. now that we can
[14:44] <persia> BugMaN: That sounds good.  Perhaps a fairly short default period, with a request to registration required for extension?
[14:44] <norsetto> oh well, I did it even if I wasn't a MOTU
[14:45] <huats> persia: the first stage should not be a "long" one.... It could be seen as a way that people express their interest and familiarize with the tools/procedures....
[14:45] <persia> I'd even recommend senior contributors to mentor bugs, if they know a solution, but are working on other things / don't have time.
[14:46] <norsetto> persia: definetively
[14:46] <persia> huats: Right.  I think most interested contributors could be conversant in a couple weeks.
[14:46] <persia> huats: Further, I'd suggest the second stage need not be much longer - more consisting of making sure the person has an agenda for contributions, and knows the right people with whom to coordinate for implementation.
[14:47] <dholbach> persia: who would set the agenda? I've been asked more times than I can count "what can I do now?"
[14:47] <persia> norsetto: Such a split should give you more slots (because of higher turnover), reducing your pain, but I'm not looking at your queue.
[14:47] <norsetto> its still not clear to me the practical side of the implementation
[14:48] <persia> dholbach: I've been asked that a lot.  Generally I encourage the contributor to decide that.  Usually the process involves a couple weeks, and looking at what needs doing, combined with personal interests.
[14:48] <huats> dholbach: may be the generalization of the weeklyTODO can help ?
[14:48] <huats> to fix the agenda I mean...
[14:49] <dholbach> huats: we use something like that for MOTU already
[14:49] <norsetto> huats: thats definetively needed, dholbach is quite aware of that
[14:49] <persia> For example, I often suggest collaboration with one of the specialised teams (-desktop, -server, -studio, etc.), combined with a specialisation on something (security, debian collaboration, QA, etc.)
[14:49] <dholbach> https://wiki.ubuntu.com/MOTU/TODO/Weekly
[14:49] <huats> norsetto: I know he is aware....
[14:50] <huats> dholbach: I was meaning to get this kind of TODO for newcomers....
[14:50] <norsetto> huats: this is what we give to newcomers
[14:50] <dholbach> huats: it already contains bitesize and packaging tasks
[14:50] <huats> oh
[14:50] <huats> oups
[14:51] <huats> I opened it after writing that ...
[14:51] <norsetto> back to the two stage approach, how do you guys think it should be implemented, in practice?
[14:53] <norsetto> do we have to expand the role of the Reception? Do we need to have two different lists of mentors/contributors? This seems like increasing the overhead....
[14:53] <persia> norsetto: I'd suggest pushing prospective mentees to mentors on an as-available slot basis, and making clear the short-term goals for the relationship.  Some mentors may ask for mentees with for the second stage only, and some for only the first stage, depending on their own interests.
[14:54] <persia> stage determination could be determined from # of sponsored uploads.  <5 is first stage, >30 is second stage.  In between should be referred to #ubuntu-motu and motu-mentors@
[14:55] <persia> (for arbitratry values of 5 and 30)
[14:55] <norsetto> persia: I don't mind the idea, I'm just worried about the availability of people to be mentors for the first stage, its already very difficult for the second
[14:55] <huats> so if I follow your idea, someone with more than 30 has finished his second stage ?
[14:55] <huats> but after that it is MOTUship ?
[14:56] <dholbach> I will have to leave in 3 minutes
[14:56] <persia> norsetto: I don't think all the current mentees are really second-stage material.  I especially think the discussion on https://wiki.ubuntu.com/MOTU/Mentoring encourages first-stage applicants.
[14:56] <norsetto> persia, huats: to me, its more a question of the mentor deciding
[14:56] <dholbach> where do we go from here?
[14:56] <huats> From my point of view and like you mention, MOTUship is not a quantity stuff....
[14:57] <persia> huats: For arbitrary "30".  It's not a fixed number.  It's really a matter of whether the person is willing to make the committment to maintain universe, and take on the additional responsibilities.
[14:57] <norsetto> dholbach: we can adjourn here, and continue on another occasion, the discussion is interesting
[14:57] <dholbach> it's great
[14:57] <dholbach> it'd benefit from somebody listing the ideas we had during it
[14:57] <huats> it is really a great discussion I think
[14:58] <dholbach> shall we have another meeting or do this on the motu mentoring list or on the wiki?
[14:58] <norsetto> I'm pretty neutral on any of the 3
[14:58] <dholbach> hm
[14:58] <norsetto> perhaps less so on the wiki
[14:59] <persia> I think informal discussion for some time, followed by another meeting to verify consensus would be ideal.
[14:59] <dholbach> ok, let's try to sum up the ideas on http://wiki.ubuntu.com/MOTU/Mentoring/Future before we do anything else
[14:59]  * persia is not fond of using the wiki for initial draft thoughts
[14:59] <norsetto> persia: yes, I think we should make a summary and submit it to motu-mentors
[15:00] <dholbach> I just think it'd be good to aggregate the ideas in a better place than a meeting log
[15:00] <persia> norsetto: Completely agreed.  Do you want to do minutes?
[15:00] <dholbach> #endmeeting
[15:00] <MootBot> Meeting finished at 15:00.
[15:00] <dholbach>  Logs available at http://kryten.incognitus.net/mootbot/meetings/
[15:00] <persia> dholbach: I agree, but think the mailing list is more appropriate for draft thoughts: people search the wiki.
[15:00] <huats> dholbach, persia  and norsetto  thanks for this various very interesting ideas....
[15:01] <dholbach> yeah, thanks everybody
[15:01] <dholbach> persia: ok, that's good too
[15:01] <norsetto> ok, lets go to the classroom :-)
[15:01] <norsetto> persia: can we do it double handed?
[15:01] <persia> norsetto: Sure.  Catch me in about 90 minutes?
[15:02] <norsetto> persia: perhaps you can draft something, I'll have a look, and then we send it?
[15:02] <huats> norsetto: classroom ?
[15:02] <huats> I forgot that too ?
[15:02] <norsetto> huats: #ubuntu-classroom
[15:02] <persia> norsetto: Sounds good.  I'll try to get something out tonight, but it may be morning.
[15:02] <dholbach> you guys rock
[15:02]  * persia points to #ubuntu-motu for further discussion on mentoring for interested parties:
[15:02]  * dholbach hugs y'all
[15:02] <norsetto> persia: sure, no need to hurry, lets do something proper
[15:02] <huats> I've seen daniel announces in -motu for th QA


[07:35] <RAOF> Saviq: oh, by the way, I worked out (half of) why you need the aufs `sed`dery in your local spread thing.
[07:37] <RAOF> If the lxd storage is on zfs, then it lacks a feature needed for schroot to use an overlay filesystem.
[07:38] <Saviq> Ah, so that's the same you encountered
[07:39] <RAOF> LXD seems to no longer set up a zfs loop mount by default, so CI works and my more recent setup works
[07:40] <RAOF> There's ways to get schroot to not try overlay filesystems, and it's not useful in ephemeral LXD containers.
[07:40] <Saviq> I'm actually on ZFS root, do that's what's used, but same problem
[08:03] <Saviq> Could be simply --type=directory for mk-sbuild?
[08:06] <Saviq> Oh here's a new one from the lab:
[08:06] <Saviq> > Mir fatal error: mir::graphics::wayland::Display not initialized
 "Could be simply --type=..." <- Nope.
[10:27] <Saviq> > <@saviq:matrix.org> Oh here's a new one from the lab:
[10:27] <Saviq> > > Mir fatal error: mir::graphics::wayland::Display not initialized
[10:27] <Saviq> Hmm this is happening consistently now on particular HW in the lab, but I can't see anything that's changed software-wise.
[10:28] <alan_g[m]> If you have logs I'll take a look once I'm out of current rabbithole
[10:34] <Saviq> Failing:
[10:34] <Saviq> http://<IP_ADDRESS>:8080/job/cert-focal-mir-smoke-mir-kiosk-edge-intel-gfx/774/consoleText
[10:34] <Saviq> Last success on this hardware:
[10:34] <Saviq> http://<IP_ADDRESS>:8080/job/cert-focal-mir-smoke-mir-kiosk-edge-intel-gfx/763/consoleText
[10:35] <Saviq> But downgrading mir* to the versions from the successful one doesn't solve.
[10:35] <Saviq> Also another (non-nested) test run on the same hardware is fine:
[10:35] <Saviq> http://<IP_ADDRESS>:8080/job/cert-focal-mir-smoke-mir-test-tools-edge-intel-gfx/708/console
[10:36] <Saviq> So yeah. So far no clue.
[10:37] <Saviq> I was able to reproduce, and non-nested failed as well. Only difference at that point was mir-kiosk being installed (but not running). Next I'll start from the working non-nested setup and see if/how I can get to a broken state
[10:37] <Saviq> But that's in ~2h
[12:29] <Saviq> Oh I see, it's because mir-kiosk dies
[12:30] <Saviq> That "Display not initialized" is b/c the tests don't get access to the device
[16:16] <Saviq> OK. This is GAH. Based on my findings, the offending mir-kiosk changes are… drumroll…
[16:16] <Saviq> https://github.com/MirServer/mir/compare/0593df6a8f...987869cbef
[16:17] <Saviq> 🤦
[16:26] <Saviq> Everything else is the same between the two snaps. The dependencies Mir built with. The things packaged into the snaps. Yet, one reliably (4 tries now) fails, the other, I've not seen fail yet.
[16:34] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq assigned AlanGriffiths to [issue #2632](https://github.com/MirServer/mir/issues/2632): Miriway frequently crashes to GDM after exiting powersave
[16:34] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq unassigned RAOF from [issue #2632](https://github.com/MirServer/mir/issues/2632): Miriway frequently crashes to GDM after exiting powersave
[17:10] <sophie-w> Why am I getting std::exception::what: Failed to find any platforms for current system when trying to run a simple Mir-based server? I have mir-platform-graphics-x installed.
[17:11] <sophie-w> I feel like this should be super obvious
[17:12] <alan_g[m]> The rest of the log should show which platforms are tried and (hopefully) why they aren't usable
[17:15]  * sophie-w sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/d58cc978c66c7d3de02a0c9ef59cb25280bc674a
[17:16] <sophie-w> $ ls /usr/lib/x86_64-linux-gnu/mir/server-platform/
[17:16] <sophie-w> graphics-gbm-kms.so.19  graphics-wayland.so.19  input-evdev.so.8  server-x11.so.19
[17:16] <alan_g[m]> "<information> mirserver: Found graphics driver: mir:x11 (version 2.7.0) Support priority: 0" - no DISPLAY variable?
[17:17] <sophie-w> wtf
[17:17] <sophie-w> ok fixed it
[17:18] <sophie-w> DISPLAY was set to wayland-1
[17:18] <alan_g[m]> Ah! Mate likes to do that for weird reasons
[17:18] <Saviq> "weird"
[17:19] <sophie-w> It seems to happen only when right-clicking in thunar and clicking "open terminal here"
[17:19] <alan_g[m]> So XFCE does it too?
[17:19] <sophie-w> And thunar is only opened when I open the downloads directory from FF
[17:20] <sophie-w> Apparently


[05:28] <DHR> Does it make sense to respin Mythbuntu now that the "MythTV Frontend does not work with RADEON DRI" problem mentioned in the 9.04 release notes has been fixed by updates?
[05:42] <tgm4883> DHR, no.  We couldn't even if we wanted to
[05:42] <tgm4883> just install and do the update
[05:42] <tgm4883> s
[05:43] <DHR> does the bug not interfere with installation?  Also, if it is being used as a liveCD (diskless), the bug surely hits.  Or do I misunderstand?
[05:44] <DHR> "couldn't" is a convincing argument, or course.
[05:44] <DHR> s/or/of/
[05:45] <tgm4883> well the frontend doesn't work, that doesn't mean that the desktop environment doesn't work
[05:45] <tgm4883> so you can still install and update
[05:45] <tgm4883> using just the live disk isn't going to work, but that isn't really a diskless setup.
[05:46] <tgm4883> the live disk is more for testing hardware and such, in which case you can install the fix in the live env and restart X
[05:46] <tgm4883> but since we can't respin anyway, it's kinda moot
[05:47] <DHR> Interesting that you cannot respin.  Is that because the fundamentals are built upstream (Ubuntu)?
[05:47] <tgm4883> DHR, no, thats because Canonical builds the disks for us
[05:47] <tgm4883> and they won't respin old disks like that
[05:48] <DHR> tgm4883: thanks for your helpful answers.
[05:48] <tgm4883> DHR, np
[05:49] <DHR> I'll go see how the live cd works on my old Fedora Core 5 Myth Box.
[09:28] <bruckout22> Anyone has mythbuntu setup using viewsat
[10:17] <Guest52004> hello all, im having some trouble when mounting my usb external harddrive over the network. Im using nfs, whenever i type on the client pc: " sudo mount <IP_ADDRESS>:/media/video /home/bsusa/Videos "  i get mount.nfs: access denied by server while mounting <IP_ADDRESS>:/media/video. Any suggestions please?
[10:22] <hads> I suggest access is denied by the server
[10:26] <Guest52004> when i mount a folder on the internal Hardrive it mounts ok
[10:26] <Guest52004> im not sure whats causing it
[10:37] <hads> Permissions?
[14:23] <Essobi> Morning.
[18:03] <weiser> Hey, anybody having some experince with Freebox recorder, I want to use it for other streams, if it is possible?
[18:07] <weiser> The stream I want to use it on is: #EXTINF:123,Sample title
[18:07] <weiser> ups this one: http://www.dr.dk/betalab/Projekter/H.264.htm
[19:31] <Seeker`> what is the best way to get mythtv to play vob/ifo files?
[20:19] <TazgodX> im having several problems. first mplayer is causing some of my stored videos to go out of sync with audio and video. VLC seems to play just fine. but i can't get VLC to work, it won't open full screen, and it won't accept any keyboard input.
[20:19] <TazgodX> next the internal player for DVDs won't work either. but playing through xine works, again, no keyboard input seems to work
[21:36] <TazgodX> i finally got my internal player working, and got the keybindings how i wanted it...somewhat. new problem, when i go into video manager, it always has the add imdb # up.
[23:30] <Seeker`> foxbuntu: I went with a Q6700 in the end


[00:43] <ahayzen> Hey, any SDK guys around?
[07:02] <bzoltan> ping zsombi
[07:02] <zsombi> bzoltan: pong
[07:03] <bzoltan> zsombi: my client is not happy with SSL on this network, so I use the web client
[07:03] <zsombi> bzoltan: ok :)
[07:04] <bzoltan> zsombi:  how is the IMA bug?
[07:05] <bzoltan> ping zbenjamin
[07:05] <zsombi> bzoltan: I found a small difference in Qt5.2 which may cause the touch event not being translated onto mouse event, tried to ask dandrader for that, no response so far
[07:22] <zbenjamin> bzoltan: pong
[07:54] <dholbach> good morning
[07:54] <justCarakas> good morning :)
[09:01] <JamesTait> Good morning all; happy Chocolate Caramel Day! :-D
[09:29] <alaak> Hi. Can someone please tell me how to position two items in a ListView delegate with one item on the left border and one on the right. Unfortunately I can not use anchors inside a ListView delegate. :(
[09:31] <gcollura> alaak, use a listitem or an item for a delegate and then anchor its contents to the delegate
[10:00] <alaak> Hm. When I use an Item, the content of the ListView is displayed over each other (not one by one) and ListItem from Ubuntu.Components.ListItems is no usable component.
[10:03] <gcollura> weird, let me see your code if you wish, I may help you
[10:05] <alaak> Ok. Mom. I probably should use the Pastebin, correct?
[10:05] <gcollura> paste.ubuntu.com is ok
[10:08] <alaak> http://pastebin.ubuntu.com/7118975/
[10:09] <alaak> thanks. I hope this works.
[10:09] <gcollura> ok don't use Component when you specify the delegate directly in the ListView {}
[10:10] <gcollura> and set a Item height too
[10:10] <dholbach> dpm, maybe we can use one of the next days' standup to look into fleshing out the tutorial instructions a little bit
[10:10] <dholbach> dpm, basically "how do I run the 'hands-on' part of the app dev school event?"
[10:10] <dpm> dholbach, yes, good idea
[10:11] <dholbach> I'll note it down
[10:12] <alaak> Thanks. Looks better now. Not perfect yet but at least some improvement. I'll try the anchors now.
[10:13] <gcollura> alaak, those anchors shouldn't give problems as far as I can see
[10:17] <alaak> Well at least one problem. I would like to position the image to the right, but using anchors.right: parent.right removes my image completely.
[10:51] <om26er> popey, hey! so is some help still needed on autopilot test failures ?
[11:55] <popey> om26er: only sudoku has a test failure, could you take a look?
[11:55] <popey> om26er: the others are fixed now I think.
[11:55] <popey> (although I see calendar has "flaky" tests) ☹
[11:56] <om26er> popey, in calendar case thats the app crashing, so nothing we can do
[11:56] <om26er> popey, the failing test for sudoku is that what's on the mailing list ?
[11:57] <popey> om26er: the one about the "about" tab.
[11:57] <popey> we fixed the issue with the profile name last night
[11:57] <popey> huh.. http://ci.ubuntu.com/smokeng/trusty/touch/mako/246:20140319.2:20140304/7259/sudoku_app/
[11:57] <popey> 100%
[11:58] <popey> confused
[12:02] <om26er> popey, so the current bug is bug 1285279 ?
[12:02] <ubot2> Launchpad bug 1285279 in Sudoku App "Autopilot test failure" [Undecided,Fix committed] https://launchpad.net/bugs/1285279
[12:09] <dholbach> hey jdstrand, I had a brief look at bug 1292418 again - I'd be happy to do a backport
[12:09] <ubot2> Launchpad bug 1292418 in Canonical Click Reviewers tools "Test suite fails in saucy" [Undecided,Incomplete] https://launchpad.net/bugs/1292418
[12:10] <popey> om26er: no, that's fixed I believe.
[12:10] <popey> om26er: I'm confused. hang on
[12:14] <om26er> popey, btw that 'about' tab bug, that has got to be an issue in the ui-toolkit helper that switches the tab OR the app actually crashed and autopilot didn't know if it did
[12:28] <mihir> balloons, why  all Jenkins are getting failed on calendar app , any idea?
[12:36] <ahayzen> t1mp, ping
[12:43] <t1mp> ahayzen: hello
[12:43] <ahayzen> t1mp, i have been trying to move our toolbar component to use the Panel component...
[12:43] <ahayzen> t1mp, it has been going well but i have got stuck on mouse events
[12:44] <ahayzen> t1mp, i try the example at https://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.Panel/ which states to add signal clicked() to the object but tht doesn't appear to work for me
[12:44] <ahayzen> t1mp, basically wht i'm asking is should the clicked() signal be working?
[12:45] <t1mp> ahayzen: I'm in a meeting for 10 more minutes, I'll check after that
[12:45] <ahayzen> t1mp, thanks I have a basic branch here (basically a copy of the example) lp:~andrew-hayzen/+junk/test-panel-clicked
[12:53] <mihir> balloons, getting this console output , http://paste.ubuntu.com/7119626/
[12:54] <t1mp> ahayzen: I'm back
[12:55] <ahayzen> t1mp, cool :)
[12:55] <t1mp> ahayzen: the online docs are not up-to-date I see
[12:55] <t1mp> mhall119: ^
[12:55] <ahayzen> t1mp, ah
[12:59] <t1mp> ahayzen: the item needs to have a trigger() function, not clicked
[12:59] <t1mp> ahayzen: I'll check your code
[12:59] <ahayzen> t1mp, thanks
[13:01] <t1mp> ahayzen: this works: http://pastebin.ubuntu.com/7119665/
[13:01] <t1mp> mhall119: ^we need to update the online docs, the docs were fixed in december
[13:02] <ahayzen> t1mp, ok thanks :) and should it be on saucy+trusty?
[13:02] <ahayzen> t1mp, or just trusty?
[13:02] <t1mp> ahayzen: trusty yes, saucy I don't know. anything with uitk r879 or greater
[13:02] <ahayzen> t1mp, ok thanks
[13:03] <ahayzen> t1mp, and will/are there be docs examples for the bottom edge animations? or is tht still WIP
[13:05] <ahayzen> t1mp, tht works \o/ thanks
[13:18] <boiko> elopio: so, I managed to reproduce the original problem on the device, trying to get a definitive fix for that now
[13:21] <alaak> greetings
[13:21] <t1mp> ahayzen: basically you will have to do it with the Panel
[13:22] <ahayzen> t1mp, how will the two stage swipe work that we have... will we have two panels or one?
[13:22] <t1mp> ahayzen: the bottom edge is completely free for app developers to do what they want, I recommend to use the Panel for that
[13:23] <t1mp> ahayzen: so "advanced" behaviors are not in UITK yet
[13:23] <t1mp> ahayzen: I think they will be there eventually if certain patterns turn out to be used by several apps
[13:23] <ahayzen> t1mp, ok :) i guess it'll become clearer as we start working on it :)
[13:24] <t1mp> ahayzen: yes.
[13:24] <t1mp> ahayzen: there is an upcoming MR for UITK that adds a bool to MainView to disable the toolbar so that it will not conflict with the Panel
[13:24] <t1mp> ahayzen: but we are waiting for a stable image with Qt 5.2 before we merge new stuff in UITK, so it will probably come next week
[13:25] <ahayzen> t1mp, i keep getting this ...
[13:25] <ahayzen> t1mp, DEPRECATED use of Panel.opened property. This property will be made read-only,
[13:25] <ahayzen>                 please use the opened property of the Page tools or use Panel.open() and Panel.close().
[13:25] <ahayzen> <Unknown File>: QML StateGroup: Can't apply a state change as part of a state definition.
[13:25] <ahayzen> t1mp, i don't think it is me... i'm just called Panel.open() or Panel.close()
[13:30] <t1mp> ahayzen: weird
[13:30] <t1mp> ahayzen: can you push the source? I'll pull again and see what I get
[13:31] <ahayzen> t1mp, it only happens in one case not quite narrowed it down
[13:31] <ahayzen> t1mp, it is in this branch lp:~andrew-hayzen/music-app/toolbar-as-panel
[13:31] <ahayzen> t1mp, somewhere when hiding the now playing page
[13:34] <t1mp> ahayzen: how do you hide/show the now playing page?
[13:34] <t1mp> in the GUI I mean
[13:35] <ahayzen> t1mp, hit Esc or hit the arrow at the top
[13:35] <ahayzen> t1mp, its a bit weird i'm gonna have a play about...
[13:36] <ahayzen> t1mp, oh no
[13:36] <ahayzen> t1mp, clicking the play/pause button in the now playing toolbar causes it?!
[13:37] <ahayzen> t1mp, infact clicking on the actual track on the queue....
[13:37] <boiko> elopio: so, the root cause of the problem was not the model reloading (although that needs optimization for sure)
[13:39] <boiko> elopio: it is the fact that the messages were new, and thus they are marked as read, which calls the history daemon to update the events and generate some item updated signals
[13:39] <boiko> elopio: and when those signals come back to the model, the items get reloaded (that explains why my original fix didn't solve the problem)
[13:40] <t1mp> ahayzen: I see the warning, but not what causes it. It might be a bug in the toolkit
[13:41] <ahayzen> t1mp, i'm wondering if calling Panel.open() when it is already open or something odd like tht
[13:41] <ahayzen> t1mp, just trying to narrow down
[13:41] <t1mp> ahayzen: I have to work on something else now, but if you manage to narrow it down, please report a bug and assign tpeeters (me)
[13:41] <ahayzen> t1mp, will do thanks :)
[14:00] <boiko> elopio: found the correct fix now, I will submit an MR soon
[14:02] <mhall119> t1mp: that was the sdk-1.0 docs
[14:03] <mhall119> t1mp: is https://developer.ubuntu.com/api/qml/development/Ubuntu.Components.Panel/ correct?
[14:06] <ahayzen> mhall119, tht looks like it :)
[14:07] <mhall119> ahayzen: so for future reference, don't use the sdk-1.0 docs anymore, use sdk-14.04
[14:07] <ahayzen> mhall119, noted thanks
[14:12] <t1mp> mhall119: yes that is correct
[14:12] <t1mp> huh which docs was I looking at before?
[14:13] <t1mp> mhall119: ahh ok
[14:13] <t1mp> mhall119: sorry for bothering you :) not your fault
[14:13] <mhall119> t1mp: old ones
[14:13] <mhall119> no problem
[14:13] <t1mp> yeah. I was (clearly wrongly) assuming that all online docs are the same
[14:29] <boiko> elopio: I have updated the MR with the correct fix now, would you mind giving it a try?
[14:38] <ahayzen> t1mp, think i found the issue I was using states before in the panel, but then i removed them. However through a certain path i was setting the state and tht appears to have been causing the issue
[14:40] <dpm> popey, I've now finished filing the bugs for calendar, and I've updated the blueprint accordingly
[14:40] <dpm> popey, https://bugs.launchpad.net/ubuntu-calendar-app/+bugs?field.tag=operator-feedback
[14:41] <popey> thanks dpm
[14:45] <popey> mzanetti / dpm our reminders hangout clashes with another meeting, can we bump it an hour later?
[14:45] <popey> (silly US daylight savings)
[14:45] <mzanetti> :D
[14:45] <mzanetti> popey: not sure we need to do one anyways...
[14:45] <mzanetti> unless you have something to tell
[14:46] <popey> lets have a quick one then ☻
[14:46] <mzanetti> otherwise its business as usual. rpadovani does the work and I review every once in a while
[14:46] <popey> hah
[14:46] <popey> rpadovani: you around?
[14:47] <dpm> yeah, this week we can do a quick IRC one if Riccardo is around
[14:47] <dpm> I need to follow up with Lucas on the visual designs, let me e-mail him now
[15:31] <rpadovani> dpm, popey, mzanetti I'm here now, sorry, I have lesson until 15:00 UTC on Wednsday
[15:31] <mzanetti> rpadovani: no problem
[15:31] <dpm> rpadovani, no worries!
[15:31] <mzanetti> we just wanted to let you know that we postponed the meeting for an hour
[15:32] <rpadovani> mzanetti, for today or for ever?
[15:32] <mzanetti> I think today
[15:32] <rpadovani> oki doki
[15:47] <bfiller> nerochiaro: on your gallery branch that uses libthumbnailer, where is the code that loads the picture when you click on a picture from the events view? seeing some weirdness where photo not being displayed at full res
[15:50] <daker> dholbach: new video :D http://vimeo.com/87206907
[15:51] <dholbach> nice, I'll take a look in a bit
[15:52] <nerochiaro> bfiller: need to look, i'll let you know in a few minutes as i finish something i'm in the middle of
[15:52] <bfiller> nerochiaro: thanks
[16:08] <mzanetti> popey: dpm: so? you guys joining?
[16:09] <dpm> mzanetti, ah, I thought we'd skipped? Sorry, yes, joining now, then
[16:15] <nerochiaro> bfiller: i just pushed the changes to the MR. the tests will probably fail, i'm looking into it. i tested it only on my device, it would be good to give it a go on nexus4
[16:17] <bfiller> nerochiaro: I'll try it
[16:17] <nerochiaro> ty
[16:19] <nerochiaro> bfiller: is trusty-proposed-customized-demo the channel we are suposed to use to install ubuntu with dual boot ? or trusty only ?
[16:19] <bfiller> nerochiaro: trusty or trusty-proposed
[16:20] <nerochiaro> ok, i asked because it proposed that channel on the app and it sounded wierd
[16:21] <bfiller> nerochiaro: I stopped using hte dual boot, it wasn't working and takes an incredibly long time to update the ubuntu image
[16:22] <nerochiaro> bfiller: it's been working for me so far and if i block the screen from going to sleep thn the install is as fast as the other way, more ore less
[16:27] <kalikiana> nik90: FYI https://code.launchpad.net/~kalikiana/u1db-qt/indexRoles/+merge/211771
[16:27] <kalikiana> that's the prerequisite for using the proposed SortFilterModel as referred to in the document
[16:28] <dpm> thanks rpadovani for reviewing https://code.launchpad.net/~bobo-324/reminders-app/fix-1279783/+merge/206341 !
[16:35] <rpadovani> dpm, I totally forgot about it, I'm sorry, we need to be more careful to new contributors, to help them to contribute again :-)
[16:48] <dpm> no need to feel sorry, and thanks for getting the branch merged!
[16:59] <gcollura> is there a tutorial on how to use the UbuntuListView and ListItem.Expandable?
[17:07] <elopio> boiko: test passes now!
[17:08] <boiko> elopio: awesome!
[17:09] <elopio> boiko: thanks. I've learned a lot about the messaging app, and now we have one sleep less :)
[17:10] <boiko> elopio: yes, I still have to work on optimize the history-service data models though., but first I need to get some features in
[17:10] <elopio> boiko: now I can refactor some of the other tests to use the helpers I added on my previous branch. Would that be useful now?
[17:11] <boiko> elopio: sure it is useful
[17:11] <elopio> ok, I'll send your way a couple of branches this week.
[17:17] <boiko> elopio: great! thanks!
[18:36] <vivek_1729> Hi, I have been using Ubuntu for almost a year now and have some programming exposure.
[18:37] <vivek_1729> I really want to contribute to Ubuntu
[18:37] <vivek_1729> Where do I get started?
[18:38] <sarnold> hello vivek_1729 :) welcome aboard
[18:39] <vivek_1729> Hey sarnold
[18:40] <vivek_1729> I don't have much experience in contributing to open source projects before.
[18:41] <vivek_1729> I was just wondering if someone could give me a beginner's walk through on where can I get started
[18:45] <sarnold> vivek_1729: it all depends on what you'd like to do ..
[18:46] <vivek_1729> I want contribute in the specific apps being developed for Ubuntu platform.
[18:46] <sarnold> vivek_1729: you could test the upcoming trusty release on your own hardware and file bug reports, or confirm fixed bug reports, or you could write touch programs for the upcoming phone/tablet releases and file bugs agains the sdk as you go :) or write whatever tools you feel are lacking...
[18:46] <vivek_1729> I am interested in writing code.
[18:47] <vivek_1729> Thanks sarnold. If I want to contribute to some programs, where do I look for the projects?
[18:49] <sarnold> vivek_1729: nearly everything is hosted on launchpad; check out e.g. https://launchpad.net/ubuntu/+source/apparmor for apparmor source packages
[18:49] <sarnold> vivek_1729: this may also help http://packaging.ubuntu.com/html/
[18:50] <nerochiaro> boiko: renato_: artmello_: oSoMoN: can you guys successfully install unity8-autopilot on your devices ? it has dependency problems for me in recent images
[18:50] <nerochiaro> om26er: ^
[18:51] <boiko> nerochiaro: let me see
[18:51] <om26er> nerochiaro, have the latest image? there was an issue previously I believe
[18:52] <boiko> nerochiaro: here it installs fine
[18:52] <boiko> nerochiaro: what is the missing dep there?
[18:52] <boiko> nerochiaro: build 246 here
[18:54] <nerochiaro> om26er: boiko: unity8-autopilot : Depends: unity8 (>= 7.84+14.04.20140317.2-0ubuntu1) but it is not going to be installed
[18:54] <nerochiaro> boiko: whoa, /etc/ubuntu-build say 188, that's weird
[18:54] <boiko> nerochiaro: which image you have there?
[18:55] <boiko> nerochiaro: have you been using trusty-proposed?
[18:55] <nerochiaro> boiko: i guess the dual boot thing isn't pulling the right one. i'm using trusty, i guess i should go with trusty-proposed
[18:55] <boiko> nerochiaro: I have only been using trusty-propose lately
[18:56] <nerochiaro> boiko: i'll try that
[19:59] <samet> hi
[22:53] <buharin> hello :)


[01:55] <PCLine_> Opps - forgot I was going to install Sabre tonight :(
[19:27] <jrgifford> ]]
[19:27] <Unit193> [[
[19:27] <jrgifford> stupid cat.
[19:27] <Unit193> Cat wants to say "hi"
[19:31] <PCLine_> Hi Cat
[19:31] <Unit193> Hello jrgifford's cat!
[19:32] <jrgifford> it's actually younger gifford siblings cat, but it says "have a nice day, i'm off to go sleep in the corner"
[19:38] <PCLine_> It could be worse....The cat could be on your keyboard trying to catch your mouse!
[19:39] <Unit193> s/mouse/fingers/
[19:41] <jrgifford> haha.
[19:42] <Unit193> jrgifford: Nice to see you're still alive.
[19:42] <jrgifford> Unit193, this is the real life model decoy of jrgifford.
[22:04] <PCLine_> Can it be this easy .... apt-get install php-sabre-dav


[12:21] <bswinnerton> Hello, first time playing around with cloud init. Things are going great in Ubuntu, but having some problems configuring networking in Debian. I'm using a nocloud database with a v2 network configuration file to set a static ip address. The user-data and meta-data is applied successfully, but after the machine comes up, it's falling back to DHCP.
[12:21] <bswinnerton> Upon further inspection, this is because /etc/network/interfaces does a source-directory for both /etc/network/interfaces.d/ (which has the correctly configured file), and /run/network/interfaces.d/ which has a file that conflicts and falls back to DHCP. Is there a way to turn off the latter?
[12:25] <bswinnerton> s/database/datastore
[12:36] <bswinnerton> hmm, there's also something weird going on similar to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867921
[12:38] <bswinnerton> So to recap, when using nocloud with a v2 network config that sets a static ip address, when the Debian host comes up, a few things need to happen in order for the machine to get networking: 1) `rm /run/network/interfaces.d/50-cloud-init.cfg` (which includes the DHCP setting), and 2) `mv /etc/network/interfaces.d/50-cloud-init.cfg
[12:38] <bswinnerton> /etc/network/interfaces.d/50-cloud-init`, once those have been completed, a `systemctl restart networking` can be run and everything works fine.
[12:39] <bswinnerton> This is cloud-init 18.3
[13:46] <meena> bswinnerton: have you tried a more recent version to see if this is fixed?
[13:47] <bswinnerton> I haven't, I'm using what's built into the debian cloud images
[13:56] <bswinnerton> In what scenarios would cloud-init write to `/run/network/interfaces.d/`? Is that the fallback described in https://cloudinit.readthedocs.io/en/latest/topics/network-config.html#fallback-network-configuration?
[13:57] <meena> I'm trying to remember if we have deb packages pre-built anyhere
[13:58] <meena> my brain isn't working very well today, so you might be quicker looking yourself
[13:59] <bswinnerton> https://packages.debian.org/buster/cloud-init
[13:59] <bswinnerton> They're quite old, which is why the debian images include them, I assume
[14:00] <meena> no backports?
[14:00] <bswinnerton> ah yes: https://packages.debian.org/source/buster-backports/cloud-init
[14:00] <meena> there's https://launchpad.net/ubuntu/+source/cloud-init but i don't know how well those will work on Debian
[14:03] <meena> bswinnerton: so let's try at version, and if that still fails, we'll file a bug report
[14:03] <meena> and by we, i mean, can you please
[14:04] <meena> s/at /that /
[14:05] <bswinnerton> Sounds good, installing 20.2 now
[14:07] <bswinnerton> Is there an effective way to test this with cloud-init on the guest without rebuilding the image?
[14:07] <bswinnerton> Or does the image need to be rebuilt?
[14:07] <meena> install, run cloud-init clean --logs --reboot
[14:08] <bswinnerton> Neat, wasn't aware of `clean`. Doing that now
[14:08] <meena> that will regenerate everything on the server, including ssh server keys
[14:10] <bswinnerton> Sigh, that fixed it
[14:11] <bswinnerton> Okay, off to pester the Debian folks. Thanks meena
[14:11] <meena> 😽
[14:12] <meena> if i really were useful, I'd help you pinpoint where that was fixed, exactly
[14:12] <meena> but screw that, let them upgrade to the latest version :P
[14:13] <bswinnerton> A quick clarifying question, even after bumping to 20.2 I notice a very long delay when trying to bring up the interface, it appears that it's trying to get a DHCP lease with "Started ifup for ens3". It then eventually times out and continues along, and sets the static IP. Any idea how I could tell it not to try and DHCP? Is that the difference
[14:13] <bswinnerton> between a dsstore of local vs net?
[14:13] <bswinnerton> I have a feeling it was this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867921
[14:13] <bswinnerton> But the dates don't quite align
[14:14] <meena> I'd have to see your full config to figure that out
[14:14] <meena> maybe there's a v1 config sent with dhcp?
[14:14] <bswinnerton> It's using v2 and no shouldn't be DHCP, but let me throw it in a gist for a second set of eyes
[14:15] <meena> cloud-init query
[14:15] <meena> something or the other
[14:18] <bswinnerton> Here's the user-data, meta-data, network-config that's being thrown into the nocloud datastore, as well as `cloud-init query -a`: https://gist.github.com/bswinnerton/86e2e44d4dee4b5271be92580afd056c
[14:28] <bswinnerton> Started a conversation with the debian cloud folks here: https://lists.debian.org/debian-cloud/2020/06/msg00073.html
[14:34] <bswinnerton> Answered my own question: it's not related to the local vs net dsstore option of cloud-localds. It still tries to get a lease on boot even with the value set to local
[14:34] <bswinnerton> I bet it's because of the dhcp config that lives in /run/network/interfaces.d/
[14:34] <bswinnerton> meena: any idea where files in that directory come from? Is that part of cloud-init?
[14:35] <bswinnerton> Oh yeah, that's definitely it. Removing the file leads to super quick boot times
[14:36] <bswinnerton> God what a mess
[14:50] <meena> that a patch from Debian?
[14:51] <bswinnerton> https://github.com/canonical/cloud-init/commit/a6faf3acef02bd8cd4d46ac9efeebf24b3f21d81.patch
[14:53] <bswinnerton> That's the first problem, the second is the fact that a file gets added to `/run/network/interfaces.d/` that defaults to DHCP
[14:53] <bswinnerton> And I'm not sure where that comes from, but am working on terrible hacks with user-data to get rid of it
[14:55] <meena> logs should be helpful
[14:55] <meena> maybe
[15:00] <bswinnerton> Not seeing any references to that directory in the log, so it must be coming from the Debian cloud image
[15:01] <bswinnerton> Is runcmd the best hook for modifying network configurations early in the boot process? It only needs to run once
[17:15] <meena> network is usually the first thing to be run, so there's almost no chance of doing anything before that dhcp thing
[17:15] <meena> unless
[17:17] <meena> https://cloudinit.readthedocs.io/en/latest/topics/modules.html#bootcmd
[17:17] <meena> bswinnerton: this could be worth a shot, if you Anna rm that file, so you don't have to modify the image :D
[17:21] <meena> wanna
[17:22] <meena> i am now second stage tired / exhausted.
[17:22] <meena> Good evening.