[07:50] <Saviq> AlanBell, you need ppa:ubuntu-sdk-team for newest SDK
[07:57] <Saviq> MacSlow, o/ long time no see :)
[08:17] <Saviq> tsdgeos, \o
[08:17] <tsdgeos> Saviq: welcome, how was south africa?
[08:17] <Saviq> tsdgeos, hot and sunny ;)
[08:18] <Saviq> tsdgeos, now back home - 10° below 0 here ;)
[08:18] <tsdgeos> booo
[08:18] <Saviq> so ~ 40° degrees difference ;)
[08:18] <Saviq> -degrees
[08:18] <Saviq> tsdgeos, how was here?
[08:19] <tsdgeos> otto broke again
[08:19] <tsdgeos> and then fixed itself
[08:19] <tsdgeos> except for one particular test
[08:19] <tsdgeos> so we have all CI failing again
[08:19] <Saviq> tsdgeos, :/
[08:20] <Saviq> tsdgeos, fginther wrote that it disappeared with updates to lp:unity-scopes-api
[08:21] <tsdgeos> And i discovered the Qt 5.2 JS engine is totally broken in x86, but failed to get any traction from upstream to fix it https://codereview.qt-project.org/#change,76374 https://bugreports.qt-project.org/browse/QTBUG-36430 https://bugreports.qt-project.org/browse/QTBUG-36289
[08:21] <tsdgeos> Saviq: https://app.asana.com/0/9785046628744/9782553540311 is tracking the new one
[08:21] <tsdgeos> there's a new comment in there, i'll see if i can get it to fail doing what they say
[08:22] <Saviq> tsdgeos, apparently I don't have access to that  task or something - empty here
[08:22] <MacSlow> Saviq, hey :)
[08:24] <tsdgeos> Saviq: hmmm, there's a "Make public to canonical.com addresses, but not sure if the guys will get angry if i do that :D"
[08:24] <Saviq> tsdgeos, yeah, leave it to them
[08:24] <tsdgeos> Saviq: anyway, the interesting link was https://wiki.canonical.com/UbuntuEngineering/CI/Playbook/UpstreamMerger#Reproducing_generic-mediumtests-runner_touch_testing
[08:25] <Saviq> tsdgeos, mhm
[08:43] <Saviq> ricmm, o/ how's Londres?
[08:44]  * tsdgeos tries reproducing the otto failures with those instructions
[08:46] <tsdgeos> Mirv: ping
[08:48] <Mirv> tsdgeos: pong
[08:48] <tsdgeos> Mirv: seen my comments from friday about qtubuntu?
[08:48] <tsdgeos> in this channel
[08:49] <Mirv> tsdgeos: yes. not really sure why it'd be, but at least the qtdeclarative snapshot was added only after the last rebuild. so I triggered another rebuild, but I haven't got my device yet to the state of testing it.
[08:49] <tsdgeos> ok
[08:59] <mhr3> Saviq, heya, back from holidays?
[08:59] <Saviq> mhr3, yup, here
[08:59] <Saviq> mhr3, I saw you had some confusion with the preview JSONs in #ferrets?
[09:00] <mhr3> Saviq, yep can we talk in a bit?
[09:00] <mhr3> also thomas wants to join
[09:00] <mhr3> Saviq, in 30mins good for you?
[09:00] <Saviq> mhr3, sure, I've a half-hour at 11am/UTC, free until/past that
[09:01] <Saviq> mhr3, yeah
[09:03] <tsdgeos> Saviq: oh, so the blurry icons thing was already reported :D good thing i didn't know so i did actually look into it instead of just duplicating ^_^
[09:03] <Saviq> tsdgeos, ;)
[09:06] <Saviq> tsdgeos, I saw bug #1271676 creep up on us some time ago, feels like a LVWPH issue?
[09:06] <tsdgeos> Saviq: isn't that the expected behaviour?
[09:07] <tsdgeos> i mean you launch an app it shows the running apps
[09:07] <tsdgeos> i thought it was by design
[09:07] <Saviq> tsdgeos, not if you scrolled down
[09:07] <Saviq> tsdgeos, i.e. expand "Installed", scroll to the bottom, launch → it jumps to top
[09:08] <Saviq> should remain in place, IMO (and should definitely *not* jump in just one frame)
[09:09] <Saviq> pete-woods, hey, any idea how https://errors.ubuntu.com/problem/5eef1d661e41b06e44728924231b45e26457dbb7 might happen?
[09:09] <pete-woods> Saviq: perhaps if the XDG_DATA_DIR environment variable was messed up somehow?
[09:09] <Saviq> pete-woods, and whether we could/should protect against it?
[09:10] <Saviq> pete-woods, hmm
[09:10] <tsdgeos> Saviq: ah ok
[09:10] <tsdgeos> Saviq: i can have a look then
[09:10] <pete-woods> Saviq: I guess that must be where gsettings-qt looks for the schemas..
[09:10] <tsdgeos> Saviq: let me try reproducing the autopilot/otto errors first though
[09:10] <Saviq> tsdgeos, of course
[09:11] <pete-woods> but why does it log fatal? seems a bit dramatic
[09:11] <Saviq> pete-woods, that's G
[09:12] <pete-woods> true!
[09:12] <Saviq> pete-woods, you need to check for a schema to exist before trying to load it
[09:12] <pete-woods> Saviq: okay, that's a good idea, I'll try and figure out how to do that with the API
[09:13] <Saviq> pete-woods, I think it'd need to be gsettings-qt that needed changing, TBH
[09:13] <Saviq> larsu, WDYT? https://errors.ubuntu.com/problem/5eef1d661e41b06e44728924231b45e26457dbb7
[09:13] <Saviq> larsu, protect against crash because of missing schema in gsettings-qt?
[09:19] <larsu> Saviq: ah, the old discussion :)
[09:20] <Saviq> larsu, I imagine it is ;)
[09:20] <larsu> Saviq: why is this happening. Is unity supposed to work even when UserMetrics is not installed?
[09:20] <Saviq> larsu, we don't yet know the reason, but yes it should
[09:21] <Saviq> larsu, as I haven't seen anyone reproduce it
[09:21] <larsu> Saviq: right. In that case, I think we should have a way to find out if it is installed
[09:21] <larsu> because which values of which types should gsettings-qt return if the schema is not installed?
[09:22] <larsu> probably unity would crash anyway (or behave weirdly) if we just returned empty variants
[09:22] <Saviq> larsu, undefined, probably ;)
[09:22] <Saviq> well, it looks like they're really old installations - unity8 from Oct 16, and I don't know of a way to reproduce...
[09:23] <larsu> Saviq: uninstall UserMetrics probably :)
[09:24] <Saviq> larsu, well, yeah, :P
[09:24] <Saviq> larsu, I mean not sure how that happens to people
[09:25] <larsu> Saviq: usermetricsservice (the package that contains the schema) is not a dependency of unity8
[09:25] <Saviq> mzanetti, oi man o/
[09:26] <Saviq> larsu, it is through libusermetricsoutput1
[09:26]  * greyback waves
[09:26] <larsu> Saviq: ah, through unity8-private, thanks. Well in that case the bug can't happen and we should ignore it :P
[09:27] <Saviq> larsu, yeah indeed
[09:28] <Saviq> greyback, \o got home OK?
[09:28] <Saviq> greyback, how long at the airport before you could check in?
[09:28] <greyback> Saviq: yep, home ok. I managed to check in at 6.30, so wasn't long wait
[09:28] <Saviq> greyback, good
[09:49] <Mirv> tsdgeos: confirming qt 5.2 unity8 now runs. apps lens seems to be empty, and starting an app from the home lens does not work, but all in all seeing unity8 itself smooth and working looks really nice.
[09:49] <tsdgeos> Mirv: i had the apps lens i think
[09:49] <Mirv> it seems I'm able to launch stuff via indicators, like battery view
[09:50] <tsdgeos> but maybe not
[09:50] <tsdgeos> don't really remember
[09:50] <Mirv> yeah, system settings etc works via indicators, just not via normal app launchers
[09:50] <Mirv> Saviq: welcome back, and sorry for the highlighting noise :)
[09:53] <Mirv> Saviq: so this actually works now. http://pastebin.ubuntu.com/6808355/ - the qtmultimedia-touch packaging does not clean itself up, otherwise those lines wouldn't be needed
[09:53] <Saviq> Mirv, hey, no worries
[09:54] <Saviq> Mirv, cool beanz
[10:09] <Saviq> tsdgeos, 2:30pm for a hangout about CI train?
[10:10] <tsdgeos> Saviq: it's a bit tight with my lunch schedule but should work
[10:11] <Saviq> tsdgeos, no that's fine
[10:11] <Saviq> tsdgeos, say when
[10:11] <tsdgeos> 3pm is a bit better
[10:11] <tsdgeos> s/bit//
[10:13] <Saviq> tsdgeos, ok, half an hour should do I think, mzanetti ↑
[10:13]  * Saviq does invite
[10:14] <mzanetti> still fine with me
[11:06] <tsdgeos> bah
[11:06] <tsdgeos> took me ages to setup that thing for autopilot
[11:06] <tsdgeos> just to have it still succeed
[11:06] <tsdgeos> :D
[11:06] <tsdgeos> :'(
[11:09] <Saviq> :/
[11:11] <tsdgeos> Saviq: do we know if the QA phones use trusty or trusty-proposed?
[11:11] <tsdgeos> we do
[11:11] <tsdgeos> because it upadtes
[11:11] <Saviq> tsdgeos, good question
[11:11]  * tsdgeos checks
[11:12] <tsdgeos> doesn't seem to use -proposed
[11:12] <tsdgeos> wonder if that is the case since i'm using it
[11:13] <tsdgeos> let me flash the phone with trusty only and see if it fails then
[11:13] <Saviq> tsdgeos, hmm I'm seeing -proposed http://s-jenkins.ubuntu-ci:8080/job/touch-flash-mako-0090f741e3d141bc/792/console
[11:13] <tsdgeos> Saviq: but https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/2266/consoleFull ?
[11:13] <Saviq> tsdgeos, otto is on x86
[11:13] <Saviq> tsdgeos, no images there
[11:14] <tsdgeos> is it?
[11:14] <Saviq> tsdgeos, yup
[11:14] <tsdgeos> and why am i pointed at stuff running on the phone?
[11:14] <tsdgeos> sigh
[11:14] <Saviq> "ps-nvidia-gt630"
[11:14] <Saviq> is what this job run at
[11:14] <tsdgeos> ok
[11:15] <mhr3> question, if i pass a qobject without a parent to qml, will it take ownership of it by calling setParent()?
[11:16] <tsdgeos> what's "pass a qobject" ?
[11:16] <Saviq> mhr3, ownership, not parentship
[11:17] <Saviq> mhr3, I don't think it will assign a parent...
[11:17] <tsdgeos> so i will try yet again on my desktop just for the fun
[11:17] <Saviq> tsdgeos, return from a model, for instance
[11:17] <tsdgeos> no, won't call setparent at all
[11:17] <mhr3> in that case the model we're using is kinda broken
[11:18] <Saviq> mhr3, meaning?
[11:18] <mhr3> we construct a preview before emitting previewReady() with the preview as a param, if there was noone listening to that signal the instance would leak
[11:22] <mhr3> and setting the scope as the preview parent doesn't seem to be helpful unless shell notified the plugin everytime it's done with a preview
[11:26] <mhr3> sounds like the correct way to do this would be to return an object from the preview() request itself and have a finished() signal on that when all the data is ready
[11:29] <tsdgeos> so yeah, oran again the tests on my machine and still work _:'(
[11:48] <karni> Saviq: Welcome back :)
[11:48] <Saviq> karni, hey, how are you?
[11:48] <karni> Saviq: Not bad, thanks :) Rested after your holiday? :)
[11:49] <Saviq> karni, when have you last rested on holidays, I ask you?
[11:49] <Saviq> ;)
[11:49] <karni> Saviq: honestly, had to take last Thursday off. We're not that long after christmas, are we? haha
[11:50] <Saviq> karni, I rather meant that I could usually use another week or two to actually rest past the holiday part ;)
[11:51] <karni> Saviq: I found that ResponsiveGridView margins always evaluate to 0, and all columns have spacing to its right (including the last one), which is clearly visible when you do tryFilterGrid. That was highly confusing :S
[11:51] <karni> Saviq: hahahahahah right ;)
[11:51] <karni> Sometimes I don't get the simplest jokes lol
[11:51] <Saviq> karni, that's right, the tiles themselves need to center themselves
[11:52] <Saviq> karni, as the Grid doesn't actually change the size of the delegates
[11:52] <karni> Saviq: Does Card(.qml) center itself? i.e. the renderer should not care?
[11:52] <Saviq> karni, no, it doesn't indeed
[11:52] <Saviq> karni, but there's more - Card doesn't know about the size it "should" be
[11:53] <Saviq> karni, so it's CardFilterGrid that should wrap the Card in an Item, that will be sized accordingly
[11:53] <Saviq> karni, and which will center the Card inside of itself
[11:53] <karni> I see. And about margins - if they always evaluate to zero - does that mean we're not interested in ResponsiveGridView margins? If so, I'd like to remove those bits. I tried to make them work, which resulted in really strange behavior of 2 columns always displaying as one, as if there was not enough space (all worked fine for 3+ number of columns)
[11:54] <karni> Saviq: That makes sense. I wonder if that's the case already, I recall CardFilterGrid had "Card" as delegate
[11:54] <Saviq> karni, which was probably a fail on my part
[11:54] <karni> aha
[11:55] <karni> Saviq: I understand that I should drop the "margin" evaluating code from ResponsiveGridView, because they always (mathematically) resolved to zero width.
[11:56] <Saviq> karni, if you can confirm they did, yeah
[11:56] <Saviq> karni, but I'm not entirely sure that's correct
[11:57] <karni> Saviq: I'll find that and let you know.
[11:57] <Saviq> karni, thanks
[11:57] <karni> sure
[11:58] <Saviq> karni, yeah, if I resize the window, I get them to be 8/14 or something
[11:59] <Saviq> karni, I mean onMarginsChanged: console.log(margins) in ResponsiveGridView
[11:59] <Saviq> karni, prints different values, depending on the size of the window
[12:00] <karni> Interesting.
[12:07] <karni> Saviq: ok, let's start elsewhere. qml/Components/ResponsiveGridView.qml ln 73 columnsForSpacing function - the formula should be return Math.max(1, Math.floor(parent.width / (delegateWidth + spacing)));
[12:07] <karni> Saviq: me and tsdgeos agree on that, I just wanted for you to validate.
[12:07] <karni> Saviq: if margin is half of spacing, then we should divide parent.width over (delegateWidth + spacing)  -- the last spacing is spread over two margins.
[12:08] <karni> There's no reason anything would be subtracted from parent.width before division.
[12:08] <karni> Is there.
[12:12] <Saviq> karni, spacing is only applied on one side of the delegate, so I feel like it does make sense
[12:13] <Saviq> karni, taking "// minimum margin is half of the spacing" into account
[12:13] <karni> Saviq: and by "margin" the author meant "sum of left and right" margins?
[12:14] <tsdgeos> Saviq: spacing is only applied in one side of the delegate?¿
[12:14] <karni> 2x spacing/2 = spacing. n-1 columns have spacing. n*(delegateWidth + spacing) would make n columns, n-1 spacings, and 1 spacing being both margins.
[12:14]  * Saviq needs a drawing
[12:14] <karni> Saviq: sending it to you
[12:15] <karni> Sent.
[12:15] <Saviq> tsdgeos, in RGV we're not *really* using GridView's spacing
[12:15] <tsdgeos> Saviq: what are we using?
[12:16] <Saviq> tsdgeos, nothing, we're just telling the delegates to center within themselves
[12:16] <Saviq> tsdgeos, and tell them their size
[12:16] <Saviq> tsdgeos, which, granted, might not be the best thing to do
[12:16] <tsdgeos> Saviq: RGV is not doing that, is it?
[12:16] <tsdgeos> maybe someone below is doing that
[12:16] <Saviq> tsdgeos, no, it's just telling:
[12:17] <Saviq> tsdgeos, ok, I've space for so many columns, and each of them is so wide
[12:17] <tsdgeos> but if you think in RGV terms what karni says makes sense, actually if you look at the test you see it's wrong
[12:17] <karni> Saviq: CardFilterGrid also has "Card" as immediate delegate. Maybe that is why I was confused.
[12:17] <Saviq> karni, yeah, it shouldn't have
[12:17] <karni> ok, now I understand
[12:17] <Saviq> tsdgeos, so it tells the delegate to *be* that size, and center within itself
[12:18] <Saviq> tsdgeos, karni, anyway, I don't think I'm needed here, if you guys understood it and say that's incorrect, I'm fine with that
[12:18] <tsdgeos> yes and no :D
[12:18] <Saviq> trying to be the devil's advocate here
[12:18] <tsdgeos> i think there's something wrong at both levels
[12:18] <tsdgeos> and that one wrong fixes the other
[12:19]  * karni tries something on new-scopes branch
[12:19] <Saviq> karni, tsdgeos the "minimum margin is half of the spacing" part is an assertion
[12:19] <tsdgeos> yes
[12:19] <karni> yes, I did take that into consideration
[12:19] <karni> 2 margins (left+right) = 1 minimum spacing
[12:19] <Saviq> and the calculation takes it into account
[12:19] <tsdgeos> not really
[12:19] <karni> wait.. *thinks*
[12:19] <tsdgeos> i mea
[12:19] <tsdgeos> it does
[12:19] <Saviq> but right
[12:19] <tsdgeos> that's not the issue
[12:19] <karni> if we center the children
[12:19] <tsdgeos> the issue is that it also takes into account an *extra* column
[12:20] <tsdgeos> on the right
[12:20] <karni> then last column could also have "spacing"
[12:20] <Saviq> yeah now I see what you mean
[12:20] <karni> Now that I know children are centered in the delegates, there's a slighty different light to the matter.
[12:20] <tsdgeos> but
[12:20] <Saviq> the "last" spacing
[12:20] <karni> still, if *one* margin is spacing/2
[12:21] <tsdgeos> it is true that make tryResponsiveGridView
[12:21] <karni> then both add up to *spacing*
[12:21] <tsdgeos> makes it look centered
[12:21] <Saviq> is the one that is "sacrificed" for left and rigth margin
[12:21] <tsdgeos> while make tryFilterGrid
[12:21] <tsdgeos> is not
[12:21] <karni> +1
[12:21] <tsdgeos> so someone is doing it wrong somewhere :d
[12:21] <karni> Looking at the code I assumed there was no layer between the delegate and the future (Card) delegate. No item we could center in.
[12:21] <karni> That is why tryFilterGrid was right aligned
[12:22] <karni> If we allow an Item above the delegate body, we can center the child.
[12:22] <Saviq> karni, we need to, as the positioners won't do it for use
[12:22] <Saviq> -
[12:22] <Saviq> -e
[12:22] <karni> So, tryFilterGrid would also look different, it's just the test is implemented in this way.
[12:22] <karni> Right
[12:22] <Saviq> karni, tsdgeos, ok I agree the right-most spacing in that calculation is "sacrificed" for left/right margin
[12:23] <Saviq> so no need for the subtraction
[12:23] <karni> Saviq: Now I don't :| Because if that was the case (which I initially thought) then if delegates are center aligned (in the width including the spacing), where would the last column *align*?
[12:24] <karni> (and I was the one suggesting it was wrong)
[12:24] <Saviq> karni, the whole thing is shifted from the right
[12:24] <Saviq> karni, so it still centers within itself
[12:24] <karni> ok
[12:24] <Saviq> karni, but the whole thing is pushed from the left by margin/2
[12:24] <Saviq> so on the right there's still margin/2 space
[12:25]  * karni admits he needs a moment to think about it
[12:25] <karni> I was assuming spacing was always to the right, that's why we 1) neede margins 2) needed not spacing for the last column
[12:26] <karni> If we center align delegate bodies, left margin + bit of spacing (that'd appear on left and right of center-aligned left most delegate) would be more than right margin of the grid view
[12:27] <Saviq> karni, spacing is actually "inside" the delegate in our case
[12:27] <karni> correct
[12:27] <Saviq> so it's centered within that
[12:27] <Saviq> it's only used to calculate how big the delegate is meant to be
[12:28] <Saviq> so every delegate is minimumWidth + spacing wide
[12:28] <karni> return Math.max(1, Math.floor((parent.width - spacing) / (delegateWidth + spacing))); (not -spacing/2) would be correct formula now, knowing delegates have center aligned bodies.
[12:28] <karni> exactly
[12:28] <karni> And because of that, I take back we should not subtract anything from parent before division. We should, the width of both margins.
[12:29]  * karni makes a new picture
[12:34] <karni> Saviq: tsdgeos: Sent updated picture, considering center-aligned body of the delegates
[12:35] <karni> Maybe one of you could point out what I'm not getting right in the new situation.
[12:35] <karni> Margins are specifically free space on left and right of the layout, different from the "free space" that may show up on left/right of a delegate because of it's center-alignment.
[12:36] <Saviq> karni, right, and in effect all spaces are equal A
[12:37] <karni> Saviq: and there's n+1 of them
[12:37] <karni> thus (parent.width - spacing) / (delegateWidth + spacing)
[12:38] <tsdgeos> ok
[12:39] <Saviq> karni, yes, but that's why the /2 I think, in your case all spaces are always equal, where the left/right margin was meant to be able to be /2
[12:39] <tsdgeos> but that assumes that the delegate will center itself
[12:39] <Saviq> tsdgeos, RGV does assume that
[12:39] <tsdgeos> if it doesn't will look bad
[12:39] <tsdgeos> but ok
[12:39] <karni> tsdgeos: yes, and it turns out we should assume that.
[12:40] <Saviq> tsdgeos, karni, I think that's because we wanted to allow smaller margins than spacing
[12:40] <karni> Saviq: You mean the comment was meant to be "the sum of left and right margin equals spacing/2 at minimum"?
[12:40] <Saviq> or well, Kaleo did
[12:41] <karni> it's so confusing the code says "margin" and in fact means "left+right margin"
[12:41] <Saviq> karni, no, the _visual_ left/right margin is meant to be A/2 at minimum
[12:41] <karni> right
[12:41] <karni> oh
[12:41] <Saviq> karni, I don't think it does
[12:41] <karni> ...
[12:41] <karni> _visual_
[12:41] <Saviq> karni, so in your image, if you take the extreme A/2 out
[12:42] <Saviq> that will result in visually A/2 left and right, and A between items
[12:42] <Saviq> karni, but your formula wouldn't allow it
[12:44] <Saviq> karni, if you go tryResponsiveGridView, maxCol 1000, minSpac 16
[12:44] <Saviq> karni, you can see we're at 8px on left/right, but 16 between items
[12:44] <karni> 8px to the left of grid item, 16px between delegate bodies, yes
[12:45] <Saviq> karni, that's actually when you drop the -spacing/2
[12:45] <karni> yes
[12:45] <Saviq> karni, when it's there, you get huge margins
[12:45] <karni> so, parent.width / (delegateWidth + spacing), is that right?
[12:45] <Saviq> karni, that sounds correct to me, yes
[13:00] <Saviq> karni, just saw your crash in the vj with filter integration, it looks like you've looped the models somehow
[13:01] <Saviq> karni, as it's calling roleNames() on itself until it decides it's enouh
[13:01] <Saviq> +g
[13:02] <Saviq> karni, yup:     property alias model: verticalJournal.model
[13:02] <Saviq>         model: LimitProxyModel {
[13:02] <Saviq>             model: root.model
[13:03] <Saviq> karni, which means the LimitProxyModel uses itself as the backing model
[13:03] <karni> :O
[13:03] <karni> tsdgeos: you where right... I did loop them
[13:05] <Saviq> truth be told I'm not sure we want the LimitFilterModel at all any more...
[13:05] <Saviq> karni, tsdgeos, as we talked, now that we have delegate ranges, we can just clip the views and let them just not draw the delegates outside of the views
[13:06] <Saviq> sure, I really doubt the overhead of drawing one more row (and would we, actually?) is worth the whole Filter dance
[13:07] <Saviq> -sure
[13:07] <karni> I dont think I'm familiar with delegate ranges, but I do know VerticalJournal has no concept of row so.. I got stuck there a bit.
[13:07] <Saviq> karni, yeah, exactly
[13:08] <Saviq> karni, QML *Views only draw the delegates that are within their geometry
[13:08] <Saviq> karni, so, say your GridView is fullscreen, and you can only see 3 rows, 2 items each
[13:09] <karni> neat
[13:09] <Saviq> karni, the GridView will make sure to only instantiate/draw the delegates you have on screen, not the whole model
[13:10] <Saviq> karni, in the dash our problem is that we make the *Views as high as their content is, so that the overall ListViewWithPageHeader behaves correctly
[13:10] <Saviq> karni, so when you expand a category, it expands to its full height, and draws all of them
[13:10] <Saviq> karni, so tsdgeos introduced two new props: delegateCreationBegin and *End
[13:10] <karni> ahaa
[13:11] <karni> okay :D
[13:11] <Saviq> karni, those were unfortunately rejected upstream, but the reason was "because we want to re-do it somewhen in the future completely, and don't touch the crap, 'cause it stinks"
[13:11] <Saviq> karni, with no timeframe
[13:11] <Saviq> karni, so we patched the *Views to include the two above
[13:12] <Saviq> karni, which let us tell the *Views that instead of considering your full geometry, only draw the delegates between *Begin and *End
[13:13] <Saviq> karni, which results in only the delegates which you can see being drawn, even though the *View itself is full-height
[13:14] <Saviq> karni, so yeah, I'm basically starting to think we should drop the *Filter* parts, and just clip the views / change their geometry, so that they take care of the delegates themselves
[13:15] <Saviq> karni, especially with VJournal, where there are no rows, as you said yourself
[13:15] <karni> Now I get it :)
[13:16] <karni> Saviq: thank you for the explanation
[13:16] <karni> Saviq: so delegateCreationBegin/End are used for clipping the rest?
[13:16] <Saviq> karni, so yeah, don't do filtering for VJ
[13:16] <mzanetti> Saviq: hey, so we still have the issue that the phone's rendering performance drops drastically when we have more than ~5 apps open.
[13:16] <mzanetti> which turns out to be an issue for showcasing the right edge
[13:17] <Saviq> karni, well, in that case it's actually not even the delegate*Begin/End, but just the view geometry
[13:17] <mzanetti> cause first thing you do with that branch is to check how it looks with 10 apps in it
[13:17] <Saviq> mzanetti, file a new bug against unity8 and mir please
[13:18] <mzanetti> ok
[13:18] <Saviq> mzanetti, and unity-mir, too, in case it's something there
[13:18] <Saviq> karni, what's more, as you probably saw in the spec
[13:18] <karni> Saviq: clip at 35gu height
[13:18] <Saviq> karni, exactly
[13:18] <Saviq> karni, so just do that in CardVJ
[13:18] <mzanetti> Saviq: given that everything gets slow, I expect it to be in mir's rendering code. but yeah, I'll put all related stuff to it
[13:19] <Saviq> karni, height: filtered ? min(35GU, fullHeight) : fullHeight
[13:19] <Saviq> karni, pseudo-code of course
[13:19] <karni> Saviq: ack, thank you :)
[13:27] <mzanetti> Saviq: https://bugs.launchpad.net/unity8/+bug/1273224
[13:27] <Saviq> mzanetti, thanks
[13:31] <Saviq> mzanetti, confirmed
[13:31] <mzanetti> Saviq: nice
[13:32] <mzanetti> Saviq: given that this issue exists ever since we switched to Mir and noone cared about it, I guess we should raise this bug with kgunn
[13:32] <Saviq> mzanetti, yup
[13:32] <mzanetti> ok. I will do so
[13:40] <om26er> Saviq, mzanetti btw bug 1227739 is probably related
[13:49] <mzanetti> om26er: interesting, might be related indeed
[13:50] <Saviq> om26er, about QT_LOAD_TESTABILITY, did you use --global for set-env?
[13:51] <om26er> Saviq, yes I did, I tried with and without it
[13:51] <om26er> even I just replied to your comment there
[13:52] <om26er> I did:
[13:52] <om26er> initctl set-env --global QT_LOAD_TESTABILITY=1
[13:53] <Saviq> om26er, truth be told, did it *ever* work like that for apps?
[13:53] <Saviq> om26er, we have a bit of code in unity8's main()
[13:54] <Saviq> om26er, that loads testability based on the env var, but that would suggests it's a unity8-specific thing at the moment
[13:54] <om26er_> Saviq, network failed me. did you read my message ?
 om26er, truth be told, did it *ever* work like that for apps?
[13:55] <Saviq>  om26er, we have a bit of code in unity8's main()
 om26er, that loads testability based on the env var, but that would suggests it's a unity8-specific thing at the moment
[13:55] <mhr3> Saviq, how much effort is it to hook up tapping in new-scopes?
[13:55] <om26er_> Saviq, Yes, it worked for me a couple of weeks ago
[13:55] <mhr3> Saviq, cuold use it so i can test the previewing and stuff
[13:55] <om26er_> Saviq, I had a working script
[13:56] <Saviq> om26er_, either way it's not a unity8 issue
[13:56] <Saviq> om26er_, not sure where it happened for apps, then
[13:56] <Saviq> om26er_, hopefully thomi/veebers will know
[13:56] <Saviq> mhr3, let me see
[13:57] <om26er_> Saviq, right, QT_LOAD_TESTABILITY is that a qt flag or does it live inside autopilot ?
[13:57] <Saviq> om26er_, it needs to be interpreted by Qt
[13:58] <mhr3> seems like card itself is just missing onClicked... plus some uncommenting then
[13:59] <Saviq> mhr3, http://paste.ubuntu.com/6826324/ should get you going
[14:00] <mhr3> Saviq, mind just pushing that to new-scopes?
[14:00] <ricmm> Saviq: sup
[14:00] <ricmm> Saviq: Londres is good as usual
[14:00] <Saviq> mhr3, otp now
[14:00] <ricmm> but im tired of not being home
[14:00] <mhr3> Saviq, i take that as "feel free to push yourself" :)
[14:00] <Saviq> mhr3, as long as you fix it first ;)
[14:00] <Saviq> mhr3, or verify it works, at least
[14:03] <greyback> ricmm: I know that feeling :)
[14:30] <mzanetti> all: kgunn, Saviq, tsdgeos and me will be a bit late for the standup. Cimi, can you take over with guiding the standup?
[14:31] <Cimi> mzanetti, sure
[14:37] <Saviq_> kgunn, going to standup
[14:39] <kgunn> Saviq: ack, i'm in ...my network freaked out
[14:40] <Saviq> kgunn, your pulseaudio freaks out again, too :/
[14:42] <bregma> didrocks, were the compiz/nux/unity7 daily PPA builds really supposed to be turned off again?  The latest rare and precious CI build failed because of weeks-old binaries.
[14:43] <didrocks> bregma: I asked to turn it on on Friday, not sure if it was done. let's see if sil2100 can have a look ^
[14:44] <sil2100> didrocks, bregma: those don't seem to be re-enabled from what I see, let me reenable
[14:44] <bregma> is there any reason why the dailes need to be turned off?  nothing in Touch depends on them, they're leaf nodes
[14:46] <sil2100> bregma: we had all dailies disabled and doing only manual stack runs because of some crucial landings - but we can reenable now I guess
[14:46] <sil2100> didrocks: can I reenable?
[14:46] <didrocks> sil2100: sure, I asked on Friday already :)
[14:46] <didrocks> sil2100: thanks a lot!
[14:48] <mzanetti> elopio: a, forgot to mention: at some point we did have those coverage results in jenkins, but some jenkins upgrade broke the collection of artifacts and we didn't get it back since
[14:48] <sil2100> didrocks: oh, one question while we're at it - the unity stack has like unity-scope-mediascanner in it, and since it's basically a unity8-specific scope, it's not building for powerpc
[14:48] <mzanetti> elopio: but the coverage.xml file generated by runtests.sh is compatible with jenkins
[14:48] <sil2100> didrocks: so the unity stack keeps waiting for it in the build phase, while it depwaits
[14:48] <sil2100> didrocks: can we disable this one scope for powerpc in cu2d in the unity stack build?
[14:48] <sil2100> didrocks: or it's per-stack only?
[14:49] <didrocks> sil2100: it can be per project, but it's per run
[14:49] <elopio> mzanetti: good to know, I'll take that into account.
[14:49] <didrocks> so you will get the same issue in the next 8 hours
[14:49] <mzanetti> kgunn: may I ask you to create some visibility/priority on this one? https://bugs.launchpad.net/unity8/+bug/1273224
[14:49] <sil2100> didrocks: ah, cu2d-skip - but a global skip, like for unity8 stack?
[14:49] <sil2100> didrocks: since you made unity8 ignore powerpc right?
[14:49] <didrocks> sil2100: yeah, it's support per stack or per projects IIRC
[14:49] <sil2100> (for ever)
[14:49] <didrocks> no
[14:49] <didrocks> it doesn't ignore forever
[14:50] <didrocks> it ignores because it was never published in ubuntu
[14:50] <didrocks> on powerpc
[14:50] <sil2100> ah, ok
[14:50] <sil2100> Crap
[14:50] <sil2100> Thanks ;)
[14:50] <kgunn> mzanetti: ack
[14:50] <didrocks> sil2100: yw! ;)
[14:52] <kgunn> tedg: were you involved in the original "multiple apps open = slow" investigation ?
[14:55] <dednick> mzanetti: neither the plugins or qml folder seems to have the qml files included with the Unity/Indicators plugin. Any idea what needs doing?
[14:55] <mzanetti> dednick: what?
[14:55] <tedg> kgunn, Sorry, xchat crashed.
[14:55] <tedg> kgunn, I don't think I was in that one.
[14:56] <mzanetti> dednick: ah... you're missing qml files in the project tree?
[14:56] <dednick> mzanetti: you did the CMake thing for qtcreator right?
[14:56] <dednick> mzanetti: yah
[14:56] <mzanetti> dednick: where are they?
[14:57] <dednick> mzanetti: plugins/Unity/Indicators/qml
[14:57] <mterry> Are unity8 CI runs just borked?   I have a simple branch that doesn't even touch anything tested and they are failing
[14:57] <mzanetti> dednick: I see. I'd suggest adding them to the Indicators target in there
[14:57] <dednick> mzanetti: maybe they should be moved to qml/plugins/Unity/Indicators ?
[14:57] <mzanetti> Saviq: ^ ?
[14:58] <fginther> tsdgeos, I have some info on the unity8 otto test failure
[14:58] <tsdgeos> fginther: cool
[14:58] <mzanetti> dednick: so yeah, either that or add them to the target in plugins/Unity/Indicators
[14:58] <fginther> tsdgeos, the problem appears to be dependency related. If I remove http://naartjie.ubuntu-ci/archive/head.unity8/trusty/ as an apt archive, the tests pass
[14:59] <Saviq> mterry, yes, tsdgeos and fginther are on it ↑
[14:59] <dednick> mzanetti: ok, thanks
[14:59] <mzanetti> dednick: I for one would keep them where they are and add them to the target in there.
[14:59] <mterry> Saviq, awesome
[14:59] <fginther> tsdgeos, example: http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty/2297/
[15:00] <tsdgeos> woot, i think i just found a bug in lvpwh
[15:00] <tsdgeos> fginther: interesting, i was thinking that was the case, but when i ran on the phone with naartjie enabled it still worked, but i'll try again on my desktop
[15:01] <Saviq> mzanetti, not sure what question am I supposed to answer?
[15:01] <tsdgeos> fginther: have you been able to reproduce the problem locally?
[15:01] <mzanetti> Saviq: would you keep indicators qml files where they are and add them to the target in there, or would you move them to qml/ so they show up in the project tree in there?
[15:02] <fginther> tsdgeos, I'm not in a position to retest locally at the moment, but I have another example:
[15:02] <Saviq> mzanetti, dednick, I think we'll be splitting up other .qmls a bit into plugins, too, so yeah, keep them there
[15:02] <mzanetti> ack
[15:02] <fginther> http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty-debug-fjg/15 also passed when I removed the naartjie source, but failed when it was there (see build 14)
[15:03] <fginther> tsdgeos, this appear to be desktop only perhaps?
[15:03] <tsdgeos> fginther: might be
[15:03] <tsdgeos> fginther: i'll try polluting my destkop with naartjie and see what happens
[15:04] <fginther> tsdgeos, there are only a few packages there, you should be able to track them and revert back when you're done
[15:09] <dednick> mzanetti: hm, as far as i can tell, they are added to a target. Although it uses a macro to do it...
[15:18] <mzanetti> dednick: still not working? need help?
[15:18] <dednick> mzanetti: please
[15:19] <mzanetti> ack.
[15:20] <dednick> mzanetti: thanks.
[15:20] <dednick> mzanetti: what actually determines which files are added to project in creator?
[15:21] <mzanetti> dednick: with cmake, I think it's listing everything that's given as source of a target
[15:21] <dednick> mzanetti: the plugins/Unity/Indicators/qml folder is there with the CMakeList.txt file, but there's no other files listse
[15:22] <dednick> mzanetti: hmm. let me try adding files on another target to confirm
[15:24] <mzanetti> dednick: https://code.launchpad.net/~mzanetti/unity8/indicators-qml-to-cmake/+merge/203351
[15:26] <mzanetti> dednick: just pushed again to align it with the rest of the file
[15:28] <dednick> hm. wonder why it doesnt work with the export_qmlfiles macro
[15:28] <dednick> mzanetti: ^ ?
[15:28]  * mzanetti reads
[15:29] <mzanetti> dednick: I don't think it does custom_targets, only real targets
[15:29] <mzanetti> dednick: as custom targets mostly do some command line execution which cmake and qtcreator don't have any clue about
[15:30] <dednick> i c
[15:30] <tsdgeos> fginther: awesome, it fails :-)
[15:30] <mzanetti> dednick: but yeah, we try to could create some no-op but real target inside the macro I guess
[15:30] <tsdgeos> which means NOT_OUR_BUG
[15:30] <tsdgeos> btu still have to fix it :D
[15:31] <mzanetti> ... we could try...
[15:31] <dednick> mzanetti: yup, looking at it now
[15:31] <mzanetti> cheers
[15:33] <fginther> tsdgeos, whew! glad that helped
[15:36] <dednick> mzanetti: hm... there doesnt seem to be a target for the root/qml qml files other than the install target. so...
[15:52]  * tsdgeos does evil eyes to MacSlow and mzanetti
[15:52] <MacSlow> tsdgeos, ?
[15:52] <tsdgeos> your last unity-notifications breaks your notification unit tests in unity8
[15:53] <MacSlow> tsdgeos, outch
[15:53] <tsdgeos> yeah, has been making our CI fail the whole last week and i was blaming CI machines
[15:53] <tsdgeos> just did not understand they used some packages that are not in distro
[15:55] <MacSlow> tsdgeos, so it's got to be r192 of lp:unity-notifications
[15:55] <tsdgeos> 193
[15:56] <mzanetti> oops
[15:56] <mzanetti> tsdgeos: hmmm... does that mean we should run unity8 tests when merging to unity-notifications?
[15:56] <tsdgeos> mzanetti: that means unity-notifications needs better tests :D
[15:57] <MacSlow> mzanetti, tsdgeos: hm
[15:57] <MacSlow> tsdgeos, do you have a link to one such CI-failure handy?
[15:58] <tsdgeos> mzanetti: please build unity-notifications, install it, and then run PYTHONPATH=../tests/autopilot autopilot run unity8.shell.tests.test_notifications.InteractiveNotificationBase.test_sd_incoming_call
[15:59] <MacSlow> tsdgeos, I'll try that on the emulator too
[15:59] <tsdgeos> MacSlow: this is blocking all our CI, do it on your computer, will be faster than messing with the emulator
[16:00] <MacSlow> tsdgeos, doing that too
[16:06] <tsdgeos> mzanetti: MacSlow: https://code.launchpad.net/~aacid/unity-notifications/qcompare/+merge/203362
[16:07] <MacSlow> tsdgeos, mzanetti: ok, I'm onit
[16:07] <mzanetti> cheers
[16:07] <mzanetti> tsdgeos: what exactly caused the fail in here?
[16:07] <tsdgeos> mzanetti: that doesn't fix anything
[16:07] <mzanetti> ah ok
[16:07] <tsdgeos> just makes stuff better
[16:08] <mzanetti> yeah. I agree with that
[16:08] <tsdgeos> MacSlow:
[16:08] <MacSlow> tsdgeos, so it's not fixing the CI-failure you mentioned earlier?!
[16:08] <tsdgeos>          if (!inserted) {
[16:08] <tsdgeos> -            insertToVisible(n, 0);
[16:08] <tsdgeos> +            insertToVisible(n, insertionPoint(n));
[16:08] <tsdgeos>          }
[16:08] <tsdgeos> fixes unittest in unity8 for me
[16:08] <MacSlow> ok
[16:08] <tsdgeos> but breaks unity-notification unittests
[16:08] <tsdgeos> so you have to make them agree :D
[16:09] <MacSlow> tsdgeos, I'll make sure to get this sorted before tomorrow
[16:10] <tsdgeos> tx
[16:19] <om26er> xnox, xnox, is there a way to set a global variable in the environment so that every app that starts with initctl appends that parameter ? talking a parameter thats not a keyword arg
[16:20] <xnox> om26er: can you please tell me what you are trying to do? and is it generic, or upstart-app-launch specific?
[16:22] <om26er> xnox, not sure about the details on what 'initctl start' uses. there is a parameter QT_LOAD_TESTABILITY=1 which if set in the environment starts all the apps with the testability driver load, due to some reason its broken. So there is an alternative parameter '-testability' which is working, So I would like to start my apps with that
[16:23] <xnox> om26er: talk to qa / ci / tedg  about it. check why your environment doesn't have that variable.
[16:24] <xnox> om26er: cause environment variable is supported better, but it also depend on your code.
[16:24] <xnox> om26er: do you have your log, where testability is / isn't loaded?
[16:28] <tedg> om26er, It might be when it gets set, for best results I'd say make a job that is "start on starting dbus" that sets it.
[16:29] <om26er> xnox, where are the upstart logs when an app is started with initctl ?
[16:30] <om26er> tedg, will '-testability' work as well ? I though initctl supported arguments of the form key=arg ?
[16:30] <tedg> om26er, Nope, it doesn't.
[16:31] <tedg> om26er, The app will put logs in ~/.cache/upstart/application*
[16:33] <om26er> xnox, logs when started with upstart http://paste.ubuntu.com/6827040/
[16:34] <om26er> xnox, and with -testability (without upstart) http://paste.ubuntu.com/6826992/
[16:34] <om26er> note the line: Testability driver loaded. Wire protocol version is "1.4".
[16:38] <tedg> om26er, How are you setting the env var?
[16:38] <tedg> initctl set-env --global QT_LOAD_TESTABILITY=1 ?
[16:38] <om26er> tedg, inictl set-env -g QT_LOAD_TESTABILITY=1
[16:38] <om26er> or that
[16:39] <MacSlow> tsdgeos, btw... your fix-suggestion for unity-notifications does cause 2 of the current unit-tests of unity-notifications to fail
[16:39] <tsdgeos> MacSlow: yes, is exactly what i said
[16:39] <tsdgeos> [17:08:31] <tsdgeos> fixes unittest in unity8 for me
[16:39] <tsdgeos> [17:08:40] <MacSlow> ok
[16:39] <tsdgeos> [17:08:40] <tsdgeos> but breaks unity-notification unittests
[16:39] <tsdgeos> [17:08:47] <tsdgeos> so you have to make them agree :D
[16:40] <MacSlow> tsdgeos, hm... guess xchat's scrollback doesn't like me then :)
[16:40] <tedg> om26er, initctl get-env QT_LOAD_TESTABILITY ?
[16:40] <MacSlow> tsdgeos, with current lp:unity8 and lp:unity-notifications only notification-autopilot-tests fail for you?
[16:40] <tsdgeos> no
[16:41] <tsdgeos> well
[16:41] <MacSlow> tsdgeos, ah ok... atm 48 out of 65 fail for me here
[16:41] <tsdgeos> what does "notification-autopilot-tests" mean?
[16:41] <tsdgeos> ah yes, only the one i told you fails
[16:41] <tsdgeos> unity8.shell.tests.test_notifications.InteractiveNotificationBase.test_sd_incoming_call
[16:41] <tsdgeos> MacSlow: how are you running the tests?
[16:41] <MacSlow> tsdgeos, *sigh*
[16:42] <om26er> tedg, that does not work as well. So I just concluded it to be a bug in autopilot somewhere. Apps that are started with qmlscene are loading the testability driver, but the ones that have a c++ binary are showing the issue
[16:42]  * om26er reports a bug for autopilot-qt
[16:43] <MacSlow> tsdgeos, doing the usual compile (and installing unity-notifications via the build .deb), make install in builddir and then starting autopilot
[16:43] <tsdgeos> MacSlow: read the CODING file
[16:43] <tsdgeos> make autopilot
[16:44] <tsdgeos> or you need to properly pass PYTHONPATH stuff around
[16:45] <tsdgeos> mzanetti: have a sec?
[16:51] <karni> mhr3: Can you tell me what you meant by "they stop being centered" comment? https://code.launchpad.net/~unity-team/unity8/new-scopes-fix-grid/+merge/202593
[16:51] <karni> mhr3: Do you mean "it makes things look worse", as opposed to the screenshots?
[16:52] <mhr3> karni, yes, the patch de-centered them
[16:52] <karni> mhr3: ack, thanks
[16:52] <mhr3> karni, but in trunk
[16:54] <om26er> mzanetti, hello
[16:54] <karni> greyback: Hiya. I believe you where the author, allow me to ask - where did the "- spacing/2" come from in qml/Components/ResponsiveFilterGrid.qml columnsForSpacing function?
[16:54] <karni> return Math.max(1, Math.floor((parent.width - spacing/2) / (delegateWidth + spacing)));
[16:54] <greyback> karni: that was a while ago, let me try refresh my memory
[16:55] <karni> greyback: thank you, I'd appreciate
[16:58] <karni> greyback: Two people other than me got convinced it should probably be (parent/(delegateWidth + spacing)) (i.e. nothing should be subtracted from parent width, because that far right spacing would be spread to both margins)
[16:59] <karni> greyback: http://paste.ubuntu.com/6827155/ ~3:50 ago on this channel
[17:00] <mhr3> karni, your formula was correct if the margin assumption was... if margins are 0 it isn't
[17:01] <karni> mhr3: by margins you mean the visual space between a delegate and screen edge, or from the delegate body to delegate edge? (because we assume the deletate contents are center aligned)
[17:02] <greyback> karni: yeah I can't think of a good reason why I subtract the spacing/2
[17:02] <mhr3> oh wait, that space is allocated to the columns anyway, so nevermind
[17:03] <karni> greyback: ack
[17:14] <karni> mhr3: quick question, how did you check that? in a test, or you built it and tried on a device/in a simulator?
[17:14] <karni> the fact that it didn't work with trunk
[17:14] <karni> I'm not assuming it does, I'm just asking to ensure best work flow on my end
[17:17] <mhr3> karni, i merged that one commit you did into trunk
[17:17] <karni> right, and then? :)
[17:33] <karni> mhr3: If you're still around, I was wondering more about the next step :) How you verified that merge to trunk broke it.
[17:50] <mhr3> karni, i just run the scope tool
[17:50] <karni> mhr3: ack
[17:51] <mhr3> in trunk it's talking to old scopes, and not using cards, and was not centered
[17:51] <karni> gotcha, thanks buddy
[18:03] <Cimi> mterry, it still failed, though https://code.launchpad.net/~unity-team/unity8/unity8.test_nested_mir/+merge/203088
[18:04] <Cimi> Saviq, still around?
[18:05] <mterry> Cimi, I think CI tests are having problems right now
[18:14] <Saviq> Cimi, mterry yes, we're getting closer, though
[18:27] <karni> Saviq: How is it possible that Cards delegates (scope-onlinemusic in new-scopes unity-scope-tool) are left-aligned, as it seems, while tiles in unity8 trunk unity-scope-tool are centered? When I manage to center align the Card delegates, the trunk tiles get moved to the right. I feel like someone cheated, stuff is actually shifted/centered in tile delegates, but I can't find it. I'm puzzled.
[18:27] <karni> Either trunk has centered tiles, or new-scopes has centered Cards. Can't make 'em both work.
[18:29] <karni> Saviq: (if you're around) lp:~unity-team/unity8/unity8-fix-grid - rev 653 correctly fixes column count. rev 654 breaks tile alignment (they're shifted to right), but the very same code centers Cards in new-scopes :/
[18:42] <Saviq> karni, isn't this because Cards do not center themselves while old-scopes renderers do?
[18:43] <karni> Saviq: I think so, as you wrote your message - I started to align the Card
[18:43] <karni> yeah, giving this a try
[18:43] <Saviq> karni, align the Card how? within an enclosing Item?
[18:43] <karni> Saviq: yes. would that be fine?
[18:43] <karni> Saviq: delegate: Card -- eek
[18:43] <Saviq> karni, yes
[18:43] <karni> :)
[18:44] <Saviq> karni, problem is there's a loop there
[18:44] <Saviq> karni, delegateHeight/Width: are based on first delegate size
[18:44] <karni> Saviq: well.. first try failed miserably ;) all card positions went haywire. lemme work that.
[18:45] <Saviq> karni, which is a shortcut that we need to get rid of (hence the FIXME in CardFilterGrid)
[18:45] <karni> ack
[18:45] <karni> ah yes, I see it
[18:45] <Saviq> karni, so yeah, we've a chicken'n'egg problem
[18:45] <karni> not good, not good :[
[18:45] <Saviq> karni, the plan for that is to create an invisible Card with dummy data for each category
[18:46] <karni> I really need to get this fixed to get going.
[18:46] <Saviq> karni, to find out its largest possible size
[18:46] <karni> I see..
[18:46] <Saviq> karni, and use that for delegateWidth/Height in the different layouts
[18:46] <karni> So basically I could fix column count, but card spacing/alignment is not that easy.
[18:46]  * karni nods
[18:46] <Saviq> karni, I'll work on that tomorrow morning
[18:47] <karni> Saviq: Appreciated, Michał -- you know where's my branch if you'd like to test it. That's based on unity8 trunk.
[18:47] <karni> I was trying to make it right in trunk, but second commit in that branch works in new-scopes only.
[18:49] <karni> Aha, so I should actually revert that last change, if the problem is in *Card* alignment.
[18:51] <Saviq> karni, yeah, I'd say it is
[18:51]  * karni nod
[18:57]  * greyback eod
[18:58] <karni> If I want to "cancel" my merge proposal, is Deleting it the right thing to do? I left a comment pointing to a different branch and left further explanation, which I assume will be sent to interested parties? https://code.launchpad.net/~unity-team/unity8/new-scopes-fix-grid/+merge/202593
[19:33] <tedg> karni, You can set it to WIP or Rejected as well.
[19:34] <tedg> karni, I'd say "make it informative" for the next person that sees it. :-)
[19:34] <karni> tedg: I've it to Rejected, only later I noticed. That'd be my first time I did it heheh
[19:34] <karni> Right :) Thanks
[20:02] <Saviq> karni, one for you: https://code.launchpad.net/~saviq/unity8/fix-card-header-height/+merge/203411
[20:02]  * karni looks
[20:03] <Saviq> karni, empty labels were taken into account for height calculations
[20:04] <karni> Saviq: slick /me awaits diff :)
[20:04] <karni> Saviq: Since you're here :) https://code.launchpad.net/~unity-team/unity8/unity8-fix-grid/+merge/203399
[20:04] <Saviq> karni, just pushed a trunk merge, so it'll still be there
[20:04] <Saviq> karni, naah, not _really_ here ;)
[20:04] <karni> heheheheh ok
[20:04] <karni> Saviq: what did you mean by "pushed a trunk merge"?
[20:05] <Saviq> karni, my branch did not have latest trunk in (in fact it was a week old or so)
[20:05] <karni> oh, gotcha
[20:05] <karni> thanks, Saviq :)
[20:06] <Saviq> this helps a bit in the layouts as cards are actually their own size as opposed that + two lines of invisible text...
[20:07] <karni> Saviq: It's good to _not_ have invisible views in there hehe
[20:07] <Saviq> karni, indeed
[20:07] <karni> Saviq: fun fact:
[20:08] <karni> Saviq: The fix for column spacing works for new-scopes *and* trunk, if there's 2 columns. If there's 3, margins are too wide (wtf?) and that's why stuff is shifted.
[20:08] <Saviq> karni, yeah, we'll have to look at it properly
[20:09] <karni> I don't know how that relates to column count, the math is there, and makes sense. anyway. I don't want to hold you here :)
[20:09] <karni> I don't plan to leave anytime soon (modulo food)
[20:09] <karni> Saviq: yep
[21:33] <Saviq> mterry, fyi, adding the repo from http://naartjie.ubuntu-ci/archive/head.unity8/trusty/ allowed Albert to reproduce the failures in otto, and there's a fix for lp:unity-notifications in the works
[21:37] <Saviq> mterry, fyi, adding the repo from http://naartjie.ubuntu-ci/archive/head.unity8/trusty/ allowed Albert to reproduce the failures in otto, and there's a fix for lp:unity-notifications in the works
[21:37] <mterry> Saviq, ah interesting.  OK, thanks!
[21:38] <Saviq> mterry, that repo contains all packages built for the unity8 stack (so unity8, unity-notifications etc.) during -autolanding jobs
[21:39] <mterry> Saviq, so like trusty-proposed-proposed?  :)
[22:07] <Saviq> mterry, well, it's meant to allow us coordinate merges within the stacks without release
[22:08] <Saviq> mterry, as the stacks are later released together (or at least were originally)
[22:14] <kgunn> mterry: are you looking into the weird "unstable" otto runs ?
[22:14] <kgunn> i was trying to bug someone/anyone in ubuntu-ci-eng
[22:15] <mterry> kgunn, I was curious about them, but mostly I've been having trouble reproducing a certain jenkins test failure in one of my branches that added a new AP test
[22:18] <kgunn> mterry: cool...i'll go back to bothering ci team :)
[22:19] <kgunn> as its holding up cimi's mp
[22:22] <Saviq> kgunn, Albert found the issue today
[22:23] <Saviq> kgunn, it was r192-193 in https://code.launchpad.net/~unity-api-team/unity-notifications/trunk
[22:23] <Saviq> kgunn, fix was already identified, too
[22:24] <kgunn> Saviq: thanks...i'll stop harping on it...assuming there'll be an mp to address it in the morning
[22:24] <kgunn> Saviq: does it really address all 4 here
[22:24] <kgunn> https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/2304/
[22:26] <Saviq> kgunn, no, but at least two of those are added in that MP
[22:26] <Saviq> https://code.launchpad.net/~unity-team/unity8/unity8.test_nested_mir/+merge/203088
[22:26] <Saviq> so those just need fixing
[22:26] <Saviq> the only persistent failure we got was http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty/2315/
[22:29] <veebers> Saviq: I'm eavesdropping here, I see you're having autopilot test failures. When did that start happening?
[22:29] <Saviq> veebers, last week, a merge in lp:unity-notifications caused it - we had problems reproducing 'cause it was never released, but was there in the local head.unity8 repo
[22:30] <Saviq> veebers, issue identified and will be resolved early tomorrow
[22:30] <veebers> Saviq: ah ok, I ask because a new autopilot was released and entered distro a couple of hours ago. I wanted to make sure it wasn't that ;-)
[22:30] <Saviq> veebers, nah
[23:39] <karni> Saviq: this looks so much better, +1. should I top approve? should you ping mzanett'i to land it? I think there's a new landing process involving adding entries to a gdoc. you might want to ask him.


[15:57] <pitti> hello
[15:57]  * apw waves
[15:57] <Riddelll> why it must be time for another release meeting
[15:57] <apw> could it be, could it be
[15:57]  * fader_ waves.
[15:57] <robbiew> ah....the anticipation
[15:59] <ogra> moop moop
[15:59] <ttx> \o
[15:59] <apw> robbiew, pgraner is on the road, so i am covering kernel
[15:59] <robbiew> 30 sec....wait for it
[15:59] <njpatel> hey hey
[15:59] <marjo> marjo waves
[15:59] <robbiew> oh....15sec
[15:59] <robbiew> lol
[16:00] <robbiew> #startmeeting
[16:00] <MootBot> Meeting started at 09:59. The chair is robbiew.
[16:00] <robbiew> https://wiki.ubuntu.com/ReleaseTeam/Meeting/2009-09-18
[16:00] <robbiew> [TOPIC] Actions from previous meetings
[16:00] <MootBot> New Topic:  Actions from previous meetings
[16:00] <robbiew> I think all are done
[16:01] <robbiew> so moving on
[16:01] <robbiew> [TOPIC] Team Reports
[16:01] <MootBot> New Topic:  Team Reports
[16:01] <cjwatson> cr3: can you confirm that that unaligned pointer bug in grub2 is now fixed for you?
[16:02] <cr3> cjwatson: I'm still getting a problem reported in bug #432497, which I'm not sure whether it's a hardware problem or a compatibility problem
[16:02] <robbiew> cr3: what's the model number?
[16:03] <cjwatson> cr3: ok, entirely separate (and probably not a kernel bug)
[16:03]  * robbiew has an Aspire One
[16:03] <cjwatson> oh, looks like it is a kernel bug actually
[16:03] <fader_> robbiew: It's an A110
[16:03] <cjwatson> that ata driver ain't happy
[16:03] <cr3> robbiew: AOA 110
[16:03] <cjwatson> it's saying "media error" rather a lot
[16:04] <robbiew> okay..I'll check mine...thinks it's different
[16:04] <cjwatson> cr3: so if you can't install, then presumably you do not know whether the grub2 bug is fixed
[16:04] <cr3> cjwatson: but for the sake of this action item, you're right: entirely different. I'm not getting the grub2 problem I was having before anymore
[16:04] <cr3> cjwatson: I could install before, I can't install anymore. so, good point, you're right
[16:05] <robbiew> well since QA is already chatting away
[16:05] <robbiew> [TOPIC] QA
[16:05] <MootBot> New Topic:  QA
[16:05] <robbiew> :D
[16:05] <marjo> hi folks
[16:05] <marjo> * Hardware testing
[16:05] <marjo> We have 2 open bugs against hardware:
[16:05] <marjo> #432497 - unable to install on Acer Aspire One
[16:05] <marjo> #431970 - internal microphone not working on HP Mini Bixby and Toshiba NB100
[16:05] <marjo> There are a couple of netbooks that are untested; Marc Tardif is testing
[16:05] <marjo> these today and will report any bugs found.
[16:05] <marjo> specs status next
[16:06] <cr3> marjo: one of the laptops seems to have hardware problems, so we might need to blacklist it
[16:06] <ScottK> o/
[16:06] <marjo> cr3: ok
[16:06] <marjo> * UbuntuSpec:karmic-qa-increase-apport-adoption
[16:06] <marjo> On Launchpad's edge server any urls that contain +filebug and ubuntu
[16:06] <marjo> in them are now redirected to the https://help.ubuntu.com/community/ReportingBugs wiki page.
[16:06] <marjo> That page encourages bug reporters to use apport for reporting bugs about Ubuntu.
[16:06] <marjo> Further information regarding the change can be found at http://fridge.ubuntu.com/node/1908.
[16:06] <marjo> Multiple data points are currently being monitored to measure the success of the change.
[16:07]  * ScottK has filed multiple bugs about it already
[16:07] <marjo> ok thx
[16:08] <marjo> * UbuntuSpec:karmic-qa-extended-audio-testing
[16:08] <marjo> Extended audio tests are complete. Almost ready to perform the automated audio testing on a daily basis.
[16:08] <robbiew> kewl
[16:08] <marjo> * UbuntuSpec:karmic-qa-metrics-based-testing-phase-2
[16:08] <marjo> cr3 explored Phoronix test definitions and determined appropriate schema to extend the current concept of test results to support their tests
[16:09] <marjo> any Qs on specs?
[16:09] <robbiew> so are they all "implemented"?
[16:09] <robbiew> status wise
[16:09] <marjo> robbiew: yes
[16:09] <robbiew> cool...thnx
[16:09] <marjo> implemented is implied; just reporting current status
[16:10] <marjo> * Alpha 6 test results
[16:10] <marjo> Marjo will send out the full report via email. Here are the highlights.
[16:10] <marjo> Bugs that affected testing effectiveness:
[16:10] <marjo> # 430611 , dbus fails to start on clean boot using upstart job ,
[16:10] <marjo> dbus (Ubuntu) , Critical , Fix Released
[16:10] <marjo> dbus (Ubuntu Karmic) , Critical , Fix Released
[16:10] <marjo> # 431786 , auto-resize fails due to fsck error on superblock ,
[16:10] <marjo> ubiquity (Ubuntu) , High , New
[16:10] <marjo> ubiquity (Ubuntu Karmic) , High , New
[16:10] <marjo> # 427709 , [MIR] insserv ,
[16:10] <marjo> insserv (Ubuntu) , Critical , Fix Committed
[16:10] <marjo> insserv (Ubuntu Karmic) , Critical , Fix Committed
[16:10] <pitti> (insserv is fix released)
[16:11] <robbiew> whoohoo...thnx pitti
[16:11] <marjo> pitti: thx!
[16:11] <marjo> excellent!
[16:11] <marjo> Test Failure Analysis
[16:11] <marjo> 113 test cases were run. 17 of them were marked as FAIL.
[16:11] <marjo> Failure Rate = 15%
[16:12] <marjo> that's all i have unless there's interest in each product line status
[16:13] <robbiew> any questions for QA?
[16:13] <pitti> are many of the failures due to general bugs like boot changes or hw specific?
[16:13] <marjo> pitti: in general yes
[16:13] <pitti> i. e. was a6 a major bug surge due due to that?
[16:13] <marjo> boot changes, e.g.
[16:14] <pitti> "a or b" -> yes .. which?
[16:14]  * ogra grins :)
[16:14] <lool> marjo: I was wondering whether you consider tests against all images we produce for an alpha including superseded ones or just the latest image
[16:14] <marjo> a
[16:14] <pitti> ogra: well, it's logically correct :)
[16:14] <marjo> lool: just the latest images
[16:14] <lool> marjo: I think it would be good to include at least bug stats for previous images
[16:14] <marjo> lool: what's the objective for that suggestion?
[16:15] <ogra> lool wants to see progress :)
[16:15] <lool> I mean I might find a bug in the first image I test and not keep mentionning it in all subsequent respins
[16:15] <marjo> lool: ah, yes
[16:15] <lool> So I might be filing 10 bugs in the first test image and 3 more in the second
[16:15] <ogra> oh, i often do that too
[16:15] <lool> marjo: Ok thanks for considering for next milestone then
[16:15] <ScottK> And if they are fixed, it'll look good.  If they aren't, it's important to know.
[16:15] <marjo> lool: ok i understand; let me work with the team on that
[16:15] <lool> ScottK: exactly
[16:15] <marjo> scottk: agree
[16:16] <robbiew> thanks marjo
[16:17] <robbiew> [TOPIC] Desktop
[16:17] <MootBot> New Topic:  Desktop
[16:17] <pitti> This week we made some good progress in both fixing RC bugs, and also reviewing our list for bugs which should also be RC (that's why we got so many new ones on the list this week).
[16:17] <pitti> The licensing question was settled, we could upload new xsplash artwork and update copyright files for the other artwork related packages. This also unblocks the new usplash artwork, which still needs to get integrated (will take some time to calculate picture positions, etc.)
[16:17] <pitti> Both feature and DX/OLS integration wise we are pretty much done. We'll move to full steam bug fixing mode from now on and will LART anyone who wants to change major things now. :-)
[16:17] <pitti> X-wise, ATI cards should finally work again, they were terribly broken for a while. My gut feeling is that X is again in good shape, there are only some reports about occasional freezes on some intel chips after suspend.
[16:17] <pitti> bug/spec stats and planned changes are on https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus
[16:18] <apw> pitti, were those intel hangs you 'feel' before or after the recent mesa fix?
[16:18] <pitti> apw: they've been there forever
[16:18]  * ogra had them too, and for me they seem to be gone now
[16:18] <apw> that was triggerng a lot of suspend/resume issues
[16:18] <pitti> I filed that upstream
[16:18] <rickspencer3_> apw: so "before"
[16:18] <apw> and should now be fixed
[16:18] <pitti> apw: I tried your kernel, but it didn't fix it
[16:18] <ogra> pitti, mesa
[16:18] <pitti> likewise
[16:18] <apw> the kernel wouldn't have no, it was a mesa bug blowing the gpu
[16:19] <pitti> that mesa (as it is in karmic) with karmic kernel still crashes
[16:19] <pitti> I also get the screen corruptions again, but that's just fixed in apw's test kernel I think
[16:19] <apw> ok do we have a bug for tha tone
[16:20] <pitti> I filed it upstream, yes
[16:20] <pitti> freedesktop bug 23923
[16:20] <pitti> bleh
[16:20] <pitti> they asked me for some debug info
[16:21] <pitti> (why did they make that private?)
[16:21] <apw> perhaps its a security issue
[16:21] <pitti> it wasn't even investigated that far yet
[16:21] <pitti> they asked me to test the patch which you have in your kernel, andn now for gpu/reg dump before/after suspend
[16:22] <pitti> anyway, if someone is interested, I can certainly subscribe them to the bug
[16:22] <apw> please
[16:23] <pitti> done
[16:23] <pitti> yes, they ticked "security/subscribers only"
[16:23] <pitti> any other questions wrt. desktop, to get away from the technical details again?
[16:24] <Riddelll> I have a wee Kubuntu update if wanted
[16:24] <pitti> please
[16:24] <Riddelll> KubuntuKarmicXsplash is done
[16:24] <Riddelll> KubuntuKarmicNetbook got moved to implemented
[16:24] <Riddelll> jockey-kde needs some checking
[16:24] <Riddelll> different install methods need checking: oem config, dvd, upgrade
[16:24] <Riddelll> social from the start components need double checking to make sure they work
[16:24] <Riddelll> and otherwise we're all good
[16:24] <pitti> jockey-kde is misbehaving?
[16:24] <ScottK> apport-kde is problematic too.
[16:24] <pitti> apport-kde is acting up, so I heard; Yuri had a fix, but I didn't seee it yet
[16:24] <Riddelll> pitti: dunno I only tried it once and it didn't work until I installed jockey-gtk
[16:25] <Riddelll> oh yes forgot about apport-kde
[16:25]  * ScottK got it to work in a live environment, but not after install (couldn't find the drivers)
[16:25] <ScottK> (jockey-kde)
[16:26] <robbiew> anything else for Desktop?
[16:27] <robbiew> thanks pitti
[16:27] <robbiew> [TOPIC] DX
[16:27] <MootBot> New Topic:  DX
[16:27] <ScottK> With luck we'll get out final big U/I push for Kubuntu Netbook this weekend
[16:27] <ScottK> (sorry, slow typing)
[16:27] <robbiew> lol..no prob
[16:27] <robbiew> anyone here from DX?  dbarth?
[16:27] <Riddelll> agateau's libindicate 2 support is in for qt/kde bits
[16:27] <davidbarth> sorry, yes, here
[16:28] <davidbarth> the release status report is up at the usual:
[16:28] <ScottK> Updated quassel patches are uploaded too (from upstream git)
[16:28] <davidbarth> https://wiki.ubuntu.com/DesktopExperienceTeam/KarmicReleaseStatus
[16:29] <davidbarth> of note: more fixes to get applications to use the new v2 of the indicator-messages api
[16:29] <pitti> new xsplash yummy
[16:29] <robbiew> whoohoo!
[16:29] <davidbarth> and also more indicator-session fixes to reflect the status of IM clients, even if they are started after the session menu (which was almost always the case...)
[16:30] <robbiew> cool
[16:30] <davidbarth> and xsplash artwork goodness thanks to Jane and the Design team
[16:30] <robbiew> yes!
[16:30]  * robbiew is tired from all the throbber complaints
[16:30] <davidbarth> some nasty crashers with n-osd, that we're still looking into
[16:30] <robbiew> now we will get new ones :)
[16:30] <robbiew> ok
[16:30] <davidbarth> ;)
[16:31] <robbiew> any questions for the DX team?
[16:32] <robbiew> ok, thanks davidbarth
[16:32] <robbiew> [TOPIC] Mobile
[16:32] <MootBot> New Topic:  Mobile
[16:32] <ogra> hey, thats me :)
[16:32] <robbiew> :)
[16:32] <ogra> https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Karmic
[16:32] <ogra> armel:
[16:32] <ogra> - dove images are working and installable now
[16:32] <ogra> - oo.o is in a scary state
[16:32] <ogra> - imx51 successfully made A6 with no arch specific regressions
[16:32] <ogra> - we're having high hopes for the outcome of the kernel sprint ;)
[16:32] <ogra> moblin-remix:
[16:32] <ogra> - currently broken, blocked by a missing upstream, but we have a path forward and things are in progress
[16:33]  * lool thanks ogra for taking up this week's report
[16:33] <lool> [link] https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Karmic
[16:33] <MootBot> LINK received:  https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Karmic
[16:33] <ogra> :)
[16:34] <robbiew> so we're changing the UNR icon theme, huh?
[16:35] <lool> Yeah
[16:35] <robbiew> bug 430277
[16:35] <lool> In jaunty it was the same as desktop
[16:35] <ogra> yes, will need a freeze exception indeed
[16:35] <lool> in karmic we tried using humanity instead of human
[16:35] <lool> but that has many issues
[16:35] <lool> Issues: http://paste.ubuntu.com/273559/
[16:36] <lool> (From a mail to ubuntu-doc@ warning about the change)
[16:36] <robbiew> will that affect the networking indicator?  currently it's hard to tell when you are and are not connected to wifi
[16:36] <lool> robbiew: it will work the same as in the Ubuntu Desktop Edition once we revert back to Human
[16:36] <lool> robbiew: So yes it will fix that bug
[16:36] <robbiew> nice
[16:36] <pitti> (the ethernet icon is ugly as well, asking design team now)
[16:37] <ogra> ++
[16:37] <robbiew> lol
[16:37] <apw> its wider too so things shuffle
[16:37] <robbiew> you know it's a solid product when we start complaining about the ethernet icon :P
[16:38] <pitti> it looks more like a Pacman ghost than an ethernet thingy
[16:38] <pitti> robbiew: the polish, man, the polish! :-)
[16:38] <ogra> yeap, absolutely
[16:38] <robbiew> indeed!
[16:38] <robbiew> okay...anything else for or from Mobile?
[16:39] <lool> apw: ack
[16:39] <pitti> mpt| pitti, ivanka and kwwii are going to sort it.
[16:39] <pitti> screw boot failures, we get nice icons back!
[16:39] <robbiew> lol
[16:39] <pitti> (SCNR)
[16:40] <robbiew> thnx ogra
[16:40] <robbiew> [TOPIC] Kernel
[16:40] <MootBot> New Topic:  Kernel
[16:40] <apw> ..
[16:40] <apw> Overall kernel team status is summarised at the URL below, including the bugs called out in the agenda.  There are a number of arm bugs listed most of which appear to be on progress for resolution.  The other new ones are rfkill and hotkey related.
[16:40] <apw> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Karmic
[16:40] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Karmic
[16:40] <apw> In the last week a number of regressions have been nailed which were affecting Intel graphics corruption and hangs.  We have also closed out a large number of suspend/resume regressions related to the GPU hangs, as well as to bluetooth and GSM support.
[16:41] <apw> All the items which impact the distro release schedule seem to be basically complete, mostly little pieces incomplete.  ARM continues to progress with the imx51 branch now up to v2.6.31 and integrating the latest updates from Freescale.  We continue to target regression-potential bugs.
[16:41] <apw> ..
[16:41] <robbiew> questions for Kernel?
[16:42] <robbiew> cool...thanks apw
[16:42] <robbiew> [TOPIC] Server
[16:42] <MootBot> New Topic:  Server
[16:42] <ttx> o/
[16:42] <robbiew> ttx: sorry...but added a few more bugs to the agenda late
[16:42] <ttx> https://wiki.ubuntu.com/ServerTeam/ReleaseStatus was refreshed a couple seconds ago
[16:43] <ttx> to try to cover for the very late agenda changes :P
[16:43] <robbiew> they were tagged eucalyptus and milestoned...but not targeted
[16:43] <ttx> I think I did that. Let's see
[16:43] <robbiew> if that was on purpose...then feel free to untarget
[16:43] <ttx> 418130: Karmic EC2 images don't use a karmic kernel is now completed
[16:44] <ttx> with aklpha6 release, we are using a karmic kernel on our EC2 images.
[16:44] <robbiew> whoohoo!
[16:44] <robbiew> that's a big accomplishment...good work guys
[16:44] <ttx> thanks to everyone involved in that.
[16:44] <robbiew> kudos to rtg
[16:44] <apw> and jj
[16:45] <ttx> the other bugss are all mentioned on the status page.
[16:45] <ttx> we already fixed (or committed fixes for) a couple
[16:45] <ttx> that said, there are still plenty to fix, plus probably some others that are critical and unreported.
[16:46] <ttx> I intend to work on that first-user-experience eucalyptus bugs next week, time permitting
[16:46] <ttx> to make sure the bugs reflect what we really need to fix to make it usable.
[16:47] <ttx> About alpha6, we had an issue with the AWS page content at the last minute
[16:47] <robbiew> heh
[16:47] <ttx> with the few people having the keys to that kingdom not present
[16:47] <ttx> I think we need to have one release team member empowered with this mythical key
[16:48] <ttx> to make sure it doesn't happen again
[16:48] <cjwatson> where is that - on www.ubuntu.com or elsewhere?
[16:48] <robbiew> there was discussion of adding someone from the server team to the release team
[16:48] <ttx> cjwatson: it's an EC2 account
[16:48] <robbiew> elsewhere...Amazon
[16:49] <ttx> all in all we are trying to finalize the EC2 release process for beta
[16:49] <ttx> and automate it as much as possible
[16:50] <robbiew> I figured we would just make smoser carry a pager and laptop with 3G :P
[16:50] <ttx> robbiew: that would do it as well.
[16:50] <robbiew> any questions for Server?
[16:51] <robbiew> thanks ttx
[16:51] <robbiew> [TOPIC] Security
[16:51] <MootBot> New Topic:  Security
[16:52]  * robbiew added this one...figure they deserve their own topic ;)
[16:52]  * jdstrand feels slightly unprepared
[16:52] <robbiew> no worries
[16:52] <ttx> jdstrand: it always feels like that.
[16:52] <jdstrand> and by 'slightly' I mean totally
[16:52] <jdstrand> robbiew: what are you lokking for here?
[16:52] <jdstrand> looking
[16:53] <ogra> more safety ?
[16:53] <ogra> locks and chains ?
[16:53] <robbiew> current status on bugs targeted for the release
[16:53] <jdstrand> ah
[16:53] <robbiew> any blueprints that are still not implemented
[16:53] <robbiew> that's it
[16:53] <jdstrand> well, afaik, all our features are either in or deferred
[16:53] <robbiew> cool and I only saw bug 429872
[16:53] <jdstrand> mdeslaur has a FFe out for his apache2 profile
[16:54] <robbiew> ah, okay thnx
[16:54] <jdstrand> robbiew: jj is handling that one
[16:54] <robbiew> cool
[16:54] <robbiew> anyone have questions for the Security team?
[16:54] <robbiew> do you feel safe?
[16:54] <robbiew> :P
[16:54] <jdstrand> there are some libvirt/apparmor integration bugs that I am working on, but I'll fix these once I get my upstream patch finished and rebase the libvirt patch on it
[16:55] <robbiew> okay...are those targeted to Karmic?
[16:55] <jdstrand> I uploaded a workaround for bug #431090 this morning, but it needs the real fix
[16:56] <jdstrand> robbiew: these only just came up this morning, so I need to file the bugs
[16:56] <jdstrand> I have a plan to fix them, and know how, just need to do it
[16:56] <robbiew> ack...hmm...so is "Fix released" the real state then (for 431090)
[16:56] <jdstrand> robbiew: it is for 'eucalyptus VMs'
[16:56] <robbiew> ah
[16:56] <robbiew> okay
[16:57] <ScottK> Sounds like jdstrand needs fewer meetings ...
[16:57] <ScottK> ;-)
[16:57] <jdstrand> robbiew: but it isn't for other people specifying a kernel, serial console or initrd
[16:57] <robbiew> jdstrand: okay, thanks
[16:58] <jdstrand> robbiew: anyhoo, I have gotten feedback from my upstreaming work, and when I do that, this will magically be fixed
[16:58] <robbiew> sounds good
[16:58] <robbiew> [TOPIC] Foundations
[16:58] <MootBot> New Topic:  Foundations
[16:59]  * robbiew scrolls through the recent boot bugs :/
[16:59] <cjwatson> https://wiki.ubuntu.com/FoundationsTeam/ReleaseStatus/Karmic just updated; I won't enumerate all the bugs here, as we just gained a lot thanks to Robbie running the meeting and dumping on his own team. ;-)
[16:59] <cjwatson> Some held-over grub2 bugs, ditto eucalyptus, and some more causes of filesystem timestamps being wrong and causing spurious fscks.
[16:59] <cjwatson> Most current bugs are related to the boot extravaganza that landed on Tuesday; the landing was a bit rough but it has mostly settled down now. The remaining problems are largely from people with complex filesystem setups which mountall doesn't quite handle yet, and we're continuing to work on those.
[16:59] <cjwatson> Regarding boot performance, the reference machine is now 7 seconds faster; some cases like ogra's ARM board are very substantially faster, on the order of 45 seconds; some cases have not been sped up at all yet, but at least we have a better foundation for future work now (the 10-second target is for 10.04).
[16:59] <robbiew> heh
[16:59] <cjwatson> Wubi is still not quite working with grub2, but we're very close.
[17:00] <cjwatson> (EOF)
[17:00] <robbiew> there are some instances of slower boots with slow HDDs...however Keybuk is on top of those
[17:00] <robbiew> sreadahead needs "tweaking" ;)
[17:01] <cjwatson> oh, yeah, there's an sreadahead bug in the status
[17:01] <robbiew> questions for Foundations?
[17:02] <pitti> sreadahead> seems it's not doing anything at all here
[17:02] <pitti> which might explain the boot time increase?
[17:02] <ogra> pitti, run top directly after boot on a slow machine :)
[17:02] <pitti> I know, it's running for minutes without using any CPU or I/O
[17:02] <ogra> it runs quite long and eats 60-98% CPU
[17:02] <robbiew> bug 432089
[17:03] <ogra> yeah
[17:03] <cjwatson> it is *intended* to be useful on hdds
[17:03] <cjwatson> but yeah, not working quite so well just now
[17:03] <robbiew> when I last spoke to Keybuk, he said it had to do with the kernel stopping the I/O
[17:04] <robbiew> because it was too much (during the sreadahead profiling)
[17:04] <ogra> we should just switch from CDs to SSDs on shipit
[17:04] <ogra> solves all size probs as well ;)
[17:05] <robbiew> he had an idea about working around it...was going to discuss with gregkh next week at Plumbers
[17:05] <robbiew> thnx cjwatson
[17:05] <robbiew> [TOPIC] MOTU
[17:05] <MootBot> New Topic:  MOTU
[17:05] <ScottK> o/
[17:06] <ScottK> I think we got our last transition close to done.
[17:06] <ScottK> The various clutter packages landed way out of sync.
[17:06] <ScottK> FFe for that is approved and moving along nicely.
[17:06] <robbiew> ok
[17:06] <ScottK> The biggest concern is still the FTBFS rate on the rebuild test.
[17:06] <ScottK> https://edge.launchpad.net/ubuntu/+archive/test-rebuild-20090909/+packages
[17:07] <ScottK> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909.html
[17:07] <MootBot> LINK received:  http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909.html
[17:07] <ScottK> It's running above 10% and that's pretty scary.
[17:07] <ScottK> We did have the training session last week and that helped.  Another is sched for today.
[17:07]  * sistpoty|work hides
[17:07] <ScottK> A fair number of FTBFS fixes are appearing in the sponsorship queue.
[17:08] <ScottK> I'd like to ask people to try and get those into the archive asap when they are sponsoring.
[17:08] <ScottK> IMO this is a big deal for post-release supportability.
[17:08] <jdstrand> imo too
[17:08] <sistpoty|work> *nod*
[17:08] <ScottK> I also note that the IA64 buildd's are still dead due to dbus needing to be ported to ia64.
[17:09] <cjwatson> fwiw I always go for build failures first since they tend to be easy as well
[17:09] <ScottK> I don't think anyone in the community is up for that.
[17:09] <ScottK> I think either Canoncial needs to allocate resources to fix it (it may be planned, I don't know) or we need to kill the port.
[17:09] <ScottK> For similar reasons ....
[17:10] <ScottK> That's all I have.
[17:10] <sistpoty|work> do we have access to an ia64 box somewhere?
[17:10] <sistpoty|work> we==community, sorry
[17:10] <ScottK> Not that I know of.
[17:10] <sistpoty|work> bleh, that looks even sillier
[17:10] <sistpoty|work> :/
[17:11]  * sistpoty|work doesn't have anything to add
[17:11] <ScottK> There is a silo patch for sparc waiting for sponsorship that might get DI built on sparc for once.
[17:11] <ScottK> It'd be nice to get that in too.
[17:11]  * ScottK just remembered.
[17:12] <robbiew> questions for MOTU?
[17:13] <cjwatson> I *may* be able to have a look at dbus on ia64 in my (ha ha) spare time, but can't promise anything
[17:13] <robbiew> lol
[17:13] <sistpoty|work> thanks cjwatson :)
[17:13] <robbiew> [ACTION] cjwatson to *possibly* look at dbus on ia64
[17:13] <MootBot> ACTION received:  cjwatson to *possibly* look at dbus on ia64
[17:14] <robbiew> thanks ScottK
[17:14] <bittin_> is the Edubuntu meeting atm?
[17:14] <robbiew> no
[17:14] <robbiew> anything else from anyone else? :)
[17:15] <robbiew> #endmeeting
[17:15] <MootBot> Meeting finished at 11:15.
[17:15] <robbiew> 15min back to ya!
[17:15] <bittin_> ah its Karmic meeting as i don't run Karmic i should shut up =)
[17:16] <ScottK> It was the release team meeting.
[17:16] <lool> thanks
[17:16] <ogra> thanks#
[17:16] <sistpoty|work> thanks
[17:17] <pitti> thanks everyone
[18:10] <ace_suares> meeting edubuntu ?
[18:11] <ace_suares> #startmeeting
[18:11] <MootBot> Meeting started at 12:11. The chair is ace_suares.
[18:11] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[18:11] <highvoltage> Good evening.
[18:11] <alkisg> Good evening everyone
[18:11] <ace_suares> {TOPIC] roll call
[18:11] <MootBot> New Topic:  roll call
[18:12] <highvoltage> Well I guess it's the 3 of us
[18:13] <ace_suares> PRESENT
[18:13]  * highvoltage
[18:14] <highvoltage> ace_suares: I'm in a slight hurry so I'll just jump with what I need to say, ok?
[18:14] <ace_suares> hmm seems the mootbot only sees highvoltage.. alkisg not..
[18:14] <ace_suares> okay
[18:14] <highvoltage> We have an alpha build!
[18:14]  * alkisg remains hidden :)
[18:14] <highvoltage> our first one, actually
[18:14] <highvoltage> should've been #6
[18:14] <alkisg> PRESENT
[18:14] <ace_suares> [TOPIC] Edubuntu Alpha build (DVD)
[18:14] <MootBot> New Topic:  Edubuntu Alpha build (DVD)
[18:15] <highvoltage> if my internet connection was a little bit slower yesterday we wouldn't have an edubuntu release for karmic
[18:15]  * ace_suares applaudes highvoltage to have made that DVD !
[18:15] <highvoltage> that's quite scary, so we need to have more testers on call for the next milestones
[18:15] <ace_suares> PRESENT
[18:15] <highvoltage> ace_suares: I didn't make it, I just tested it. if no one tests it, the release manager doesn't release it
[18:15] <highvoltage> ace_suares: the build system builds them every day
[18:16] <ace_suares> highvoltage: oh! didn't know that. As you know my intartubesnetweb is VERY slow and it's a hell to download and test.
[18:16] <ace_suares> I'm so glad you did.
[18:16] <highvoltage> The disc is in quite a good shape currently
[18:16] <ace_suares> Laserjock told that he has it down to 3.2 GB so that's good!
[18:16] <highvoltage> the biggest problems I noticed was things that will get fixed from the ubuntu side anyway
[18:16] <highvoltage> we'll have to put some work into artwork and making it look nicer for karmic+1, imo
[18:17] <highvoltage> I couldn't download the amd64 iso in time, my internet connection was just too slow to get it down in time
[18:17] <ace_suares> so there won;t be a release for amd64?
[18:17] <highvoltage> so we might not have an amd64 release, we have to check on that whether it's possible
[18:17] <ScottK> BTW, once you've downloaded one, you can use rysnc to update your image without having to redownload the entire ISO.
[18:17] <ace_suares> right
[18:18] <ace_suares> ScottK: rsync or zsync?
[18:18] <highvoltage> ace_suares: probably not. maybe we can have an exception since it shares so much with the ubuntu dvd and if we test it properly now
[18:18] <ScottK> I know rsync works.
[18:18] <highvoltage> ScottK: I used rsync, there's still a big diff between the i386 and amd64 dvd images
[18:18] <ace_suares> ScottK: okay I'll try hat I used zsync but it segfaulted!
[18:18] <ace_suares> hat=that
[18:18] <ScottK> highvoltage: True, but if you download early and rsync regularly it's not so hard to keep up.
[18:19] <ScottK> It doesn't matter so much then if you have a slow link.
[18:19] <ace_suares> si what's the next step for testing?
[18:19] <highvoltage> ScottK: indeed, we had *massive* changes yesterday, so I had to sync almost half of the DVD for i386 and I have just a 4mbit DSL line
[18:20] <ace_suares> *just* 4Mb !? wow. I have 'just' 256k most of the time..!
[18:20] <highvoltage> ace_suares: https://wiki.ubuntu.com/KarmicReleaseSchedule
[18:20] <ace_suares> there's this page: https://wiki.edubuntu.org/EdubuntuTesting
[18:20] <highvoltage> ace_suares: the beta release is on 1 October
[18:21] <ace_suares> Where can we look at the seeds?
[18:21] <highvoltage> ace_suares: we'll have to test the images built for that to have it released as beta images
[18:21] <ScottK> If you want to have a amd64 beta, I'd suggest asking the release team to set up the ISO tracker for a special Edubuntu test and get one through the test cycle in advance of the actual beta.
[18:21] <highvoltage> ace_suares: https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/edubuntu.karmic
[18:21] <ace_suares> [ACTION] test for BETA release way for 1 oct
[18:21] <MootBot> ACTION received:  test for BETA release way for 1 oct
[18:22] <highvoltage> ScottK: that's a very good idea, thanks, we'll do so
[18:22] <cjwatson> ace_suares: IIRC zsync sometimes has a bit of trouble with DVD-sized images
[18:22] <ace_suares> [ACTION] If you want to have a amd64 beta, I'd suggest asking the release team to set up the ISO tracker for a special Edubuntu test and get one through the test cycle in advance of the actual beta.
[18:22] <MootBot> ACTION received:  If you want to have a amd64 beta, I'd suggest asking the release team to set up the ISO tracker for a special Edubuntu test and get one through the test cycle in advance of the actual beta.
[18:23] <ace_suares> [IDEA] then put a note of that on the cdimage site, it advertises zsync now. Advertise rsync instead. Maybe a wiki page must be made for it!
[18:23] <MootBot> IDEA received:  then put a note of that on the cdimage site, it advertises zsync now. Advertise rsync instead. Maybe a wiki page must be made for it!
[18:23] <highvoltage> we'll have to start looking at the todo items for the release as well. release notes, updating the website, updating installation information (since that will work differently now)
[18:24] <ace_suares> [PRESENT]
[18:24] <highvoltage> I suppose more people already use rsync as apposed to zsync currently
[18:24] <highvoltage> s/suppose/think/
[18:25] <ace_suares> highvoltage: but it says use zsync and that's a wrong advice - if indeed zsync can not handle large images.
[18:25] <highvoltage> ok, feel free to take it up :)
[18:26] <ace_suares> https://wiki.edubuntu.org/Edubuntu/WikiSite/Release/9.10/Tasks
[18:26] <ace_suares> any more on the dvd!?
[18:26] <highvoltage> I have to leave in about 3 minutes, but basically we're more or less ok now for the first time this release
[18:26] <ace_suares> great work, thaks highvoltage
[18:26] <highvoltage> we can probably squash a few bugs still, and we can improve things website/documentation/community wise somewhat
[18:26] <ace_suares> ..and LaserJock
[18:27] <ace_suares> [TOPIC] Weekly updates
[18:27] <highvoltage> I think we should schedule a meeting when he can at least connect using one of the freenode web interfaces from work
[18:27] <MootBot> New Topic:  Weekly updates
[18:27] <ace_suares> [TOPIC] meeting schedule
[18:27] <MootBot> New Topic:  meeting schedule
[18:27] <highvoltage> or perhaps we can even do an impromptu meeting when he pops in again
[18:27] <ace_suares> just go ahead and reschedule the meetings, highvoltage
[18:28] <highvoltage> ace_suares: ok
[18:28] <highvoltage> well, thank you ace_suares and alkisg, I need to be off
[18:28] <ace_suares> [ACTION] highvoltage reschedules meeting so LaserJock can be there
[18:28] <MootBot> ACTION received:  highvoltage reschedules meeting so LaserJock can be there
[18:28] <alkisg> thanks highvoltage!
[18:28] <ace_suares> bye highvoltage
[18:28] <highvoltage> (and thanks ScottK and cjwatson for feedback as well)
[18:28] <highvoltage> bye!
[18:29]  * sbeattie is using zsync to download dvds off of cdimages, and modulo one recent bug fix, it works.
[18:29] <ace_suares> [TOPIC] zsync
[18:29] <MootBot> New Topic:  zsync
[18:29] <ace_suares> sbeattie: I used zsync to download the iso, and then when I wanted to update, it segfaulted.
[18:29] <ace_suares> so you are saying zsync is safe to use?
[18:30] <sbeattie> ace_suares: it is in karmic
[18:30] <ace_suares> sbeattie: i might have an older version then
[18:31] <ace_suares> does anyone have other points he or she wants to talk about?
[18:31] <sbeattie> ace_suares: bug 420931 recently fixed in karmic, which is where I was seeing segv's when updating dvds.
[18:31] <ace_suares> sbeattie: thanks
[18:32] <ace_suares> sbeattie: we could use a backport then :-)
[18:32] <ace_suares> we are trying to test the 9.10 dvd but with our OS being 9.04 or lower and that does have that bug.
[18:33] <sbeattie> ace_suares: a backport should be trivial, an SRU might be a little more work.
[18:33] <ace_suares> sbeattie: way over my head :-)
[18:34]  * sbeattie will look into it.
[18:34] <ace_suares> [ACTION] sbeattie will look into backporting zsync to 9.04 so we can reliably use it to test Edubuntu DVD's. rsync also works as a workaround.
[18:34] <MootBot> ACTION received:  sbeattie will look into backporting zsync to 9.04 so we can reliably use it to test Edubuntu DVD's. rsync also works as a workaround.
[18:36] <ace_suares> thanks sbeattie for fixing rsync!
[18:36] <ace_suares> sorry zsync
[18:43] <ScottK> sbeattie: Feel free to ping me when you need backport approval.
[18:51] <ace_suares> 10 minutes left, any more points?
[18:57] <ace_suares> closing the meeting
[18:57] <ace_suares> #endmeeting
[18:57] <MootBot> Meeting finished at 12:57.
[18:59] <alkisg> Thank you ace_suares :)
[19:01] <ace_suares> Epharisto, alkisg
[19:01] <alkisg> ;)
[20:55] <alsroot> hi all
[22:00] <flint> Is Edubuntu meeting here now?
[22:06] <flint> Did I get the time or date wrong for the Edubuntu meeting?
[22:25] <flint> highvoltage, Jonathan, when does the Edubuntu meeting start?  I have some great news!
[22:27] <flint> Listen folks, my wife ran out of gasoline on the road, so I gotta go rescue her.  I would like to introduce to the Edubuntu community ALSROOT.
[22:28] <flint> Alsroot has completed the port of sugar to ubuntu!!!!!!  I wish I could stay for the meeting, but duty (or my wife) calls!
[22:29] <flint> alsroot, I will be here just not online. Tell the nice folks in this community how you have just set education on ubuntu on fire.  Thanks for being here!
[22:30]  * alsroot hanging around all time
[23:28] <ScottK> flint and alsroot: You missed the meeting by ~4 hours.
[23:28] <alsroot> heh