[08:37] <mhr3> Saviq, ok for me to build new scopes stuff in ppa:unity-team/ppa?
[08:37] <mhr3> Saviq, want to have latest stuff available for trusty
[09:03] <mhr3> Saviq, re the no form factor thing - ultimately you still have "currentShellConfiguration", don't you? that is enough for us
[09:03] <mhr3> we don't care how you make the decision
[09:03] <mhr3> and if that doesn't match the device type... we don't care
[09:22] <Saviq> mhr3, you won't be able to build u8 on trusty without new qt package names
[09:23] <Saviq> mhr3, wth is "currentShellConfiguration"? ;)
[09:25] <mhr3> Saviq, i just want scopes, trusty u8 will have to be enough for now :)
[09:26] <mhr3> and it's whatever layout type your smart thing + user decided to use
[09:28] <Saviq> mhr3, grep comes up empty ;), or is that in the API simply?
[09:29] <mhr3> Saviq, that's what i just decided to call it now
[09:29] <mhr3> Saviq, as i said ^^ shell's current layout
[09:29] <Saviq> mhr3, yeah, we'll need to come up with a proper name for that
[09:29] <Saviq> mhr3, I'd leave it be formFactor for now
[09:30] <mhr3> a bit misleading, but fine by me
[09:30] <Saviq> mhr3, the values will be different anyway, so we'll deprecate that part of the API in due time
[09:30] <Saviq> mhr3, and introduce a new, proper one for the new thing
[09:30] <mhr3> Saviq, any clue already what the new values will be?
[09:31] <mhr3> or what they'll look like?
[09:31] <mhr3> will it be things like "touch-optimized" etc?
[09:34] <Saviq> mhr3, if I have my way, it will be touch, windowed, 10feet, or some such
[09:34] <Saviq> mhr3, names TBD
[09:34] <mhr3> k
[09:34] <Saviq> mhr3, we're sending frameworks to the store atm anyway, right?
[09:35] <mhr3> no idea
[09:35] <mhr3> pstolowski, ^?
[09:35] <Saviq> mhr3, so for the most important thing - apps - form factor or The Other Thing™ is not enough anyway
[09:35] <pstolowski> Saviq, yes, we do
[09:35] <Saviq> so TBH I'd drop formFactor from the API sooner rather than later
[09:36] <mhr3> but that'd be api break :P
[09:44] <Mirv> Saviq: will tsdgeos be around today? I built the 5.3 qtdeclarative with delegate patch and the tsdgeos' unity8 branch, but I'm getting just a crash loop over there
[09:44] <Saviq> Mirv, no, he's out
[09:45] <Saviq> Mirv, ok, let's leave it until Monday then
[09:45] <Saviq> Mirv, maybe we'll get feedback upstream
[09:45] <Mirv> on 5.2 with the backported qtdeclarative patch and the same unity8 branch I have stuff running, although there might be something wrong (I've only just started tests, but a _lot_ of UI Toolkit tests failed, unless my cats interfered or something)
[09:46] <Saviq> Mirv, ah, so it could be 5.3 specific then?
[09:46] <Mirv> Saviq: well the crash thing yes. it just may be that it's faulty also on 5.2.
[09:47] <Mirv> Saviq: for reference, qt5-beta2 has the "normal" stuff still regarding 5.3 (unity8 starts, but scopes broken), while qt5-daily has the same otherwise but updated qtdeclarative + unity8
[09:47] <Saviq> Mirv, ok thanks
[09:48] <Saviq> seb128, bug #1320160
[09:50] <seb128> Saviq, thanks ... likely not our bug, that code didn't change since january and was working fine
[09:50] <seb128> but I can try having a look at what change
[09:50] <seb128> likely qt
[09:52] <Saviq> seb128, k
[10:01] <Saviq> dednick, https://code.launchpad.net/~saviq/unity8/cmake-plugin-cleanup/+merge/218171 Approved → Needs Review for a reason?
[10:02] <dednick> Saviq: i switched to Approved, but there's still alberts review pending.
[10:02] <dednick> so i switched back
[10:03] <Saviq> dednick, he only complained about a conflict ;)
[10:03] <Saviq> but yeah, your call
[10:03] <dednick> Saviq: "Are the approvals equal to or greater than the disapprovals?"  -NO!
[10:03] <dednick> :)
[10:03]  * Saviq kicks the bot :P
[10:04] <Saviq> it should be working this morning
[10:04] <dednick> Saviq: couldnt be bothered. just approved it
[10:04] <Saviq> ;)
[10:12] <pete-woods> Cimi: just letting you know that I revised the path that the fake json file needs to go in
[10:12] <pete-woods> Cimi: instead of the cache directory (naughty pete), the hooks are supposed to install stuff in ~/.local
[10:13] <pete-woods> so you'll now need to create ~/.local/share/libusermetrics/sources/foo.json instead
[10:28] <Cimi> pete-woods, thanks
[11:23] <mt_caret> Is anybody here?
[11:24] <mt_caret> I'm new to IRC, but I problems with unity, it'll be great if someone could help me
[11:24] <mt_caret> *I have problems
[11:26] <mt_caret> anyone?
[11:26] <Saviq> mzanetti, you said there was still an issue with short appid, greyback just ACK'ed the branch, so what's the deal?
[11:26] <Saviq> mt_caret, just ask your questions
[11:26] <mt_caret> k, well I just booted and the launcher was gone.
[11:27] <mt_caret> so I switched to a terminal and started ccsm
[11:27] <greyback> Saviq: I approved the unity8 changes because they're good. It's unity-mir which needed fixing. I pushed fix for it, we're testing it now
[11:27] <mt_caret> checked all the options, but nothing happened.
[11:27] <Saviq> greyback, kk
[11:27] <mzanetti> Saviq: packages building, testing soon
[11:27] <Saviq> mt_caret, if you press against the left edge, does it show up?
[11:27] <mt_caret> nope
[11:27] <mt_caret> well, I tried unity from the command line, and it failed
[11:28] <mt_caret> saying compiz couldn't load opengl
[11:28] <mt_caret> even though ccsm says its on.
[11:28] <mt_caret> but then when I just executed 'compiz'
[11:28] <mt_caret> opengl loads normally, and I get a unity launcher
[11:28] <Saviq> mt_caret, if you log in to the guest session from the greeter, does everything work?
[11:29] <mt_caret> haven't tried that, I'll check...
[11:34] <mt_caret> just tried it out, and it looks like i do get unity in the guest session
[11:35] <mt_caret> btw, exec unity, then ctrl-c and then compiz gets my launcher back, but without any of the indicators in the top right
[11:36] <Mirv> ok there was something wrong with my previous AP run, now UITK passed this time
[11:42] <mt_caret_> oh, and I also can't launch the terminal emulator after getting a launcher, it disappears in a flash
[11:48] <greyback> Saviq: gentle reminder: https://code.launchpad.net/~gerboland/unity-mir/fix-upstart-closed-apps2/+merge/218721 :)
[11:48] <Saviq> greyback, on it right now
[11:48] <greyback> Saviq: thanks
[11:48] <Saviq> greyback, only just found that unity8 crashes under wrong locale so want to file a bug on that first
[11:49] <Saviq> well, aborts, not crashes
[12:21] <mhr3> saviq, btw will you add the scope-tool update to any of your u8 landings, or are you excepting me to do it?
[12:21] <Saviq> mhr3, I will
[12:21] <mhr3> k, ty
[12:21] <Saviq> mhr3, might not be today, Monday latest
[12:22] <mhr3> i waited a week, can do one more day :P
[12:22] <Saviq> mhr3, pfft! it only got approved... 3 days ago ;P
[12:23] <Saviq> mhr3, it's mzanetti's and greyback's fault! I tell you!, they've been hogging a unity8 silo for 3 days now!
[12:23] <mzanetti> and still hogging it
[12:23] <mhr3> saviq, tell them off then, you're their lead! :)
[12:23] <Saviq> mhr3, good news is that there's no more manual intervention required to migrate unity8 from -proposed
[12:24] <Saviq> mhr3, hint hint, I just did! ;D
[12:24] <mhr3> saviq, too subtle :)
[12:24] <mzanetti> yes. too subtle
[12:25] <mzanetti> no seriously... we're working on it... but we shouldn't land it before issues are fixed
[12:26] <Saviq> mzanetti, no indeed, but we might need to switch it into override mode, when we can land stuff in parallel
[12:26] <Saviq> mzanetti, or get it out of the silo for that matter, until you confirmed fixes locally
[12:26] <mzanetti> Saviq: what's the issue actually?
[12:26] <mzanetti> Saviq: why can't we have multiple silos?
[12:27] <Saviq> mzanetti, because you have to serialize *somewhere*
[12:27] <Saviq> mzanetti, and currently silos are where we try to serialize
[12:27] <mzanetti> ah I see
[12:27] <Saviq> mzanetti, i.e. a single component in-flight in multiple silos is meant to be an exception, not a rule
[12:27] <mzanetti> mhm... ok
[12:27] <Saviq> because then you land one of them and have to rebuild / retest the rest anyway
[12:28] <mzanetti> I really hope we have it soon. but just found another issue in what I thought would be the last test run. but fix already committed and its rebuilding
[12:30] <Saviq> mzanetti, FWIW, it actually takes longer to rebuild in silo than cross-build locally
[12:30] <mzanetti> yeah... you might be right there
[12:31] <mhr3> saviq, but setting up and keeping cross-building working... :(
[12:31] <Saviq> mhr3, huh?
[12:31] <Saviq> mhr3, if we don't use it, it won't work, that's how it is
[12:31] <Saviq> mhr3, not the other way around
[12:32] <mhr3> true, but it still feels overly complicated
[12:32] <mhr3> i can't imagine regular developers actually doing it, and somehow we expect them to
[12:32] <mzanetti> I tend to agree with that
[12:32] <Saviq> mhr3, "click chroot create foo"
[12:32] <Saviq> mhr3, that's what regular developers do
[12:32] <Saviq> mhr3, *we* need a bit more for dpkg reasons
[12:33] <Saviq> mhr3, and what's more, click chroot support is integrated into qtcreator
[12:33] <mzanetti> yep, true. there's definitely progress
[12:33] <mzanetti> altough I haven't managed to use it from qtcreator yet.
[12:34] <mzanetti> haven't send too much time trying tho
[12:34] <Saviq> mhr3, mzanetti, it's a 15-minute set-up time for multi-hour savings over the course of a cycle... really?
[12:34] <mzanetti> spend
[12:34] <Saviq> spent
[12:34] <mzanetti> :D
[12:34] <mzanetti> I have the sbuild thing running...
[12:34] <mhr3> saviq, yea, i noticed, but honestly when i tried to build an app that used a lib that we have in archive but isn't qt, i couldn't figure out how i'd do that
[12:34] <mzanetti> and I even use it sometimes
[12:35] <Saviq> mhr3, right, BYOB is still a problem
[12:35] <Saviq> mhr3, but is a problem whether you're cross-building or not
[12:35] <mhr3> BYOB?
[12:35] <Saviq> bring your own binaries
[12:36] <mhr3> yea, but apps are pretty useless without those :)
[12:36] <mhr3> qt has things... but
[12:36] <mhr3> not those 10k of libs that we normally have :)
[12:36] <Saviq> mhr3, yeah, again, how is that related to cross-building? ;)
[12:37] <mhr3> diverged a bit :)
[12:37] <mhr3> saviq, but yea the problem is that even your simple sbuild is 3 A4 pages of instructions :P
[12:38] <Saviq> mhr3, most of which optional
[12:38] <mhr3> saviq, time for RealSimpleSBuild then :)
[12:38] <Saviq> mhr3, and again, it's only 15 mins setup, for multi-hour savings over the cycle
[12:39] <mzanetti> its 15 mins to setup when you know what you're doing. certainly not the first times you set it up
[12:39] <mzanetti> but yes... I still agree we should do it
[12:39] <mzanetti> but also agree with mhr3 that its not easy enough yet
[12:39] <dednick> Saviq: i'm going to miss standup today. I'll put my notes in.
[12:39] <Saviq> dednick, kk
[12:40] <Saviq> mzanetti, if there are issues in the wiki, needs fixing - it indeed mentioned --arch= instead of --target=, which was your main issue
[12:41] <mhr3> saviq, could you maybe do a cross-building presentation in malta?
[12:41] <mhr3> demo*
[12:42] <Saviq> mhr3, wonder if a workshop would be of better ues
[12:42] <Saviq> use
[12:42] <mhr3> take vanilla trusty/utopic and have armhf binaries of u8 or something by the end
[12:42] <Saviq> I wonder if I could use the click chroots, that would simplify things a bit
[12:43] <mzanetti> +1
[12:43] <Saviq> I'll see what I can do
[12:47] <Saviq> greyback, we're ignoring the fact that you can see the old app when respawning for now?
[12:48] <greyback> Saviq: no change there, it was like that before
[12:48] <Saviq> greyback, less visible since we were never respawning, but yeah
[12:48] <Saviq> hmm I just lost one app again...
[12:49] <Saviq> greyback, the weird thing is that sometimes you can see black, sometimes old app... not sure what's that about
[12:49] <Saviq> maybe if both old and new were killed I think
[12:51] <Saviq> xnox, you're in Malta second week, could we have you for a bit in a "Cross-building workshop" session so that you explained Multi-Arch: and Dep qualifiers?
[12:51] <Saviq> +tried to
[12:52] <xnox> Saviq: ok.
[12:52] <Saviq> xnox, awesome, thanks
[12:56] <Saviq> looks like we could use click chroots indeed
[13:11] <Saviq> greyback, hmm, app with --desktop_file_hint... Ctrl+C, app gets restarted, that expected?
[13:12] <greyback> Saviq: no
[13:12] <Saviq> greyback, this must be a fallout of the last fix :|
[13:14] <greyback> Saviq: how you mean get restarted?
[13:14] <Saviq> greyback, I believe it takes the .desktop file and relaunches based on that
[13:14] <Saviq> greyback, so I don't have the app in console any more
[13:15] <Saviq> greyback, but it launches the one by desktop file
[13:15] <greyback> Saviq: if you Ctrl+C something you manually launched with dfh, it does stay in the list of apps
[13:15] <Saviq> greyback, yeah, it does
[13:15] <greyback> which is unfortunate, but I can't fix that *and* the issue you found yesterday
[13:15] <greyback> they conflict
[13:15] <Saviq> greyback, and then it gets restarted when I tap on it...
[13:15] <Saviq> greyback, yeah I figured as much :/
[13:16] <Saviq> greyback, just not sure which is worse...
[13:16] <greyback> Saviq: I had thought it would be an ok compromise , but now i'm not so sure
[13:17] <Saviq> greyback, it *might* actually be ok
[13:17] <Saviq> greyback, it's a rather special case, too - more special than webapps
[13:17] <greyback> Saviq: if you open accounts from Settings, can you close it? Does it act "normal"
[13:17] <greyback> (I suspect accounts launches with desktop_file_hint somehow)
[13:17] <Saviq> greyback, it does
[13:18]  * Saviq tries
[13:18] <Saviq> greyback, seems to behave fine
[13:18] <greyback> Saviq: I'll have to leave it to you as a judegment call. Right now, I don't have any bright idea on fixing it (not so say such a possibility exists).
[13:19] <Saviq> greyback, weird thing, though... accounts exit fine (after their 5s grace period)
[13:19] <Saviq> greyback, and they go away from the stack... why wouldn't a manually started app :/
[13:20] <Saviq> greyback, does it depend on exit code?
[13:20] <greyback> Saviq: no. Now I'm confused, that should not be possible.
[13:20] <Saviq> greyback, same for mediaplayer app, if you launch it, it closes and goes away from the stack
[13:21] <Saviq> greyback, maybe because they're focused?
[13:22] <Saviq> greyback, I'll write down unexpected things on the MP
[13:23] <Saviq> greyback, yeah, as long as they exit when focused, they just go away
[13:23] <Saviq> greyback, but if they're suspended in the mean time, they get relaunched on focus
[13:23] <greyback> Saviq: makes sense, unity-mir assumes if an app that's focused closes, then it cannot be lifecycle restored
[13:24] <greyback> but if unfocused, the app has been given time to save state, so in theory it can be resumed
[13:24] <Saviq> greyback, right, so accounts will be problematic if you swipe them away
[13:24] <Saviq> greyback, they confuse the stack for sure
[13:25] <greyback> Saviq: I really don't think unity-mir get's enough information to make the correct decision, if upstart is not involved
[13:25] <Saviq> greyback, yeah I know
[13:25] <Saviq> greyback, could the fix you implemented last
[13:26] <Saviq> greyback, only have exceptions for known things - like QtWebProcess, signon-ui?
[13:27] <Saviq> greyback, it's not tragic, nothing dies etc., and only the corner cases get weird, but maybe we could limit the amount of corner cases then?
[13:27] <greyback> Saviq: it could be done I suppose. Though note https://code.launchpad.net/~mardy/unity-mir/signonui-with-oxide/+merge/216845
[13:27] <greyback> signon-ui will improve shortly
[13:28] <Saviq> greyback, sure, when it improves we'd remove the special-case for it
[13:28] <Saviq> greyback, in both places
[13:28] <greyback> Saviq: will give it a go
[13:30] <greyback> Saviq: please add the strange behaviour you notice to the MR, I'll see what i can do
[13:46] <Saviq> greyback, https://code.launchpad.net/~gerboland/unity-mir/fix-upstart-closed-apps2/+merge/218721/comments/524957
[14:18] <mzanetti> Saviq: ok. green light on Silo 5
[14:18] <mzanetti> sorry for the delays
[14:18] <Saviq> mzanetti, kk
[14:18] <mzanetti> do I still need to ping someone from the landing team?
[14:19] <mhr3> Saviq, finally wrote down my take on departments -> http://paste.ubuntu.com/7473209/ comments?
[14:19] <Saviq> mzanetti, no
[14:19] <Saviq> mzanetti, ACK the branch, though https://code.launchpad.net/~gerboland/unity-mir/shortAppIds-0.1.9/+merge/219377
[14:20] <Saviq> mhr3, hmm hmm
[14:21] <Saviq> mhr3, didn't request for departments require the canned query itself?
[14:21] <mhr3> Saviq, maybe... let's say that depId == cannedQuery
[14:22] <mhr3> afterall canned query is serializable
[14:22] <Saviq> mhr3, so it looks like my original plan basically stands ;)
[14:22] <mhr3> with some tiny changes
[14:22] <Saviq> mhr3, only you don't want a separate Model
[14:23] <Saviq> mhr3, but just make Department a model, fine with that
[14:23] <mhr3> need to dig up your proposal again :)
[14:23] <Saviq> mhr3, http://pad.ubuntu.com/dash-departments-shell-api
[14:23] <mhr3> thx
[14:24] <Saviq> mhr3, not sure we need hasDepartments, though
[14:24] <Saviq> mhr3, and I think it should be the object itself straight away
[14:24] <mhr3> yea, it's wildly similar to yours :)
[14:25] <mhr3> Saviq, i actually wanted to hide it more there
[14:25] <Saviq> mhr3, why? we'd be loading it straight away anyway?
[14:25] <mhr3> Saviq, you wouldn't be able to use it anyway, cause it would update to always the current query, and you couldn't do your transition thing
[14:25] <Saviq> mhr3, sure I could
[14:26] <Saviq> mhr3, ah well, ownership
[14:26] <Saviq> mhr3, ok
[14:26] <Saviq> mhr3, but let's drop the bool
[14:26] <mhr3> the bool is necessary :)
[14:26] <Saviq> no it isn't, just make the departments prop empty if there's no department ;)
[14:27] <mhr3> Saviq, i'm not sure i can, it will be probably serialized canned query, and empty could mean either not loaded yet, or parent, or no departments
[14:27] <mhr3> too much ambiguity
[14:28] <mhr3> s/parent/root/
[14:28] <Saviq> hasDepartments would have the exact same ambiguity
[14:28] <Saviq> it'd be false until loaded
[14:28] <Saviq> without knowing whether they'd ever be loaded
[14:29] <mhr3> but you can nicely bind to the widget's visible prop
[14:29] <Saviq> yeah, with department != "", too ;)
[14:29] <Saviq> or whatnot
[14:29] <mhr3> yea.. no :)
[14:29] <Saviq> mhr3, this just adds another property to be listened to Changed signals
[14:30] <mhr3> Saviq, should be the only one really
[14:30] <Saviq> mhr3, "department" will be a property, too
[14:30] <Saviq> mhr3, will have a Changed signal
[14:30] <mhr3> but you don't need change notifications on the currentDep
[14:30] <Saviq> mhr3, bleh
[14:30] <Saviq> mhr3, please no bool
[14:31] <mhr3> bools are good!
[14:32] <Saviq> mhr3, sure, when they're not useless ;)
[14:32] <mhr3> i wouldn't add it if i thought the other prop is enough
[14:32] <Saviq> mhr3, you still haven't convinced me why it's not enough
[14:33] <mhr3> i told you
[14:33] <mhr3> department == "" is either no departments or root
[14:33] <mhr3> no way to distinguish
[14:33] <Saviq> mhr3, yeah, and? you won't know whether there are departments until you receive them anyway
[14:34] <Saviq> mhr3, anyway, not sure what's "or root", root has departments, doesn't it?
[14:34] <mhr3> Saviq, sub-, yes, but id-wise, it can't be distinguished from no-departments
[14:35] <sil2100> mzanetti: publishing 005 - double checking, is everything ok?
[14:35] <Saviq> mhr3, hmm you mean the root node won't have a department id?
[14:35] <mhr3> Saviq, yes
[14:35] <mhr3> it won't
[14:36] <Saviq> mhr3, bleh :|
[14:36] <mzanetti> sil2100: yep. all good
[14:37] <Saviq> mhr3, so anyway, the actual arg to getDepartment() will be a string will it? serialized canned query?
[14:37] <mterry> Saviq, you mentioned catching up and planning silo 002's landing.  So I've gotten all the branches approved except two: the unity8 one (which Albert said he'd approve with one small tweak, made the tweak, and then he went EOD I think :) and indicator-network, and a developer of that said he'd review today).  I'm rebuilding the silo today, should be all good
[14:37] <mhr3> Saviq, yep
[14:38] <Saviq> mhr3, bleh for not being able to do null QString ;)
[14:38] <mhr3> Saviq, or dep id, i still need to check the api expects... anyway.. some kind of string
[14:38] <Saviq> mterry, awesome, so let's plan for Monday for testing and landing?
[14:38] <mterry> Saviq, sure.  I'll continue poking at it in the meantime
[14:39] <Saviq> mterry, I'll try and clear the current queue before then
[14:39] <Saviq> mhr3, ohkay ohkay, have your bool ;(
[14:39] <mhr3> \o/
[14:40] <Saviq> mhr3, please MP against unity-api (prereq on Albert's)
[14:40] <mhr3> Saviq, i'll do it in -shell first to see whether it really fits
[14:40] <Saviq> mhr3, sure, just make it so that they all land together (-api, -shell and unity8)
[14:41] <Saviq> mhr3, or well, -api lands before the other two
[14:41] <Saviq> at least
[14:41] <mhr3> Saviq, yea.. thx for making that harder :P
[14:41] <Saviq> mhr3, that's the whole idea! (to make it harder to break API) ;P
[14:41] <mhr3> your evil plans!
[14:43] <mhr3> oh i missed the loaded prop
[14:45] <Saviq> mhr3, yeah, status
[14:46] <Saviq> mhr3, I'll modify the pad then
[14:46] <Saviq> mhr3, to get on the same page
[14:46] <mhr3> ok, thx
[14:48] <mhr3> Saviq, why did you want special error state for departments?
[14:48] <mhr3> errors are per-search, not dep-specific
[14:48] <mhr3> shouldn't be there imo
[14:48] <Saviq> mhr3, right, this was probably when I thought a query for departments could fail
[14:49] <Saviq> mhr3, when now it'd just be a generic query fail
[14:50] <Cimi> Saviq, I changed the animation of the crossfade with a parallel animation composed of two animation for the different 2 images running in parallel - I'd like to disable one of these when I am using the two different transitions, how would you disable one NumberAnimation without hacks?
[14:50] <Saviq> mhr3, WHAT DID YOU DO! ;P\
[14:50] <mhr3> whoops :)
[14:50] <mhr3> it's back :)
[14:51] <Saviq> mhr3, think we need Model in DepartmentModel? I'm fine without it
[14:51] <mhr3> whatev
[14:51] <Saviq> ok, no, then
[14:51] <Saviq> Cimi, what are they triggered by?
[14:52] <Cimi> Saviq, swapImage function calling start
[14:52] <Saviq> Cimi, then don't call start :)
[14:52] <Cimi> Saviq, but I put them inside a parallelAnimation
[14:53] <Cimi> Saviq, and I can't call start on a not-root animation
[14:53] <Saviq> Cimi, right, then just unset the target probably
[14:53] <Cimi> so if I have Parallel { Number { image1 } Number { image2 } }
[14:53] <Cimi> Saviq, which was what I called "hack"
[14:53] <Saviq> Cimi, you could override the animations parent
[14:54] <Saviq> Cimi, so Number { parent: foo ? something : parallel }
[14:54] <Saviq> Cimi, that should work I think
[14:54] <Cimi> mmm
[14:55] <Cimi> Saviq, so this is the code I am talking about
[14:55] <Cimi> http://paste.ubuntu.com/7473365/
[14:55] <Saviq> mhr3, do we need "id" at all then?
[14:55] <Cimi> Saviq, what I want is not to run currentImageFadeOut when I ran the parent
[14:57] <Saviq> Cimi, yeah, put "parent: realCrossFade ? nextImageFadeIn : somethingElse" in  currentImageFadeOut
[14:57] <Cimi> I try
[14:57] <Saviq> Cimi, I'm not *sure* that will work, but you can try
[14:58] <Saviq> Cimi, otherwise you could create that animation dynamically and destroy it on realCrossFadeChanged
[14:58] <mhr3> Saviq, hm, the api has both ids and canned queries, so i think the plugin will expose just the ids
[14:58] <Saviq> Cimi, but not sure that'd really be that much better
[14:58] <Saviq> mhr3, ah so you'd handle queries down there?
[14:58] <Cimi> Saviq, I might be able to change the property affected
[14:58] <mhr3> Saviq, yep
[14:59] <Cimi> or change target
[14:59] <Saviq> Cimi, that was what you called "hack" just a second ago ;)
[14:59] <Cimi> yeah but who cares :D
[14:59] <Cimi> unless we have better idea
[14:59] <Saviq> Cimi, apparently you do :D
[14:59] <Cimi> haha
[14:59] <Saviq> Cimi, the only "better" idea was to move the animation outside of the parallel
[14:59] <Cimi> yeah
[14:59] <Saviq> Cimi, so that it doesn't get ran at all
[15:00] <Cimi> Saviq, I could have two animations running
[15:00] <Cimi> and call what I want
[15:00] <Saviq> mhr3, so we don't need runQuery, it will just be "close" basically
[15:00] <Cimi> not sure which is better
[15:00] <Saviq> mhr3, ah, leaf nodes
[15:00] <mhr3> Saviq, we still need activateDepartment()
[15:01] <mhr3> which is pretty much runQuery()
[15:01] <Saviq> mhr3, yeah, renamed
[15:01] <Saviq> mhr3, made it gotoDepartment(string id), k?
[15:01] <mhr3> i'm still wondering how that one could be merged with getDepartmentModel()
[15:02] <Saviq> mhr3, well, in theory I could getDepartment() and close
[15:02] <mhr3> i mean gotoDepartment could return new DepartmentModel
[15:02] <Saviq> mhr3, scary
[15:03] <Saviq> mhr3, I'd rather you departmentChanged
[15:03] <mhr3> Saviq, well cause right now you're expected to do getDepartmentModel(foo); gotoDepartment(foo)
[15:03] <Saviq> mhr3, hmm as long as ids are static
[15:04] <mhr3> feels wrong
[15:04] <mhr3> but if getDepModel is gone, i'm not sure how to the initial query for departments
[15:04] <Saviq> mhr3, not really
[15:04] <Saviq> mhr3, I do gotoDep(foo); closeUI()
[15:05] <Saviq> mhr3, you then do depChanged() → I do getDep()
[15:05] <mhr3> Saviq, what if it's a hasChildren node?
[15:05] <Saviq> mhr3, same
[15:05] <Saviq> mhr3, ah you mean when you press "all foo"?
[15:05] <mhr3> but you shouldn't close the dep ui when navigating
[15:05] <mhr3> at least that's what mike said as some point
[15:05] <Saviq> mhr3, yeah, I'd only close when it's a leaf node
[15:06] <mhr3> right
[15:06] <Saviq> mhr3, well, I'd close on press on "All foo" *or* leaf node *or* the top button
[15:06] <Saviq> mhr3, on leaf node I'd *also* do gotoDep()
[15:07] <mhr3> Saviq, i'm not sure about the gotoDep() -> depChanged() -> getDep()
[15:07] <mhr3> i was thinking getDep() -> gotoDep()
[15:07] <mhr3> cause the first one will take long
[15:07] <Saviq> but why would I getDep
[15:07] <Saviq> mhr3, I wouldn't need gotoDep() then
[15:08] <Saviq> mhr3, since getDep() would already give me everything
[15:08] <mhr3> Saviq, cause you can get the subtree right away and it will be filled
[15:08] <Saviq> mhr3, gotoDep() would at that point equal closeUI
[15:08] <Saviq> mhr3, since you'd already have loaded results for it
[15:08] <Saviq> because of getDep()
[15:09] <Saviq> mhr3, the only problem I see with that is
[15:09] <Saviq> mhr3, when I go getDep(), you query the scope
[15:09] <mhr3> no
[15:09] <Saviq> yes?
[15:09] <Saviq> mhr3, you want me to gotoDep() on _every_ dep change? why?
[15:10] <mhr3> no, i'll just snapshot what i know about the dep tree at that point
[15:10] <Saviq> mhr3, if you don't know anything about the tree, you'd query it anyway
[15:10] <Saviq> mhr3, and got deps and results back
[15:10] <mhr3> but i can't just query the tree, i'll get results too
[15:10] <Saviq> mhr3, so whether you query scope or cache - your call
[15:10] <Saviq> mhr3, exactly
[15:10] <Saviq> mhr3, we *need* the results, too
[15:11] <Saviq> mhr3, as they're meant to update all the time when you browse deps
[15:11] <mhr3> right
[15:11] <mhr3> so you wanted to call gotoDep only when going to a leaf?
[15:11] <Saviq> yeah
[15:11] <mhr3> why do we even need that then :)
[15:12] <Saviq> mhr3, so, again
[15:12] <mhr3> i don't care about the close
[15:12] <mhr3> you own the model, just destroy it when you don't need it
[15:12] <Saviq> mhr3, yeah, but my only problem was Scope.departmentChanged
[15:12] <Saviq> mhr3, which you'd emit, would you
[15:13] <mhr3> i would, but i didn't think you'd actually need it
[15:13] <Saviq> mhr3, I wouldn't *need* it
[15:13] <dandrader> mzanetti, so you're planning on make lp:~mir-team/qtmir/trunk use cmake instead of qmake?
[15:13] <Saviq> mhr3, that's exactly my point :)
[15:13] <Saviq> mhr3, I'd have to differentiate between "standard" depChanged when you change searches and such
[15:13] <mzanetti> dandrader: we definitely should do that at some point. greyback already has a branch for that, but said there would be roadblockers
[15:14] <mzanetti> dandrader: I haven't tried myself yet
[15:14] <Saviq> mhr3, and "browse" depChanged when you just load the dep for current query
[15:14] <dandrader> mzanetti, so I should now start pushing my changes there?
[15:14] <Saviq> mhr3, *but*
[15:14] <mzanetti> dandrader: yes
[15:14] <mhr3> Saviq, right, right, i kinda forgot about that
[15:14] <Saviq> mhr3, since it's a string, I could in theory ignore it
[15:14] <Saviq> mhr3, in case my current dep is equal to it
[15:15] <dandrader> mzanetti,ok,  because that s/qmake/cmake is a quite intrusive, potentially clashing with my changes. so it scares me a bit :)
[15:15] <mhr3> Saviq, i wanted to just update the model i gave you, but i can't really do that
[15:15] <greyback> dandrader: mzanetti: I mostly hit walls with cmake as I don't think people usually use it to compile a QPA. Have struggled a bit with it
[15:15] <Saviq> mhr3, well, you could, if you could, but you can't if you can't ;)
[15:15] <Saviq> mhr3, I saw your note
[15:15] <mzanetti> dandrader: if you push soon enough you'll be first anyways :D
[15:15] <Saviq> mhr3, but I think it might be too tricky
[15:15] <greyback> dandrader: I'd consider cmake a nice to have, it's far from required IMO. It's not going to land any time soon anyway
[15:15] <mhr3> Saviq, indeed
[15:16] <mzanetti> dandrader: if you do changes, please either ask me to upload a new version to the ppa, or do it yourself, however you see fit. but its not automatically updated so far
[15:16] <Saviq> mhr3, basically, I will only ever *keep* two models at most - when transitioning up or down
[15:16] <dandrader> greyback, yeah, qpa's are very tied to qt, so it makes sense to stick with qmake as it has all the secret rules for getting it installed properly
[15:16] <mzanetti> greyback, dandrader: I agree too
[15:16] <Saviq> mhr3, and whenever current changes, you'd let me know and I'd load it there and then
[15:16] <greyback> mzanetti: dandrader 2 against one, motion defeated (I'm not that upset either)
[15:17] <Saviq> mhr3, so, with that in mind... I should probably call gotoDepartment on every click
[15:17] <Saviq> mhr3, and getDepartment on departmentChanged
[15:17] <mhr3> Saviq, i think you'll need to keep comparing the currentDepId with what you last requested in getDep()
[15:17] <mzanetti> greyback: huh? I thought we all 3 agreed
[15:17] <Saviq> mhr3, indeed
[15:17] <greyback> mzanetti: yeah I do. Just being theatrical :)
[15:17] <Saviq> mhr3, feels like the only way, otherwise we'd reload it unnecessarily
[15:18] <Saviq> mhr3, in which case... gotoDeparment can go away indeed
[15:18] <mzanetti> greyback: anyways, I'd like to ask you too to push upcoming changes to lp:~mir-team/qtmir/trunk
[15:18] <mhr3> Saviq, ok, enough for now, think we went far enough, let's sort out details once we have some code :)
[15:18] <Saviq> mhr3, or we could rename getDepartment to gotoDepartment
[15:18] <Saviq> mhr3, yeah
[15:18] <Saviq> mhr3, but I agree, let's try and get rid of goto
[15:18] <mzanetti> greyback: also, as you're the one that registered the qtmir project, I think only you can set the alias for lp:qtmir to that branch
[15:18] <greyback> Saviq: haveyou the power to assign branches as the devel focus? https://code.launchpad.net/qtmir
[15:18] <Saviq> mhr3, removed it
[15:18] <mhr3> kk
[15:19] <greyback> mzanetti: unfortunately not, the Maintainer group can only do that, which I'm not on (I gave the power away)
[15:19] <mzanetti> ah, I see
[15:19] <Saviq> greyback, mzanetti, done
[15:19] <mzanetti> thanks Saviq
[15:19] <greyback> Saviq: ta
[15:21] <Saviq> mhr3, you really want "current" in "currentDepartment"?
[15:21] <mhr3> Saviq, yes!
[15:21] <Saviq> mhr3, :D
[15:21] <mhr3> although not really consistent with searchString :/
[15:22] <Saviq> oh oh, published already! :D
[15:22] <mhr3> then again, searchString isn't async
[15:22] <Saviq> :| just unity-mir
[15:23] <greyback> just?!
[15:23] <Saviq> mzanetti, greyback, is it ok that unity-mir got published alone (did one depend on the other)?
[15:23] <Saviq> greyback, if you didn't add version dependencies between them, they won't get migrated together
[15:23] <mzanetti> Saviq: shouldn't break anything (except not fixing the launcher issue yet)
[15:23] <Saviq> or bumped ABI or whatnot
[15:23] <Saviq> mzanetti, ok
[15:24] <Saviq> unity8 is still in autopkgtest
[15:24] <mzanetti> Saviq: what exactly would have been the right thing to do here?
[15:24] <mzanetti> Saviq: bump version on unity-mir and depend on that in unity8?
[15:24] <mzanetti>  >=
[15:24] <Saviq> mzanetti, that, and
[15:24] <Saviq> mzanetti, Breaks: unity8 <= foo
[15:24] <Saviq> mzanetti, in unity-mir
[15:25] <mzanetti> ok... well, if it did break it, yes. in this case its actually correct not to have the Breaks
[15:25] <Saviq> mzanetti, and/or, if ABI changed, just bump ABI
[15:25] <Saviq> mzanetti, indeed
[15:26] <Saviq> mhr3, ok, the pad is good then, I think
[15:27] <mhr3> kk
[15:28] <Saviq> paulliu, you around?
[15:28] <Saviq> paulliu, lp:~paulliu/unity8/logout still has tags, please strip with http://people.canonical.com/~msawicz/unity8/strip-u8-tags.sh
[15:31] <Saviq> mhr3, you cleared the "unity8 dependencies" ppa did you?
[15:31] <mhr3> Saviq, yea, had saucy pkgs mostly anyway
[15:31] <Saviq> mhr3, good, I'm dropping the recipes
[15:31] <mhr3> Saviq, keep the scopes-related ones pls
[15:32] <mhr3> plus i just took over some of the -saucy ones :)
[15:32] <Saviq> mhr3, were they named -saucy? ;)
[15:32] <mhr3> yea
[15:32] <Saviq> mhr3, then they're gone, sorry
[15:32] <mhr3> nvm
[15:32] <mhr3> eh, nw
[15:33] <Saviq> mhr3, could've renamed them...
[15:33] <mhr3> i did... they're -trusty now
[15:33] <Saviq> mhr3, ah then those are fine
[15:34] <Saviq> mhr3, I only dropped the -saucy ones
[15:34] <Saviq> good, so everyone did right!
[15:34] <Saviq> except launchpad...
[15:34] <mhr3> we're just awesome
[15:34] <Saviq> fooking timeout :|
[15:34] <mhr3> heh
[15:36] <mhr3> grr, so ditching this stupid wifi over the weekend
[15:36] <mhr3> hopefully i won't kill my laptop :)
[15:37] <mhr3> otherwise i'll consider it Cimi's fault :P
[15:53] <paulliu> Saviq: ok
[15:55] <paulliu> Saviq: BTW, How to push if I clear the tags?
[15:55] <Saviq> paulliu, you need to run the script passing lp:~paulliu/unity8/foo to it
[15:55] <Saviq> paulliu, it will iterate over the arguments
[15:56] <paulliu> Saviq: ah.. ok
[15:56] <Saviq> paulliu, so you can just run it with "/path/to/your/local/checkout lp:~paulliu/unity8/foo"
[16:00] <mhr3> mhall119, ping? the 14.04 docs didn't get updated
[16:04] <dandrader> mzanetti, since you're on the packaging etc
[16:05] <dandrader> mzanetti, have you notice that if you make qtmir with e.g.  -j4 it eventually breaks. then you issue make once again and it continues finishes successfully
[16:06] <greyback> dandrader: one of the reasons cmake is better
[16:06] <dandrader> looks like some missing build dependency. building in the wrong order I guess
[16:07] <greyback> dandrader: there's a qmake ".depends" command which can specify that one target requires another one
[16:09] <mzanetti> dandrader: fixed already
[16:09] <greyback> mzanetti: yes you did, yay for you
[16:09] <mzanetti> dandrader: although only pushed to my packaging branch
[16:09] <mzanetti> I think
[16:09] <mzanetti> anyways. its fixed and will land in a ppa near you soon
[16:11] <mzanetti> greyback: yeah, you had the depends the wrong way round
[16:11] <greyback> mzanetti: ah was that it? Bah
[16:11] <mzanetti> yep. at least in the ppa it builds now
[16:12] <mzanetti> and that's building with -j8
[16:12] <greyback> great
[16:13] <mzanetti> yay! unity8 built too!
[16:13] <mzanetti> only keyboard to go
[16:13] <greyback> mzanetti: keyboard not needed, I landed the change needed
[16:13] <mzanetti> oh! awesome!
[16:13] <mzanetti> => ppa ready to be installed for the first time
[16:13] <greyback> Don't expect any miracles
[16:14] <mzanetti> no. I expect breakage
[16:14] <greyback> the surface management in unity8 needs a bit of work still
[16:14] <mzanetti> but hey, that's what we have the ppa for. find the breakage
[16:14] <greyback> yep
[16:15] <dandrader> mzanetti, what about the changes from the "Getting it up and running" session?
[16:15] <mzanetti> dandrader: right... still to be done
[16:16] <dandrader> likely need to branch some other packages to get them in
[16:16] <greyback> dandrader: where is that doc again?
[16:16] <dandrader> https://docs.google.com/a/canonical.com/document/d/1IiHBDIW_e0qnGt-po1D2z5HJKrNhBwh6pdILeEN2sgA/edit#
[16:16] <greyback> tnx
[16:17] <dandrader> how come it's not in your faves list? :)
[16:17] <greyback> dandrader: mzanetti I'd argue those changes are not necessary just yet. I'd like to test using the standard client QPA plugins from qtubuntu first
[16:18]  * mzanetti doesn't know enough about what's changed, so doesn't argue in this case
[16:19] <mzanetti> greyback: but afaiu it won't even boot without that, no?
[16:19] <greyback> mzanetti: it will
[16:20] <greyback> mzanetti: ubuntuclient QPA plugin is the equivalent of the ubuntumirclient QPA plugin from qtubuntu
[16:20] <greyback> mzanetti: both are used by Qt applications to connect to Mir
[16:20] <mzanetti> oh i see
[16:20] <greyback> ubuntuclient just a tidied up version of ubuntuMirclient
[16:21] <mzanetti> got it
[16:21] <greyback> ubuntuclient  has a couple of small changes, which will probably make the experience better
[16:22] <greyback> (e.g. ubuntumirclient adds a white strip to the top of the application surface - which is usually hidden under the panel)
[16:22] <greyback> ubuntuclient removes that
[16:22] <greyback> but I've a branch of qtubuntu that does the same, which might be a lot easier to land - longer term
[16:23] <mzanetti> and you're still unsure if you want to replace the ubuntumirclient with ubuntuclient, or upstream changes to ubuntumirclient
[16:23] <mzanetti> I see. makes all sense
[16:23] <mzanetti> just let me know which one you want in the ppa and you'll get it
[16:24] <greyback> mzanetti: I've not tested my qtubuntu branch yet, so let's leave that decision until monday
[16:25] <mzanetti> yeah... I'm EOWing soon now
[16:25] <greyback> no worries, Have a good weekend!
[16:25] <greyback> thanks for all your help today
[16:25] <mzanetti> no problem... finally I see progress
[16:25] <mzanetti> felt really slow the last 3 days
[16:26] <greyback> oh yeah
[16:28] <dandrader> yes, reflashing got my rotation back \o/ (god knows what I f**ed up on the previous image)
[16:33] <dandrader> greyback, whall I remove qpamirserver repo to avoid confusion?
[16:33] <dandrader> shall
[16:33] <greyback> dandrader: ok
[16:35] <dandrader> will just bring  your recent "Establish object ownership with more care" commit into qtmir and them nuke it
[16:38] <greyback> dandrader: thanks!
[16:42] <mhall119> mhr3: can I just copy the 14.10 docs over top of the 14.04 docs?
[16:42] <mhr3> mhall119, yes
[16:42] <mhall119> mhr3: if there's anything that was removed between 14.04 and 14.10, I'll need to manually remove it
[16:43] <mhr3> mhall119, just added afaik
[16:44] <mhall119> ok, putting it up on 14.04 on staging first
[16:44] <mhall119> mhr3: please verify http://<IP_ADDRESS>/api/scopes/sdk-14.04/ and then I'll push them to 14.04 on production
[16:45] <mhr3> mhall119, +1
[16:46] <mhall119> ok, going to production now
[16:46] <mhr3> mhall119, i hope the new scripts aren't going to revert it back?
[16:46] <mhr3> automatically
[16:47] <dandrader> greyback, so I can remove DBusScreen from qtmir as unity-system-compositor has it, right?
[16:47] <greyback> dandrader: right
[16:47] <dandrader> ok, will do
[16:51] <mhall119> mhr3: once it's automated it'll only update the development version, not stable version
[16:51] <mhr3> mhall119, ok
[17:05] <mhall119> mhr3: please verify http://developer.ubuntu.com/api/scopes/sdk-14.04/
[17:06] <mhr3> it's ok
[17:06] <mhall119> thanks, let me know if there are any other changes you need
[17:34]  * greyback eow o/


[06:04] <didrocks> good morning
[06:05] <Trevinho> hi didrocks
[06:05] <Trevinho> good morning :-)
[06:05] <Trevinho> I was actually waiting for you :-D
[06:06] <didrocks> hey Trevinho! really? ;)
[06:06] <Trevinho> yeah...
[06:06] <Trevinho> didrocks: as, you might have a look at branches in https://bileto.ubuntu.com/#/ticket/2967
[06:07] <Trevinho> there are also two branches that andyrock approved and tested, but he can't global approve
[06:08] <didrocks> Trevinho: will have a look today
[06:08] <Trevinho> didrocks: ok, no rush... just I wanted to mention before I was going to bed :)
[06:08] <didrocks> Trevinho: sure! Have a good night :)
[06:09] <Trevinho> thanks
[06:09]  * Trevinho loved the Bali timezone more :-P
[06:24] <jibel> morning
[06:28] <didrocks> salut jibel
[06:31] <jibel> salut didrocks , bien rentré?
[07:12] <didrocks> jibel: oui oui, aucun problème, et toi ?
[07:33] <jibel> didrocks, perfect, arrived 1h15 early. I was a very short flight
[07:33] <jibel> s/I/It/
[07:34] <didrocks> nice!
[07:34] <didrocks> mine was delayed (boarding 40 minutes in JFK, then, waiting an hour for taking off)
[07:35] <didrocks> but we arrived only 20 minutes late, which was ok for connecting anyway
[08:02] <willcooke> morning all
[08:04] <Laney> sup
[08:04] <willcooke> hi Laney
[08:06] <didrocks> hey willcooke, Laney
[08:06] <willcooke> hi didrocks, how goes?
[08:07] <seb128> good morning desktopers
[08:07] <seb128> hey didrocks willcookel
[08:07] <seb128> did everybody had a good trip back and recovered?
[08:07] <willcooke> hi seb128l, how was your day yesterday?  Restful?
[08:07]  * seb128 failed to connect to that channel today when he started irc because of the +r mode
[08:07] <willcooke> same here
[08:07] <didrocks> willcooke: good, still a little bit tired, but getting there :)
[08:08] <seb128> willcooke, it was good, not so much rest though, just catchup with busy life mostly... :-)
[08:09] <seb128> we had all been travelling for a week so quite some unpacking, tiding up, etc
[08:09]  * Laney nods didrocks willcooke seb128
[08:09] <seb128> just as a fyi Olivier is off today, Catalonia protests = no school so he has to take care of his daugther
[08:09] <seb128> hey Laney, how are you?
[08:11] <Laney> ahh I was hoping he was going to be on strike
[08:11] <Laney> seb128: good!
[08:11] <Laney> umm there's a weird noise coming from the bathroom
[08:11] <Laney> brb
[08:12]  * Laney gets eaten by the drain monster
[08:12] <Laney> ... it's next door scraping on their side of the wall in a creepy way ...
[08:15] <seb128> lock the door!
[08:44] <didrocks> andyrock: hey, once you are online, do you mind answering on https://github.com/ubuntu/gnome-shell-extension-appindicator/pull/95? Feedback asked 4 days ago, you should really fix your github emails ping! (I don't really want to merge/sponsor it before upstream +1 on it)
[08:50] <seb128> didrocks, 4 days which included rally wrapup, w.e and post sprint monday ... still agreed that it would be nice to reply though, just putting things in perspective a bit :)
[08:51] <seb128> andyrock, but yeah, please reply today :)
[08:54] <didrocks> well, it's just the second time I'm asking to track on this one and answer (and some others)
[08:54] <didrocks> I think fixing his github notifications is a must, as already explained last week
[08:54] <popey> Hm. the appindicator extension seems to keep disappearing for me
[08:55] <seb128> popey, report a bug with logs?
[08:56] <popey> right, where? upstream git or launchpad?
[08:59] <seb128> launchpad, though you might want to report it against the upstream on as well since we don't really change it
[09:01]  * didrocks found another theme issue to fix, I wonder if this is an indirect related issue to what jibel saw on Friday
[09:12] <popey> ok, thanks seb128
[09:12] <seb128> thx
[09:19] <didrocks> Am I the only one for who the nautilus copy progress bar in the dock doesn't refresh if you close the nautilus windows during the copy?
[09:20] <seb128> I didn't notice that but I'm not sure I close the window usually
[09:20] <seb128> I'm currently on my xenial partition but I try later when I reboot
[09:21] <seb128> I had cases where it stayed a bit longer but the in-win indicator does the same so it's a nautilus issue
[09:22] <didrocks> could be that it doesn't send refresh signals if closed, but I don't see the in-win indicator jumping from one place to another when opening it (can maybe refresh too fast)
[09:28] <seb128> does the launcher refresh immediatly when you reopen the view?
[09:32] <didrocks> yes
[09:33] <seb128> it's probably something like that then, and probably not easy to fix
[09:36] <Laney> didrocks: did you see there's a glib stable release up for merge?
[09:36] <Laney> (just saw the queue entry land)
[09:37] <didrocks> Laney: I probably will do another glib upload once I debug the desktop file translation issue we have (I guess I'll tackle this tomorrow), I'll merge it as the same time
[09:43] <Laney> ok, let's hold for then then
[09:43] <Laney> it probably won't go through proposed-migration by tomorrow anyway
[09:44] <didrocks> hum, I have other uploads waiting on this glib fix to go through thus
[09:44] <seb128> k, I'm out for some errands and lunch, bbiab
[09:45] <didrocks> and time to debug/fix maybe it will be thursday, I hoped to get that one in in between as I tested it for a day already
[09:45] <didrocks> but if you don't mind having more uploads by the end of the week, that's ok to me (migration scripts and default ubuntu settings fix)
[09:58] <popey> looks like I'm also experiencing bug 1719192
[10:05] <ahayzen> popey, https://github.com/ubuntu/gnome-shell-extension-appindicator/issues/96 seems like a duplicate of https://github.com/ubuntu/gnome-shell-extension-appindicator/issues/75 ?
[10:06] <popey> ooh, could be yeah, thanks
[10:06] <popey> I searched but didnt find that one
[11:14] <ricotz> chrisccoulson, I assume this will be required for tb52.4 on artful https://paste.debian.net/plain/988838/
[11:15] <chrisccoulson> ricotz, ah, yeah, I forgot about that one
[11:15] <chrisccoulson> thanks
[11:16] <ricotz> chrisccoulson, also the arm64 fix for firefox doesnt look good imo
[11:16] <ricotz> it is only required on trusty -- https://bazaar.launchpad.net/~mozillateam/firefox/firefox-beta.trusty/view/head:/debian/patches/build-arm64-skia.patch
[11:17] <ricotz> chrisccoulson, you can imagine that there is all kind of things I wanted to ask you over the past couple of weeks
[11:17] <chrisccoulson> we shouldn't be shipping that - it doesn't really have any chance of landing upstream
[11:18] <ricotz> chrisccoulson, I specifically talking about your patch here
[11:22] <ricotz> chrisccoulson, "the desktop team are going to be gradually taking firefox", could you elaborate?
[11:37] <chrisccoulson> ricotz, yes, olivier will be gradually taking it. And hopefully foundations will take rust
[11:40] <ricotz> chrisccoulson, do you have moment for a PM?
[12:25] <jbicha> chrisccoulson: what do you think of LP: #1720422 ? does it help?
[12:34] <jbicha> seb128: hi, what do you think we should do for artful for LP: #1719322 now?
[13:15] <ricotz> hello, there are Firefox 52 ESR packages to test in https://launchpad.net/~mozillateam/+archive/ubuntu/ppa
[13:27] <seb128> jbicha, hey, I would revert, we discussed freezes a bit in N-Y and there was agreement that those are not well enforced nowadays and that people take more liberty of ignoring them which start making the process pointless
[13:28] <seb128> so I think it's time we start being more strict again
[13:28] <jbicha> seb128: revert just file-roller?
[13:28] <seb128> UI change or feature without an approved request should be reverted imho
[13:28] <seb128> jbicha, let me read the wiki, is UIF about the archive or about flavors only?
[13:29] <seb128> seems default installation only
[13:29] <Laney> default applications
[13:29] <jbicha> my personal opinion is that UIF is about documentation and translations so unseeded packages shouldn't be affected
[13:29] <seb128> so yeah, I guess just file-roller is enough
[13:30] <jbicha> ok, that's fine. I felt bad about the file-roller change after I uploaded. That's why I stopped before changing eog & evince
[13:30] <seb128> though those changes are border line feature changes
[13:30] <seb128> and ffe is about the archive, no default install
[13:30] <andyrock> didrocks: seb128 the issue with my github notification emails is not easy to solve :D
[13:30] <seb128> andyrock, hey! what is it?
[13:30] <seb128> jbicha, thanks
[13:31] <andyrock> I get the email but then gmail deletes it and I cannot see any filter than can cause it
[13:31] <andyrock> and "good morning!"
[13:31] <seb128> andyrock, it's in the trash? gmail doesn't give you indication of why?
[13:31] <didrocks> maybe set in spam?
[13:31] <seb128> if it's on any github comment easy to test, disable all filters and do a trivial change
[13:31] <seb128> need to change location, brb
[13:31] <jbicha> I only get notification emails from github sometimes, I have to manually visit http://github.com/notifications so I don't miss stuff
[13:32] <andyrock> seb128 not in trash not in spam I get the notification on my phone for one second, than the notification disappears
[13:57] <Laney> what's that weird smell?
[13:57] <Laney> oh, that weird smell is me
[13:57] <Laney> :(
[14:01] <seb128> bah, I really need to fix my irc client to identify on start, failed to connect to -desktop again
[14:01] <didrocks> even that isn't enough, as for me, ident answer is after autojoin
[14:02] <Laney> it's probably ok to take the mode off now
[14:03] <Laney> but that identify on connect is supposed to be for this case
[14:04]  * Laney has sasl set up
[14:05] <Laney> nope, I did that for OFTC but not freenode, for freenode I have laney:password in the server password
[14:07] <tseliot> Laney: hey, shall I file a bug report against gdm3 about reverting my workaround? I have tested the new nvidia driver (which I haven't uploaded yet), and it's all good
[14:07] <jbicha> andyrock: is there a LP bug for https://bugzilla.gnome.org/788268 ?
[14:08] <Laney> tseliot: maybe ping me when it's in archive and I'll do it
[14:08] <seb128> jbicha, bug #1720150
[14:09] <tseliot> Laney: ok, thanks
[14:09] <seb128> jbicha, you can https://bugs.launchpad.net/bugs/bugtrackers/gnome-bugs/nnn to find the reverse bug
[14:09] <Laney> cool launchpad hack
[14:09] <seb128> :-)
[14:09] <jbicha> wow, that's magic
[14:11] <seb128> I've an alias/keyword on that for years, it's handy :-)
[14:14] <willcooke> PSA:  The new community hub is live: https://community.ubuntu.com
[14:15] <seb128> nice
[14:15] <willcooke> Looks good
[14:16] <didrocks> great :)
[14:16] <didrocks> popey: should we retry a mock blog post ?
[14:16] <popey> Not sure it needs a mock one, why not a real one? :D
[14:16] <didrocks> popey: the issue is if we publish a real one and it doesn't work… no comment for people
[14:17] <popey> and if we do a mock one 5 mins after site launch, all eyeballs see a mock post
[14:17] <popey> which looks messy :)
[14:17] <popey> maybe tomorrow?
[14:17] <didrocks> fine for tomorrow :)
[14:17] <popey> or at 3am :D
[14:17] <didrocks> popey: here is my ssh key to publish and try it thus :p
[14:18] <popey> didrocks: i ssh'ed in but couldn't navigate all the baguettes and croissants!
[14:18] <didrocks> I can ensure you wouldn't be able to find any « croissant au chocolat » here :)
[14:18] <popey> Saw that coming :)
[14:19] <didrocks> héhé
[14:20] <andyrock> jbicha: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1720150
[14:20] <jbicha> thanks
[14:21] <jbicha> seb128: could you review LP: #1719462 ? will that change break translations?
[14:26] <seb128> jbicha, I believe it will yes
[14:26] <seb128> there is no fallback to the string without context since that would be wrong
[14:26] <Laney> fail
[14:26] <seb128> :-/
[14:27] <jbicha> so do we need a UIFe for LP: #1719462 or is emailing the translators list ok?
[14:28] <seb128> jbicha, you need to stay away from doing it I would say
[14:28] <seb128> well it's tricky, if you do it now you risk to have that string not translated in most locales
[14:28] <seb128> depends how reactive translators are
[14:29] <seb128> to weight against a string looking weird in russian
[14:29] <jbicha> ok, I can revert my change and it'll be fixed for 18.04 LTS instead
[14:29] <seb128> I would suggest to do that
[14:56] <ahayzen> Hi, anyone else getting hashsum missmatches from apt update for zesty universe translations? https://pastebin.ubuntu.com/25667357/  or know where to ask/report?
[15:04] <ahayzen> magic, seems to have resolved itself now :-)
[15:07] <kenvandine> ahayzen, that's weird :)
[15:07] <Trevinho> hey guys
[15:19] <didrocks> Trevinho: hey! I did your review, small requests on them :)
[15:20] <Trevinho> didrocks: oh I didn't see the email, now I did :-D
[15:24] <willcooke> Lots of people out for the meeting today, and not many emailed reports, so I think it will be a quick one
[15:29] <kenvandine> :)
[15:29] <kenvandine> quick is good
[15:29] <jbicha> I've got a couple questions to discuss
[15:30] <willcooke> ding ding ding
[15:30] <willcooke> #startmeeting Desktop Team Weekly Meeting 2017-10-03
[15:30] <Laney> |o|
[15:30] <meetingology> Meeting started Tue Oct  3 15:30:37 2017 UTC.  The chair is willcooke. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:30] <meetingology> Available commands: action commands idea info link nick
[15:30] <kenvandine> o/
[15:30] <didrocks> o/
[15:30] <willcooke> Roll call: andyrock, dgadomski, didrocks, duflu (out), jbicha, jamesh (out), jibel/heber (out?), kenvandine, laney, oSoMoN (out), seb128, tkamppeter (out), trevinho, robert_ancell (out)
[15:30] <jbicha> o/
[15:31] <Trevinho> hola!
[15:31] <andyrock> o/
[15:32] <willcooke> Let's get started..
[15:32] <willcooke> But, before we do, an announcement... at the end of the meeting we're going to do a quick scan through the rls-aa-incoming bugs and see if there is anything which needs urgent attention and to make sure the bugs are getting looked at.
[15:33] <willcooke> But first, #topic andyrock
[15:33] <willcooke> #topic andyrock
[15:33] <andyrock> # Ubuntu Rally last week
[15:33] <andyrock> # Setting up jhbuild to build the gnome stack.
[15:33] <andyrock> # Fix scaling in appIndicator extension for pixbuf icons.
[15:33] <andyrock> # Windows not scaled in hidpi setups using "Ubuntu Xorg" session.
[15:33] <andyrock> # gnome-shell crashed with SIGSEGV in st_theme_node_reduce_border_radius() from st_theme_node_paint_borders() from st_theme_node_paint().
[15:33] <andyrock> # Some work on "System goes to sleep with external monitor and lid closed after login.". Not yet fixed as I don't have a multimonitor with me right now.
[15:33] <andyrock> # Working on fixing the way the osk is activated in gnome-shell on touch events.
[15:33] <andyrock> ops too fast :D
[15:33] <willcooke> I think it worked
[15:33] <willcooke> :)
[15:33] <willcooke> thanks andyrock
[15:33] <willcooke> #topic dgadomski
[15:33] <dgadomski> hey
[15:33] <dgadomski> nothing to share, have been out last week
[15:34] <willcooke> thanks dgadomski
[15:34] <willcooke> #topic didrocks
[15:34] <didrocks> Since last meeting (2 weeks ago?):
[15:34] <didrocks> * Publish about dash transparency: https://didrocks.fr/2017/09/20/ubuntu-gnome-shell-in-artful-day-13/ and as usual, handle comments and feedbacks.
[15:34] <didrocks> * Discussed with g-g-c upstream about some enhancements for ubuntu dock panel and most of those are now implemented (better layout, multiple screen detections…) and look with seb128 about white background for better readability.
[15:34] <didrocks> * Add advanced printer button in g-c-c to trigger system-config-printer.
[15:34] <didrocks> * Fix gnome-software to show up ubuntu software icon on xorg session.
[15:34] <didrocks> * Spent some time looking and adding bugs to -incoming.
[15:34] <didrocks> * Discussed with GNOME designers on shortcuts like (shutdown) after a patch introduced by system76.
[15:34] <didrocks> * Worked on HUB integration beta with blog post to comments to collect feedback and traffic.
[15:34] <didrocks> * Google Code-in 2017 desktop list tasks.
[15:34] <didrocks> * Tease and work on plan for our next theming strategy.
[15:34] <didrocks> * Fix some theme issues like better button discovery in headerbar, checkbox in the Shell…
[15:34] <didrocks> * Released badges and progress bar in Dock and blog about it: https://didrocks.fr/2017/09/25/ubuntu-gnome-shell-in-artful-day-14/, reseed thunderbird support thus. Using those upload to cherry-pick other fixes and cleaning shorcuts list.
[15:34] <didrocks> * Dig into existing GNOME Shell tests and see what we can do to run them with jibel, build a test framework around them.
[15:34] <didrocks> * Test and uploaded a fix for french in gnome-calculator.
[15:34] <didrocks> * Purge more s390x desktop packages as not leaf dependencies have been removed first and causing FTBFS and other random Archive Admin requests.
[15:34] <didrocks> .
[15:34] <willcooke> thanks didrocks
[15:35] <willcooke> skipping duflu
[15:35] <willcooke> #topic jbicha
[15:35] <jbicha> • Tweaks 3.26.1 release to fix some regressions
[15:35] <jbicha> • Reviewed and merged GunnarHj's im seed changes (replacing fcitx with ibus)
[15:35] <jbicha> • Filled in Desktop section of 17.10 Beta release notes
[15:35] <jbicha> • Made ubuntu-gnome-desktop transitional depending on ubuntu-desktop
[15:35] <jbicha> • Created vanilla-gnome-desktop for those who really liked Ubuntu GNOME
[15:35] <jbicha> • Mentored ventrical and sponsored his work to fix some Unity 17.10 issues
[15:35] <jbicha> • Discussed big-endian mozjs problem (this issue is blocking Debian unstable from updating GNOME Shell to 3.26)
[15:35] <jbicha> • Dropped xterm and xdiagnose from default install
[15:35] <jbicha> • Started packaging GNOME 3.26.1
[15:35] <jbicha> • I had some trouble with imagemagick LP: #1717951 do we want to discuss after the meeting?
[15:35] <jbicha> eof
[15:35] <willcooke> thanks jbicha
[15:35] <willcooke> want to leave your other topics  for the end?
[15:36] <seb128> jbicha, +1 to discuss imagemagick
[15:36] <seb128> at end/after meeting is fine imho
[15:36] <willcooke> kk
[15:36] <jbicha> yes
[15:36] <willcooke> skipping jamesh
[15:36] <willcooke> #topic jibel / heber
[15:36] <willcooke> Ubuntu rally QA highlights:
[15:36] <willcooke> KPIs:
[15:36] <willcooke> Showed current KPIs in grafana dashboard
[15:36] <willcooke> Ideas for new KPIs, example: SRUs (e.g. How long things are waiting in proposed), ISO Size, Boot Speed, Memory Usage
[15:36] <willcooke>  Make KPIs public
[15:36] <willcooke>  Add a KPI review to the weekly meeting
[15:36] <willcooke>  IRC bot to advise on KPI failures
[15:36] <willcooke>  IRC bot to say when an ISO fails to get promoted
[15:36] <willcooke> Gnome-shell-extensions:
[15:36] <willcooke> Discussion about creating an integration suite for gnome-shell-extensions:
[15:36] <willcooke> JS tests scripts
[15:36] <willcooke> D-bus service
[15:37] <willcooke> External tests runner
[15:37] <willcooke> This week working on:
[15:37] <willcooke> Design D-bus interface for gnome-shell-extensions integration tests
[15:37] <willcooke> Analyse red ubiquity jobs
[15:37] <willcooke> Fix problems with VMs in venonat server
[15:37] <willcooke> #topic kenvandine
[15:37] <kenvandine> * Helped elementary guys create a runtime platform snap and snap their first application
[15:37] <kenvandine> * Created a build snap for elementary sdk, which will be used in stead of build -packages for building elementary apps.  Not yet tested, once we sort out how this works I need to do the same for GNOME.
[15:37] <kenvandine> * Discovered the new build-attributes in snapcraft that allows us to exclude system libraries from our snaps more easily
[15:37] <kenvandine> * Put our snaps on a diet!  Our snaps are now significantly smaller thanks to excluding the system libraries.
[15:37] <kenvandine> * 13 new snaps last week
[15:37] <kenvandine> * Created a wiki page for our snaps https://wiki.ubuntu.com/DesktopTeam/GNOMESnaps
[15:37] <kenvandine> * Working on the Ubuntu Migration to GNOME doc
[15:37] <kenvandine> EOF
[15:37] <willcooke> thanks kenvandine
[15:37] <willcooke> #topic Laney
[15:38] <Laney> • Went to the Ubuntu Rally in NYC
[15:38] <Laney> ∘ Worked with wgrant on a new cloud region for arm64 / s390x testing, found some problems with the setup that are being worked through.
[15:38] <Laney> ∘ Discussed release team processes with the members who were there.
[15:38] <Laney> ∘ Took advantage of jadahl to learn more about monkeypatching in the looking glass, and to fix some random bugs.
[15:38] <Laney> ∘ Triaged the list of rls-aa-incoming bugs in person.
[15:38] <Laney> ∘ Helped out with defining the 18.04 work list.
[15:38] <Laney> ∘ Some pair debugging of the systemd/armhf failure with x_nox.
[15:38] <Laney> ∘ Helped s_il2100 out with his first serious bit of release managing (well done!)
[15:38] <Laney> ∘ Tested + released NM 1.8.4.
[15:38] <Laney> ∘ Pizza, steak, burger.
[15:38] <Laney> • Been doing release team reviews (queue + FFe).
[15:38] <Laney> • Helped out a bit with gnome-software 3.26.1 release upstream - cherry-picked some patches & wrote release notes, then hughsie turned up and pushed the tarball.
[15:38] <Laney> 💌
[15:39] <willcooke> thanks Laney
[15:39] <willcooke> skipping osomon
[15:39] <willcooke> #topic seb128
[15:39] <seb128> * travelled to N-Y
[15:39] <seb128> * had quite some discussions with different people here about random topics (didn't take enough notes to list them here, that wouldn't be too useful anyway)
[15:39] <seb128> * looked at some theme issues with Didier (g-c-c lists bg, action button colors)
[15:39] <seb128> * debugged some ubiquity issues (layout not applying, start sound not playing, orca not starting)
[15:39] <seb128> * reviewed trellos board and milestoned bugs with the team
[15:39] <seb128> * triaged recent reports on launchpad
[15:39] <seb128> probably others bugs and debugging I didn't list there

[15:39] <willcooke> thanks seb128
[15:39] <willcooke> #topic tkamppeter
[15:40] <willcooke> Hey tkamppeter, are you here?
[15:40] <tkamppeter> yes
[15:40] <tkamppeter> - Ubuntu Rally:
[15:40] <tkamppeter>   o Met Gerry Boland to coordiante integration of print dialog work, as in
[15:40] <tkamppeter>     the LTS we will not get beyond Qt 5.9, he suggests to create a separate
[15:40] <tkamppeter>     package with the new Qt print dialog
[15:40] <tkamppeter>   o Talked with Olivier about the (upstream-accepted) LibreOffice print dialog
[15:40] <tkamppeter>     patch.
[15:40] <tkamppeter>   o Met several of the Snap guys and got some help on the CUPS Snap. Next
[15:40] <tkamppeter>     problem is Avahi:
[15:40] <tkamppeter>     https://forum.snapcraft.io/t/snapping-cups-printing-stack-avahi-support-system-users-groups/1502/16?u=till.kamppeter
[15:40] <tkamppeter>     Printer driver plug-in support is covered by this bug:
[15:40] <tkamppeter>     https://bugs.launchpad.net/snapd/+bug/1655125
[15:40] <tkamppeter>   o Talked with several people about driverless printing.
[15:40] <tkamppeter> - cups-filters: Released 1.17.8 with a bug fix in foomatic-rip and packaged
[15:40] <tkamppeter>   this for Artful
[15:40] <tkamppeter> - OpenPrinting: Started to move all OpenPrinting projects to GitHub:
[15:40] <tkamppeter>   https://github.com/OpenPrinting
[15:40] <tkamppeter> - Common Print Dialog Backends (CPDB): Started new OpenPrinting project for
[15:40] <tkamppeter>   all the GUI-toolkit-independent parts of print dialog work of this year's
[15:40] <tkamppeter>   Google Summer of Code:
[15:40] <tkamppeter>   o cpdb-libs: Libraries to implement the D-Bus interface between print dialog
[15:40] <tkamppeter>     and backends
[15:40] <tkamppeter>   o cpdb-backend-cups: CUPS/IPP backend
[15:41] <tkamppeter>   o cpdb-backend-gcp: Google Cloud Print backend
[15:41] <tkamppeter>   The GIT repositories are available on the OpenPrinting GitHub.
[15:41] <tkamppeter> - Common Print Dialog Backends (CPDB): Suggested to do to additional pieces:
[15:41] <tkamppeter>   o "Adaptor" backend for current (old) GTK print dialog which connects to the
[15:41] <tkamppeter>     new CPDB backends, for the time being until the new GTK print dialog will
[15:41] <tkamppeter>     get released (like Ubuntu 18.04).
[15:41] <tkamppeter>   o "Print to File" CPDB backend to allow to save the output to a PDF file.
[15:41] <tkamppeter>   Nilanjana Lodh, who did the libraries and CUPS backend in GSoC will most
[15:41] <tkamppeter>   probably work on this.
[15:41] <tkamppeter> - Google Summer of Code 2018: 7 project ideas already lined up. Most of the
[15:41] <tkamppeter>   students are still available for next GSoC and we will ask them to work for
[15:41] <tkamppeter>   us again. We will also start to recruit in December.
[15:41] <tkamppeter> - Bugs.
[15:41] <willcooke> thanks tkamppeter :)
[15:41] <willcooke> #topic Trevinho
[15:42] <Trevinho>  · Fixed landing of unity7 stack on artful and did the landing
[15:42] <Trevinho>  · Fixed mutter to get proper matching of snapped gnome applications
[15:42] <Trevinho>  · Continued the work on fractional scaling with Jonas, targetting various annoyances
[15:42] <Trevinho>  · Did the work to port ubuntu settings saved in gnome to our schemas
[15:42] <Trevinho>  · Eat a lot of American food
[15:42] <Trevinho>  · Took selfies with the team
[15:42] <Trevinho> <3
[15:42] <willcooke> heh
[15:42] <willcooke> thanks Trevinho
[15:42] <willcooke> skipping robert_ancell
[15:42] <willcooke> #topic rls-aa-incoming review
[15:43] <tkamppeter> You forgot something: Drink a lot of Espresso.
[15:43] <willcooke> Laney, could you take us through it?
[15:43] <Laney> UMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMOK
[15:43] <Laney> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-aa-incoming-bug-tasks.html
[15:44] <Laney> so question for each one is
[15:44] <Laney> accept or not, and if so, assign to who?
[15:44] <Laney> the DHCP thingy is not for our team, but the other three at the top are I think
[15:44] <Laney> https://bugs.launchpad.net/ubuntu/+source/lshw/+bug/1720624
[15:44] <seb128> I don't think the first one (g-s) is important enough to be on the list
[15:45] <seb128> jbicha, ^you tagged it?
[15:45] <didrocks> (also, seb tried to fix the first one and it's not trivial)
[15:45] <Laney> can we do them in order please
[15:45] <Laney> well, the order that I'm giving them :
[15:45] <Laney> :P
[15:45] <willcooke> That does appear to be the first one
[15:45] <jbicha> seb128: if the actions don't work, we could disable them from the .desktop
[15:45] <seb128> Laney, "gnome-screenshot Actions don't work in default Ubuntu 17.10 session" is first here
[15:46] <Laney> :/
[15:46] <Laney> I already gave one, but ok.
[15:46] <seb128> Laney, sorry, go ahead with your order
[15:46] <Laney> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1720262
[15:46] <seb128> that's fine
[15:46] <didrocks> I would suggest we remove the extra actions from desktop file
[15:47] <didrocks> better than a non working action
[15:47] <seb128> jbicha, if you wish, I don't think many users are going to pin that icon to the launcher and right click on it in practice
[15:47] <didrocks> (for this cycle)
[15:47] <seb128> but a small improvement is still welcome and it's a cheap change
[15:47] <seb128> jbicha, would be worth upstreaming the issue still
[15:47] <Laney> who wants to be assigned it then?
[15:48] <jbicha> ok, I'll do those 2 tasks (upstream and remove non-working actions)
[15:48] <Laney> k, nominate, assign, remove tag please, thanks!
[15:48] <seb128> jbicha, thanks
[15:49] <Laney> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1720829
[15:49] <Laney> I found the upstream bug, pinged on it for a review, but I vote notfixing for the release
[15:49] <Laney> as in, wait for that review
[15:50] <seb128> +1
[15:50] <seb128> we can SRU the fix later
[15:50] <didrocks> sounds minor enough to not risk it, at worst, SRU
[15:50] <didrocks> yep :)
[15:50] <Laney> thx
[15:51] <willcooke> kk, looks like the other bugs are not for us
[15:51] <Laney> no
[15:51] <Laney> https://bugs.launchpad.net/ubuntu/+source/lshw/+bug/1720624
[15:51] <Laney> that is
[15:51] <seb128> udisks is foundations no?
[15:51] <seb128> if it's not it should :p
[15:51] <seb128> it's in systemd now no?
[15:52] <Laney> no
[15:52] <seb128> (or virtual is if that didn't land yet)
[15:52] <Laney> https://launchpad.net/ubuntu/+source/udisks2
[15:52] <Laney> Desktop Packages
[15:52] <jbicha> I didn't update udisks2 to 2.7 because of FeatureFreeze
[15:53] <seb128> Laney, I disagree it should be on our team list but that's not a topic for the meeting
[15:53] <seb128> Laney, I can take on that one, I'm unsure if I can fix it but I can at least try to find the commit that regressed and report upstream
[15:53] <jbicha> (libblockdev needs a MIR anyway for udisks 2.7)
[15:54] <Laney> there's a comment that says it is fixed in 2.7.something
[15:54] <seb128> well I can find the commit then :-)
[15:54] <seb128> git bisect works either way
[15:54] <Trevinho> didrocks: about the comment, sure for the bug
[15:55] <Laney> k
[15:55] <Trevinho> didrocks: as for the order of elements, the fact the script is named like that it ensures it will run before the one you added which does the reset
[15:55] <didrocks> Trevinho: yeah, but will make sense to move all that in the same script, doesn't it?
[15:55] <Trevinho> but indeed the fact they're provided by different packages doesn't help to track this
[15:55] <Laney> umm
[15:55] <Laney> guess we're done with bugs then ...
[15:55] <didrocks> Laney: yeah, feel free to steal/move it :)
[15:55] <willcooke> thanks all
[15:56] <didrocks> thanks!
[15:56] <willcooke> #topic AOB
[15:56] <didrocks> oupss, that was for Trevinho the steal/move it
[15:56] <Laney> sounds like seb128 wants an action to slide udisks2 off us
[15:56] <seb128> we should review the list of components assigned to us at some point
[15:57] <seb128> I think there are some weird things in there
[15:57] <seb128> and things we don't have the experience to maintain/have been dealt with other team
[15:58] <seb128> like udisks was p_itti/foundation for a long time, I don't think anyone of us ever worked on it
[15:58] <willcooke> Lets take a look at the list soon (after 17.10 is out?) and take it from there
[15:59] <seb128> thanks
[15:59] <jbicha> udisks2 is basically in sync from Debain except for the exfat MIR
[16:00] <seb128> jbicha, that doesn't change the "who is responsible to look at issues on the Ubuntu side" in case similars to the one we were discussing now
[16:01] <jbicha> right, Desktop Team isn't really working on udisks
[16:01] <willcooke> I'll add a reminder to look at the list soon
[16:01] <willcooke> Any other AOB?
[16:02] <willcooke> 5
[16:02] <kenvandine> not here
[16:02] <willcooke> 4
[16:02] <jbicha> imagemagick and a font seeding question
[16:03] <jbicha> imagemagick (LP: #1717951) was more difficult than I expected because Debian has 2 different imagemagick variant packages: q16 and q16hdr
[16:03] <willcooke> jbicha, want to do that in the meeting, or shall we end here and continue with the dicussion?
[16:03] <jbicha> I think these 2 topics are fine after meeting
[16:04] <willcooke> kk, lemme end
[16:04] <willcooke> #endmeeting
[16:04] <meetingology> Meeting ended Tue Oct  3 16:04:12 2017 UTC.
[16:04] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2017/ubuntu-desktop.2017-10-03-15.30.moin.txt
[16:04] <willcooke> thanks all
[16:04] <willcooke> jbicha, ta, please do carry on
[16:04] <ricotz> hey desktopers
[16:04] <kenvandine> hey ricotz
[16:04] <ricotz> is there a final conclusion about firefox-esr?
[16:05] <Trevinho> didrocks: ack, where's managed the code of the other script?
[16:05] <Trevinho> didrocks: ubuntu-session code I mean
[16:05] <jbicha> one possibility is to do what Ubuntu GNOME and several flavors did by just shipping minimal /usr/share/gnome/applications/ .desktops for imagemagick
[16:05] <seb128> hey ricotz
[16:05] <jbicha> https://bazaar.launchpad.net/~ubuntu-gnome-dev/ubuntu-gnome-default-settings/ubuntu/files/head:/usr/share/gnome/applications/
[16:05] <Trevinho> I don't see it anymore in the bzr branches we used
[16:05] <seb128> ricotz, Olivier replied on the desktop list
[16:05] <ricotz> kenvandine, seb128, hey
[16:05] <didrocks> Trevinho: it's in gnome-session
[16:05] <Trevinho> ah i see it now https://code.launchpad.net/~ubuntu-desktop/gnome-session/ubuntu
[16:06] <ricotz> seb128, right, as mentioned earlier a took a shot at it and pushed it to the mozillateam ppa
[16:06] <didrocks> Trevinho: feel free to move it from there (I did write it)
[16:06] <seb128> ricotz, I read that; it's good to know but doesn't make a difference to what desktop team do? or do we expect us to revisit based on your ppa?
[16:07] <Trevinho> didrocks: ok
[16:07] <didrocks> Trevinho: add it to the landing, I'll review tomorrow if you ping me (shoot an email) at me :)
[16:07] <Laney> jbicha: that's OK to do I think
[16:07] <seb128> jbicha, I'm unsure to understand what you suggest/what are the options for imagemagick
[16:07] <Trevinho> didrocks: fine
[16:07] <ricotz> seb128, I would expect this to be revisited, and give those packages some testing and consideration
[16:08] <ricotz> seb128, of course maintaining Firefox 52 will end with 2018-06-26 at latest
[16:08] <jbicha> seb128: 1) we could try to do the package split but that is rather complex 2) we could have ubuntu-settings ship overrides to set NoDisplay=true for the imagemagick .desktop's like some flavors already do
[16:09] <jbicha> 3) we could just remove the ImageMagick .desktop (and maybe binary) from the imagemagick packages
[16:09] <jbicha> 4) we could just WONTFIX the issue for artful. I think that's all
[16:09] <willcooke> I think I'm the only person who thinks that we should ship a .desktop with IMagick, so if it should go away, then I can live with that
[16:09] <seb128> ricotz, I don't think we have interest in commiting to more firefox work and I don't think we want to commit to maintain esr even if you did some work on it, users can get it from your ppa if they want ... but check with willcooke maybe he thinks differently or you can explain why you think we should take on extra commitements
[16:10] <ricotz> seb128, jfyi, I am working on firefox with chris for time
[16:10] <jbicha> willcooke: you actually use that app?
[16:10] <seb128> ricotz, I know, and that's appreciated, but firefox != firefox-esr
[16:10] <ricotz> seb128, this is not "my" ppa
[16:10] <seb128> jbicha, I would vote for 2 or 3
[16:10] <willcooke> jbicha, nope, but *if* I did, and I installed it, and it was a GUI app, then I would expect there to be a .desktop
[16:11] <seb128> ricotz, sorry, typo, still it can stay in that ppa
[16:11] <willcooke> but I'm in a minority of one :)
[16:11] <seb128> ricotz, I don't think we want to official commit in maintaining it in the archive
[16:11] <ricotz> seb128, not sure what you mean, but I am aware of that, since I am doing firefox beta and firefox-trunk too
[16:11] <jbicha> ok, I'll work on #2 for imagemagick and I hope to ping y'all tomorrow about it
[16:11] <seb128> ricotz, I don't understand what makes you think that we might want to sign for work we said we didn't have the capacity to take on
[16:12] <willcooke> thanks jbicha
[16:12] <seb128> jbicha, thanks
[16:12] <seb128> jbicha, what was the font issue?
[16:12] <didrocks> jbicha: the alternative is to move it to "utilities" but we can refine next cycle if we hear protest :)
[16:12] <Laney> do they show up in startup applications with the nodisplay thing?
[16:12] <jbicha> font issue is LP: #1720809
[16:12] <Laney> guess not, that's for xdg autostart
[16:13] <Laney> nm me
[16:13] <seb128> Laney, is imagemagick a "startup application"?
[16:13] <Laney> TOO SLOW!
[16:13] <seb128> k
[16:13] <seb128> lol
[16:13]  * didrocks was writing the same thing
[16:13] <seb128> :)
[16:13] <didrocks> but too slow as well :p
[16:13] <jbicha> back when Firefox ESR was announced, Mozilla said that it wouldn't really be possible to fully backport security improvements to the ESR. Also ESR doesn't have near as many users
[16:14] <seb128> well imho we are commited to enough and we said no to add that one to our list
[16:14] <seb128> and having it in a ppa or not doesn't change that position
[16:15] <seb128> willcooke, ^ wdyt?
[16:15] <willcooke> I agree with seb128, we don't have capactity to take on more
[16:16] <ricotz> this will end with the release firefox ESR 59.2 anyway and just eases the transition to firefox 57+ for some enviroments which require native alsa support
[16:16] <ricotz> I see
[16:17] <seb128> willcooke, oh, one topic we should discuss at the next meeting is shifting the meeting to be one hour early (though that might fix itself for a cycle with DST)
[16:18] <willcooke> wfm
[16:18] <didrocks> +1
[16:18] <ricotz> seb128, so having like a community maintainer is not an option?
[16:18] <seb128> willcooke, several europeans requested for that because some are starting early and should be done before 6pm, also with the current team layout we don't have people much west in the U.S so it should be fine for everyone
[16:18] <willcooke> +1
[16:19] <willcooke> I'll email the team
[16:19] <seb128> thanks
[16:19] <didrocks> thanks willcooke ;)
[16:19] <seb128> ricotz, oh, desktop team doesn't have a lock on the archive, community can maintain firefox-esr in universe if they wish
[16:19] <seb128> or whoever wants to do that
[16:20] <seb128> ricotz, I'm not saying it shouldn't be in Ubuntu or maintained, just that our team isn't going to put its name on it officially
[16:21] <jbicha> I'm more comfortable with firefox-esr staying in a ppa for now. If it's in Ubuntu, people will assume it's supported (most people don't pay attention to main/universe)
[16:21] <ricotz> seb128, ok, I never suggested that the desktop-team should maintain it though ;)
[16:22] <seb128> ricotz, k, I'm unsure why you asked us/here then, but if you want to maintain it that's fine I think
[16:22] <ricotz> jbicha, seb128, the problem while using the debian version is uses the wrong googlekey and branding
[16:23] <jbicha> installing packages directly from Debian definitely isn't supported ;)
[16:23] <ricotz> seb128, I asked because it was a topic and is pretty much related to firefox which is going to maintained here
[16:24] <ricotz> yeah, but the other ppa mentioned on the list is simply doing that
[16:25] <jbicha> I assumed we were talking about the mozillateam ppa's which I trust more :)
[16:25] <ricotz> of course ;)
[16:26] <jbicha> except for Lubuntu which has already switched to pulseaudio, I don't see how having firefox-esr in a ppa is a problem for users
[16:27] <jbicha> seb128: did you see LP: #1720809 ?
[16:27] <Trevinho> didrocks: what's the reason for the script being shell-migration.18.08 and not 17.08?
[16:28] <didrocks> Trevinho: the reason is a typo at the time. I already renamed it in something that is staged
[16:28] <Trevinho> didrocks: ah, ok... :)
[16:28] <didrocks> but which is blocked on glib and Laney decided to wait for the merge
[16:28] <didrocks> so can't upload it
[16:28] <Trevinho> didrocks: I guessed that, ack ack
[16:28] <Trevinho> so..... the merge of mine should based on that?
[16:29] <didrocks> Trevinho: no, that's fine, I'll rebase and retest
[16:29] <didrocks> once the glib is in
[16:56] <seb128> jbicha, saw it but I've no opinion about fonts sorry
[16:56] <seb128> ricotz, k, fair enough
[16:57] <jbicha> ok, maybe didrocks has an opinion tomorrow :)
[17:02] <xnox> Laney, seb128 - i call bullshit on 32bit UEFI and i should step away from the keyboard.
[17:18] <Trevinho> seb128: can't ubuntu-session added to bileto?
[17:18] <Trevinho> > You must add ~ci-train-bot to ~ubuntu-desktop to continue
[17:18] <Trevinho> https://bileto.ubuntu.com/log/2967/build/10/
[17:21] <jbicha> gnome-session? but we don't use bileto for GNOME Stuff
[17:41] <xnox> Laney, re test-copy on armhf, upstream build passes
[17:41] <xnox> *sigh*
[18:12] <willcooke> night all
[18:12] <willcooke> it's very dark.
[18:13] <willcooke> :(
[18:13] <willcooke> Let's see what happens tomorrow ;)
[18:39] <seb128> Trevinho, we just do normal upload for those, we should stop using that service there is nobody maintaining it and it's mostly adding overhead now
[18:41] <Trevinho> seb128: well, ok for me... But I can't do the uploads otherwise so that would made the work more annoying for me actually... As I woud need to prepare the sources manually and ppas
[18:41] <Trevinho> not that I need to use it much nowadays, but at least for SRUs
[18:42] <seb128> Trevinho, well, as long as it keeps working you are free to use it, but for desktop updates just to a merge proposal against the packaging vcs or send a diff for sponsoring
[18:43] <Trevinho> seb128: ack, Didier will handle it
[18:43] <seb128> Trevinho, what change is that?
[18:43] <Trevinho> seb128: to keep unity and gnome shell settings separated
[18:43] <seb128> k
[18:43] <Trevinho> seb128: so upgraders won't mess up
[18:46] <seb128> Trevinho, let's see if Didier reviews it tomorrow otherwise I can have a look
[18:49] <Trevinho> seb128: no worries, he already checked most of it, he just wanted a change which I did on that session side
[18:49] <seb128> k, good
[18:49] <seb128> he should comment on the mps on those cases
[18:49] <seb128> so others know he started reviewing
[18:51] <Trevinho> seb128: that MP is new, but he did it in https://code.launchpad.net/~3v1n0/unity/use-scaling-ubuntu-schemas-settings/+merge/331667
[18:51] <seb128> k
[18:51] <Trevinho> As last (my) night i wrote to him here, before going to bed, so we synced :)
[19:04] <seb128> I saw :-)
[19:27] <xnox> Laney, this test-copy is full of sigh
[19:27] <xnox> i have no idea what is going on
[19:27] <xnox> it's not linked with anything but libc when build, but systemd-tests has it linked with the $world like selinux and what not.
[19:28] <xnox> the small binary execs fine; the $world binary bombs out
[20:51] <xnox> Laney, omg omg omg omg
[20:55] <xnox> -rwxr-xr-x root/root     38360 2017-08-30 10:22 ./usr/lib/systemd/tests/test-copy
[20:55] <xnox> -rwxr-xr-x root/root     30168 2017-09-26 15:38 ./usr/lib/systemd/tests/test-copy
[20:56] <xnox> the crutial difference between the two is the file size.... as test-copy uses itself as the source file, and it expects the source to be larger than 32000
[20:56] <xnox> doko, your armhf toolchain compiles too small binaries
[20:56] <xnox> in latest artful
[20:59] <doko> xnox: you're the first one to complain about too *small* binaries ... sigh
[21:05] <xnox> doko, i know it's tongue-in-cheek complaint. it's really awesome =) but sometimes things are too good ;-) basically this is the reason why src;systemd was stuck in proposed all last week.
[21:07]  * tsimonq2 whispers, "fix the test, don't fix the compact size" :P
[21:12] <xnox> tsimonq2, you wish =) this will be quality engineering of testing source size and skipping; or just adding dh_strip -X test-copy
[21:13] <tsimonq2> hehehehe :)


[08:46] <sekon_> cjwatson:
[08:46] <sekon_> 19:55 < cjwatson> sekon_: it's unpacked into /casper/filesystem.squashfs
[08:46] <sekon_> thanks :)
[08:46] <sekon_> 19:56 < cjwatson> the .deb itself isn't stored
[15:41] <CIA-16> hw-detect: cjwatson * r1473 ubuntu/ (73 files in 3 dirs): merge from Debian 1.88
[15:43] <CIA-16> hw-detect: cjwatson * r1474 ubuntu/debian/po/kn.po: msgmerge
[15:45] <CIA-16> hw-detect: cjwatson * r1475 ubuntu/debian/changelog: releasing version 1.88ubuntu1
[20:33] <bdmurray> is /var/log/installer/cdebconf not created by default?
[20:34] <bdmurray> or is it only created using certain install methods...
[20:34] <cjwatson> it's only created by d-i
[20:34] <cjwatson> ubiquity doesn't
[20:35] <bdmurray> okay, that's what I guessed
[20:35] <bdmurray> cjwatson: I was looking at bug 885442
[20:35] <ubot2> Launchpad bug 885442 in debconf "Unable to dump debconf database" [Critical,New] https://launchpad.net/bugs/885442
[20:53] <cjwatson> bdmurray: right, I brought that up in the session, but IIRC Daviey thought it was a server install
[20:53] <cjwatson> I believe he took an action to provide more details
[20:53] <cjwatson> I didn't want to rule out some other kind of breakage
[20:54] <bdmurray> cjwatson: session?
[20:59] <cjwatson> that bug arose from a UDS session on adding a non-sucky tool to generate a preseed file from an install
[20:59] <cjwatson> I asked Dave to file it for reference


[02:11] <bleedingmonk> i would like a cloak
[02:11] <bleedingmonk> can anyone help me get it?
[02:12] <rww> bleedingmonk: are you an Ubuntu Member?
[02:12] <bleedingmonk> yeah
[02:12] <bleedingmonk> :)
[02:12] <rww> bleedingmonk: can you link your Launchpad page, please?
[02:13] <bleedingmonk> https://launchpad.net/~bleedingmonk
[02:13] <bleedingmonk> i have a very old forum user
[02:13] <rww> bleedingmonk: by "Ubuntu Member", I mean https://wiki.ubuntu.com/Membership
[02:13] <bleedingmonk> but i didnt use it now... i cant reset its pass also... :S
[02:14] <rww> Ubuntu's IRC Council only does cloaks for people who've gone through that membership process. For an unaffiliated cloak, see #freenode.
[02:15] <bleedingmonk> :(
[02:16] <bleedingmonk> will try! :)
[02:17] <bleedingmonk> thanks anyway buddy! :)
[02:17] <rww> you're welcome
[12:57] <ubot4`> ikonia called the ops in #ubuntu-marketing ()
[14:55] <ubot4`> In #ubuntuone, thisfred said: != True is better written as not
[19:31] <m4v> oh btw, BlouBlou joining #kubuntu-es an insulting me for no reason. http://privatepaste.com/5b896b2aeb
[19:37] <Tm_T> can't say I'm surprised
[19:47] <m4v> that's great, 'cause he always tries to put an "I'm a good person" act.


[16:47] <brianb> does anyone know the reason why both Firefox and Google Chrome (inc Chromium) fail to load and display adobe flash content on web pages in ubuntu 12.04?
[16:49] <micahg> brianb: huh? wfm
[16:50] <brianb> Also is both Firefox and google Chrome running in protected mode via the sandbox mechanism - which could be the reason why both browsers fail to play out a flash website content?
[16:51] <micahg> does it work in non protected mode?
[16:51] <brianb> well how do you switch off protected mode in each browser?
[16:52] <micahg> well, you can try in a new firefox profile (firefox -P)
[16:52] <brianb> how do i do that
[16:52] <micahg> run it in a terminal or alt + f2
[16:53] <brianb> with firefox runing?
[16:53] <micahg> no
[16:53] <brianb> explain please
[16:55] <micahg> is this flash protected mode or the browser's protected mode?
[16:56] <brianb> well thats an interesting question it could be either
[16:57] <micahg> there was a problem with firefox/flash protected mode, I don't know if it's fixed: http://support.mozilla.org/en-US/questions/929134
[16:58] <brianb> ok so that sounds like the sandox mech
[16:58] <brianb> which i think is built into mozilla
[16:58] <micahg> we also don't ship flash 11.3, is this a problem with the flash from the Ubuntu archive?
[16:59] <brianb> however the problem i have is that both google chrome and mozilla will not play any flash content and i have doubled checked to make sure that both have a flash plug in installed
[17:00] <micahg> chrome ships its own flash
[17:00] <brianb> Chrome does but chromium i think does not
[17:00] <micahg> right
[17:00] <brianb> i stand to be corrected on that
[17:01] <brianb> now lets take Chrome which I have installed
[17:01] <brianb> it has as you rightly said flash built into the browser
[17:01] <micahg> for Chrome you'll have to ask them
[17:02] <brianb> so if i try and display content from the BBC news (live ) what should happen is i should get a both audio an video content
[17:04] <brianb> what i actual get is a blank space where the content should appear and a message - could not load shockwave flash
[17:05] <brianb> the message appears at the top of the chrome browser
[17:05] <micahg> http://support.google.com/chrome/bin/answer.py?hl=en-GB&answer=108086
[17:06] <brianb> the flash is enabled i have checked that
[17:07] <brianb> it would appear to me that the trigger mech to load flash is not working hence the message
[17:07] <brianb> which begs the question is it a problem with the sandbox protected mode of flash?
[17:08] <micahg> in the support article it mentions a system and built in version, maybe try with the system version
[17:10] <brianb> i have tryed both chrome and chromium both yeild the same problem
[17:10] <brianb> also same with firefox
[17:11] <brianb> if it was a google chrome issue that that would effect the chrome browser
[17:11] <micahg> which version of flash shows up in Firefox?
[17:11] <brianb> but since it affects both browsers i am suspecting that it could be a scripting issue with ubuntu 12.04
[17:12] <micahg> 12.04 works fine with the version in the archive
[17:13] <brianb> firefox shockwave flash 11.2 r202
[17:13] <brianb> updated 27/11/12
[17:14] <brianb> same ver used with chrome
[17:14] <micahg> weird
[17:16] <brianb> would there be any hardware that could cause this issue?
[17:17] <brianb> after all its just a extention/plugin for a browase
[18:37] <cousin_luigi> Greetings.
[18:37] <micahg> hi cousin_luigi
[18:43] <cousin_luigi> Are there 64 bit builds of ff18 beta?
[18:44] <kbrosnan> micahg: adobe has stop making new releases of flash for npapi browsers. sec updates only for the flash 11.2 branch
[18:44] <micahg> cousin_luigi: yes, in the PPA
[18:44] <micahg> kbrosnan: yeah
[18:44] <kbrosnan> so there is no sandboxed mode for Fx
[18:45] <micahg> kbrosnan: ah, ok
[18:49] <cousin_luigi> micahg: firefox-next?
[18:49] <micahg> cousin_luigi: yeah
[18:50] <cousin_luigi> micahg: is launchpad down or is it just my connection?
[18:50] <micahg> chrisccoulson: can I reenable publishing on firefox-next?
[19:24] <cousin_luigi> bbl