[01:32] <desrt> robert_ancell: 'nobody' account, for example
[01:32] <desrt> and nfsnobody, i think also exists
[01:33] <desrt> in general, there are a few high-numbered accounts that are not normal users, and we wanted to avoid those
[01:33] <robert_ancell> desrt, they're already blacklisted explicitly
[01:34] <robert_ancell> oh, I see you disable the blacklist and use this instead.
[01:36] <robert_ancell> RAOF, I forget again, can you cancel uploads?
[01:36] <desrt> robert_ancell: we were trying to move away from heuristics...
[01:37] <RAOF> robert_ancell: No, but if it's still in -proposed you can reject it.
[01:37] <robert_ancell> RAOF, how do I do that?
[01:37] <desrt> RAOF: hey... how's that mainloop unhate going?
[01:37] <RAOF> desrt: Generating ASIO rage.
[01:37] <RAOF> desrt: But the prerequisites are basically done, so I should be able to *actually* provide you with a manual dispatch option soon.
[01:38] <desrt> RAOF: cool.  keep me updated :)
[01:38] <RAOF> robert_ancell: You ask me to reject an upload :)
[01:38] <desrt> robert_ancell: btw: big drawing changes in gdk lately.... seems like maybe you were right to stay on 3.12 ;)
[01:38] <robert_ancell> RAOF, right, can you reject accountsservice/0.6.37-1ubuntu4 please?
[01:38] <robert_ancell> desrt, ha!
[01:38] <RAOF> robert_ancell: Sorry, no can do. It's already gone through.
[01:39] <robert_ancell> man, it was in proposed seconds ago :(
[01:39] <RAOF> Hm. Or maybe I actually *don't* know how to do this...
[01:41] <robert_ancell> meh, I'll just do a new upload
[01:41] <robert_ancell> desrt, so what do you do on systems that have 100000s of users and but still have a "nobody" account?
[01:42] <robert_ancell> this is the sort of user who is confused by the change
[01:42] <desrt> robert_ancell: enable heuristics?
[01:42] <desrt> the situation is kinda crap :(
[01:42] <robert_ancell> it's compile time right?
[01:42] <desrt> ya...
[01:42] <desrt> you could also up the max
[01:42] <robert_ancell> yeah, that doesn't seem right
[01:42] <desrt> that was possible in login.defs before
[01:42] <desrt> but now it's compile-time
[01:43] <desrt> apparently login.defs is not universal
[01:43] <robert_ancell> desrt, right, but if you set UID_MAX to 100000 then the nobody user will show because there's no blacklist anymore
[01:43] <desrt> exactly.
[01:43] <desrt> do we support uids > 65k?
[01:43] <robert_ancell> apparently
[01:43]  * desrt thought the FS had only 16bits for owner/group
[01:43] <robert_ancell> it's undefined. I guess it depends on what fs you are using
[01:44] <robert_ancell> uid_t is undefined I mean
[01:44] <desrt> so ext2/3/4 support 16bit uids
[01:44] <desrt> but they have an extended attribute for higher numbers
[01:44] <robert_ancell> yeah
[01:45] <desrt> so ya... i guess it's possible
[01:45] <robert_ancell> I think we should just consider uid < UID_MIN and a small blacklist of known legacy system UIDS greater than that
[01:45] <desrt> hmm.  chown doesn't like large-number uids
[01:46] <robert_ancell> oh, I'm sure loads of other code falls apart but for the purposes of what is considered a system user to a-s I think it has no concept of an upper limit
[01:46] <desrt> ah ya... goes up to 2^32 indeed
[01:47]  * desrt had one too many digits
[01:48] <desrt> maybe we should be changing our nobody user....
[01:48] <desrt> 2^32-1 instead of 2^16-1
[01:48] <desrt> having nobody in the middle of the range of normal valid uids is a bit weird
[01:48] <robert_ancell> desrt, since the number is baked into the fs bits we can never move it right?
[01:58]  * robert_ancell heads out for a bit
[02:01] <desrt> robert_ancell: would be a new-install thing
[02:01] <desrt> the number itself means nothing in terms of the fs -- only in terms of existing installs on those fses
[03:36] <pitti> Good morning
[03:39] <TheMuso> Morning pitti, an early start for you today it seems. :)
[03:39] <pitti> TheMuso: indeed, couldn't sleep any more after my wife got up; head full of ideas :)
[03:56] <TheMuso> pitti: Ah that sucks.
[08:11] <seb128> good morning desktopers!
[08:48] <seb128> shrug
[08:48] <seb128> * Other changes:
[08:48] <seb128> - This release changes the default behavior of gtk-update-icon-cache
[08:48] <seb128>   to not include image data into the icon cache. Use the new
[08:48] <seb128>   --include-image-data flag to get the old behavior back.
[08:48] <seb128> GTK2 2.24.24 stable update
[08:49] <Laney> oh yeah was going to look at that one
[08:49] <Laney> are you taking it?
[08:49] <didrocks> "nice" :/
[08:49] <seb128> go GTK, keep doing such changes
[08:49] <seb128> Laney, no, I'm not, I was just reading the ftp list changes
[08:49] <seb128> there is a new glib as well btw ;-)
[08:49] <Laney> indeed
[09:40] <Laney> grah
[09:41] <Laney> looks like dspam died in the overnight badness
[09:41] <Laney> meaning that mail was being refused
[09:41] <Laney> (with a bounce)
[09:41] <Laney> wonder how many subscriptions I lost due to that
[09:56] <seb128> Saviq, seems like unity8 migrated, the logout silo is for the next round? ;-)
[09:56] <Saviq> seb128, in testing
[09:56] <seb128> Saviq, thanks
[10:02] <seb128> larsu, it could be useful if you wrote a https://wiki.ubuntu.com/Process/Merges/TestPlan/gsettings-qt
[10:02] <seb128> larsu, just take one of the indicator one, e.g as a base https://wiki.ubuntu.com/Process/Merges/TestPlan/indicator-messages
[10:02] <seb128> larsu, something easy, just how you usually test updates/changes, like run the example from the source, one test scenario with settings maybe as well
[10:03] <larsu> seb128: make check!
[10:03] <larsu> just kidding, will do
[10:03] <seb128> ;-)
[10:03] <seb128> danke
[10:03] <larsu> thanks for the pointer
[10:03] <seb128> yw
[10:03] <seb128> btw I'm asking because I just put your changes from yesterday up for landing
[10:04] <larsu> ah cool thank you!
[10:04] <seb128> yw ;-)
[10:36] <larsu> seb128: re those manual test cases. Does it make sense to add those to the source and copy them to the wiki as described in https://wiki.ubuntu.com/Testing/TestCaseFormat ?
[10:37] <seb128> larsu, your call, it doesn't hurt to have them in the source I guess (I know ted has been doing that for the stuff he works on)
[10:38] <larsu> okay, thanks
[12:54]  * didrocks grumbles about http://bugs.python.org/issue9351
[13:00] <ogra_> didrocks, just use go then :P
[13:02] <didrocks> ogra_: volonteering yourself? :)
[13:02] <ogra_> hahahahaha
[13:02] <ogra_> ha
[13:02] <ogra_> ha
[13:02] <ogra_> ...
[13:02] <ogra_> ha
[13:03] <didrocks> :p
[13:04] <ogra_> :)
[13:56] <didrocks> ok, I'm going for a late run, I should be back just on time for the meeting :)
[13:56] <didrocks> see you later!
[14:12] <tkamppeter> Someone succeeded to run the current Adobe Reader under the current Ubuntu? I have a highly DRMed PDF file and cannot open it.
[14:29] <ChrisTownsend> seb128: Hey, got a moment to chat about https://bugs.launchpad.net/unity/+bug/1281058 for Unity Trusty SRU?
[14:29] <seb128> ChrisTownsend, hey, sure
[14:30] <ChrisTownsend> seb128: Cool.  So I was under the impression that the translations for this is not there for Trusty.  Is this true?
[14:31] <ChrisTownsend> seb128: As we'd like to include this in the next Unity Trusty SRU.  I just want to make sure about the translations.
[14:32] <ChrisTownsend> seb128: There is some question that the translations are part of unity-greeter and Unity gets the translations for "free" from that.
[14:32] <seb128> ChrisTownsend, translations are not included in the current langpacks no
[14:33] <seb128> I guess the template got ovewritten by one of the unity SRUs
[14:33] <seb128> you could use the translation from unity-greeter I guess
[14:33] <seb128> you would need to change the gettext domain for that though
[14:33] <seb128> it feels hackish
[14:33] <ChrisTownsend> seb128: Yeah, that is hackish.
[14:34] <ChrisTownsend> seb128: Well, this is priority bug with a string.  What's your recommendation on how to proceed?
[14:35] <seb128> ChrisTownsend, the change is going to be in the next unity SRU?
[14:36] <ChrisTownsend> seb128: Well, that's what I'm trying to determine.  I don't think we should include it if it's not translated, but we need to get it in when the translated strings are available.
[14:36] <ChrisTownsend> seb128: But we do need to get it in though.
[14:38] <seb128> ChrisTownsend, then we need to upload manually a pot include that string to launchpad, then wait for a langpack export
[14:43] <Trevinho> seb128: how long that would take, approx?
[14:44] <seb128> Trevinho, not sure when the next langpack trusty update is due
[14:44] <seb128> dpm, pitti: do you know?
[14:44] <pitti> seb128, Trevinho: we just did one two weeks ago (https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA)
[14:45] <pitti> so supposedly not that soon, unless there's something urgent to fix
[14:45] <seb128> pitti, right, that doesn't help us to resolve the current question ;-)
[14:45] <pitti> "whenever someone starts the community verification process"
[14:45] <pitti> last time, GunnarHj kindly did it
[14:45] <Trevinho> pitti: the problem is that there's this OEM prio bug that needs some new translations (already provided by unity-greeter)...
[14:46] <seb128> pitti, they need to add an user visible string to unity, if we don't want to slap in in the face of users untranslated, we need to upload an updated template to launchpad, get translators to do their work and then do an export
[14:46] <seb128> then only we can upload the code change in unity
[14:46] <pitti> Trevinho: as I said, "unless there's something urgent to fix" - best to create an SRU bug then with specific instructions which translatoins to watch out for, and testing the ones in https://launchpad.net/~ubuntu-langpack/+archive/ppa
[14:46] <seb128> Trevinho, you might as well try to hack around by loading that string from the unity-greeter domain then...
[14:47] <Trevinho> seb128: we might yes, let me see
[14:47] <pitti> seb128: ah, that sounds like that SRU needs to happen first, then?
[14:47] <Trevinho> (not lovely, but still...)
[14:47] <pitti> Trevinho: so in short, don't wait for the update to happen, ask for it :)
[14:47] <seb128> pitti, the langpack needs to include the string before we can SRU the unity change
[14:47] <Trevinho> pitti: ok, makes sense :)
[14:47] <seb128> or we can declare the untranslated string fine
[14:48] <pitti> seb128: I'm afraid that doesn't work; it only gets imported into LP via an upload
[14:48] <seb128> it's going to happen only in case where other users are logged in while you try to stop the system
[14:48] <pitti> we can keep that in -proposed until the corresponding langpacks are in -proposed too, and release both together
[14:48] <seb128> pitti, no, we can tweak the template to include the string and upload to https://translations.launchpad.net/ubuntu/trusty/+source/unity/+pots/unity/+upload
[14:48] <seb128> I did that before
[14:49] <pitti> ah, if that works, sure
[14:49] <seb128> my template just got overwritten by a SRU import since
[14:49] <pitti> why wasn't it included in that SRU, too then?
[14:49] <pitti> changing it *only* in LP is wrong
[14:49] <pitti> changing it in trunk and in LP is fine
[14:50] <seb128> because dh_translation regenerate the pot at package build
[14:50] <seb128> the code change is not there
[14:50] <seb128> because of the reason described before
[14:50] <seb128> need the translations in place before we do the code changes
[14:50] <seb128> though I guess we would have the code in but commented
[14:51] <seb128> that would be good enough to have intltool-update to pick the string
[14:51] <pitti> I don't understand that
[14:51] <pitti> if the string isn't translated now, why can't it be marked translatable and uploaded to -proposed
[14:51] <pitti> and then the translations happen on LP
[14:52] <seb128> the string doesn't exists in the code
[14:52] <seb128> they want to add a new dialog/string
[14:52] <seb128> it's not like it was there currently and displayed in english
[14:52] <seb128> so if we add it first, we have an user "regression"
[14:52] <pitti> right, so we can do that in -proposed
[14:52] <pitti> or in utopic even, which is what SRUs need to do anyway
[14:52] <seb128> just keep the SRU in proposed for ages?
[14:52] <seb128> it's in utopic
[14:53] <pitti> if it's as urgent as you say, then it shouldn't be "ages", if we have translators already translating it in utopic, and can get some to do the ones we need for OEM
[14:54] <seb128> right, the variable there is the time it's going to take to get new langpacks out and validated
[14:54] <pitti> but I suppose you could also re-import it into LP manually, if for some reason the code change can't happen first?
[14:54] <seb128> but I guess we can take on some locales showing an english UI
[14:54] <pitti> well, we aren't going to get it translated to all ~ 200 languages anyway :)
[14:55] <seb128> the SRU team is not so happy to introduce a non translated UI in front of users
[14:55]  * pitti -> ubuntu on air, sorry
[14:55] <seb128> so that was trying to find a middle ground solution
[14:55] <seb128> pitti, thanks for the chat!
[14:55] <Trevinho> ta
[14:55] <pitti> seb128: back in ~ 1 hour, for now it's pitti TV time :)
[14:56] <seb128> pitti, good luck with the hangout as well ;-)
[14:56] <pitti> merci!
[15:22] <didrocks> woot, even time to take a shower before the meeting!
[15:23] <seb128> didrocks, just went for exercice?
[15:23] <didrocks> yep ;)
[15:23] <didrocks> it wasn't that hot today, so running late was acceptable
[15:24] <didrocks> seems they shoot a movie in the park btw…
[15:30] <seb128> hey
[15:30] <seb128> it's meeting time!
[15:31] <seb128> qengho, Laney, tkamppeter, desrt, attente, larsu, didrocks, FJKong, hey
[15:31] <qengho> Aiee!
[15:31] <didrocks> hey
[15:32] <FJKong> hey
[15:32] <seb128> ok, let's get started
[15:32] <seb128> qengho, you start ;-)
[15:32] <qengho> Just one item that *looks* small.
[15:32] <qengho> * Testing cr 35.0.1916.153. Fixing patching bugs: New high-dpi geometry problem. Testing session saving/restoration backport.
[15:33] <qengho> EOF
[15:33] <seb128> is that the current stable? is it landing in Ubuntu this week? ;-)
[15:34] <qengho> It's upstream's "stable". It should land as soon as it's better than the last version!  Yes, this week. :)
[15:34] <seb128> I see that Debian already landed it for a week to their stable
[15:34] <seb128> great
[15:34] <seb128> qengho, thanks
[15:34] <seb128> Laney, hey
[15:34]  * Laney crawls out of the swamp
[15:34] <Laney> • Finish evo/e-d-s 3.12 transition
[15:34] <Laney> • Quite a number of merges: packagekit, sane-backends, inkscape, lcms2, others
[15:34] <Laney> • Upstream updates (mostly in Debian too): gtk2 glib2.0 folks (see below) vala
[15:34] <Laney> • Work with Renato on folks update, do this in Debian
[15:34] <Laney> ∘ Required some zeitgeist fixes first
[15:34] <Laney> ‣ In Debian this broke stuff: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752482 - firefighting of this issue, seems fixed in new upstream release. Pending testing results & NMU.
[15:34] <Laney> • Look at theme problems in qt4 in Unity, turns out to be because we're not setting the deprecated(!) GNOME_DESKTOP_SESSION_ID any more. Patch upstart to set this.
[15:35] <Laney> ☀
[15:36] <seb128> Laney, thanks
[15:36] <seb128> tkamppeter, hey
[15:37] <seb128> no tkamppeter I guess
[15:37] <seb128> desrt, your turn ;-)
[15:37] <desrt> hi
[15:38] <desrt> not the most productive week -- got stuck in a number of debugging-the-compiler/library situations
[15:38] <desrt> got snagged by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731509 for example
[15:38] <desrt> but i did manage to get the fast mutexes finished and ready to merge -- they will go in probably today or tomorrow
[15:39] <desrt> also had a fight today with some new optimisations in gcc 4.9... sigh.
[15:39] <desrt> all in all one of those "learned a lot of things that i wish i didn't have to know...." weeks
[15:40] <seb128> yeah, I was just reading the #gtk+ backlog
[15:40] <seb128> compiler bugs are fun
[15:40] <desrt> don't get me started....
[15:40] <desrt> thing is -- this is arguably not a compiler bug
[15:40] <desrt> they'd tell me to complain at glibc
[15:40] <desrt> and glibc would tell me to complain at the C99 spec authors...
[15:41] <desrt> because it turns out that you cannot, in the general case, use memcmp() on an array.  go figure.
[15:41] <seb128> you are right, I should not get you started on that ;-)
[15:41] <seb128> desrt, thanks
[15:41] <seb128> attente, hey
[15:42] <attente> seb128: hey
[15:42] <attente> work on g-s-d, g-c-c, gnome-shell for the accountsservice patch
[15:42] <attente> g-s-d and gnome-shell work is ready, wrapping up g-c-c work which should be ready soon
[15:42] <attente> eof
[15:42] <desrt> \o/
[15:42] <seb128> nice
[15:43] <desrt> attente: if you need reviews, you know where to find me
[15:43] <seb128> seems to make desrt happy as well ;-)
[15:43] <attente> desrt: sure :)
[15:43] <desrt> attente: at the weston centre, most probably :p
[15:44] <seb128> attente, did you have anything still waiting for sponsoring?
[15:44] <seb128> I did the gtk sponsoring to utopic, I guess we should also get that to trusty once it has got some testing?
[15:44] <desrt> seb128: do we want to discuss the possibility of including the mir backend in the mainline uploads of gtk to the archive?
[15:45] <desrt> it's not in super-working form, but it does work.... and it's very isolated, so it's highly unlikely to regress the existing code
[15:45] <attente> seb128: right, i forgot, there's that u-g-m MP that tedg was reviewing, but was blocked by not having that gtk patch
[15:45] <seb128> desrt, we should discuss that, but having robert_ancell around when we do would be useful
[15:45] <desrt> k
[15:46] <attente> seb128: and i guess there's just that g-s-d sru, but i don't know if it's been uploaded to trusty-proposed yet
[15:46] <desrt> might be nice to figure out sooner or later what our workflow will look like there, because it's going to be strange
[15:46] <seb128> attente, g-s-d has been uploaded/approved and is being tested
[15:46] <attente> seb128: oh, ok, thanks for that :)
[15:46] <seb128> yw!
[15:47] <seb128> attente, feel free to ping tedg ont he u-g-m review I guess
[15:47] <seb128> I can do a landing for it then
[15:47] <attente> ok
[15:47] <seb128> attente, thanks
[15:47] <seb128> desrt, for what? the GTK Mir backend?
[15:47] <seb128> well, I guess it's going to be "have it as a distro patch on 3.12" for this cycle
[15:48] <seb128> which is already what we have, so no real issue
[15:48] <seb128> then depends on what it goes upstream
[15:48] <seb128> what->when
[15:49] <seb128> but we need robert_ancell for that discussion
[15:49] <desrt> seb128: ya... just pondering how we track the changes and where we keep them
[15:49] <desrt> indeed
[15:50] <seb128> ok, next is larsu if he's there
[15:50] <seb128> he said he would probably be away but send me his update before, but I don't think he actually did
[15:50] <seb128> larsu, ?
[15:50] <seb128> ok, I guess he's not around then
[15:50] <seb128> didrocks, hey
[15:51] <didrocks> yep ;)
[15:51] <didrocks> * Tweak and finished the category and framework loader functionality
[15:51] <didrocks> * Put this under tests and happily reached the bar of 120 tests!
[15:51] <didrocks> * Start fighting with the CLI with argparse and shell completion to get auto-registration and generation (and got back to some popular old python bugs…)
[15:51] <didrocks> * Try to fix and finally disabled Travis CI as it's running under 12.04 and we depend on python 3.4. Unfortunately, there is no pypi python-gobject and so, no virtualenv 3.4 on 12.04 to use system libs… I'm fallbacking at running the tests manually on my machine until 14.04 is available in Travis.
[15:51] <didrocks> * Some MIR-review work (some more onthe list)
[15:52] <seb128> oh, didrocks having some free slots again for archive activities, nice ;-)
[15:52] <seb128> didrocks, do you know when Travis plan to provide 14.04? waiting for .1?
[15:52] <didrocks> seb128: seems it's "in the work" since the last couple of month, but no ETA yet
[15:52] <didrocks> however, it's a popular topic on their bugtracker
[15:52] <didrocks> so I guess it will come soon :)
[15:52] <seb128> I can imagine ;-)
[15:53] <seb128> didrocks, thanks (and good work on the tests front ;-)
[15:53] <didrocks> thanks ;)
[15:53] <seb128> FJKong, hey, do you have anything to share this week?
[15:54] <happyaron> hi, late...
[15:54] <seb128> happyaron, hey, same ... if you have anything to share, now is the time!
[15:55] <happyaron> I'm working on the git migration, package auto-release for Sogou, and is waiting to see what to do for cinnamon
[15:55] <Laney> what is the git migration?
[15:55] <happyaron> we decided to not use bzr anymore for the project
[15:55] <seb128> what project?
[15:55] <happyaron> Sogou
[15:55] <seb128> oh, ok
[15:56] <attente> does that mean we no longer need to work on the fcitx-transition for unity?
[15:56] <happyaron> don't think so, just being too busy
[15:56] <didrocks> the package auto-release shouldn't use/be coordinated with the CI team?
[15:56] <happyaron> didrocks: for CI I think maybe, for auto-release no.
[15:57] <didrocks> happyaron: not sure I understand exactly what you mean by "auto-release" then :)
[15:58] <happyaron> didrocks: well, that's preparing packages for all commits with different version of components for QA
[15:58] <didrocks> happyaron: yeah, that's exactly what we do in CI and what the CI team is in charge, hence the "you should talk to them"
[15:58] <happyaron> OK
[15:59] <happyaron> but hell, the project we are working on is tightly following Sogou's normal development/release procedure
[15:59] <seb128> ok, let's discuss those details out of the meeting
[15:59] <seb128> happyaron, thanks
[16:00] <happyaron> :)
[16:00] <seb128> ok, my turn then
[16:00] <seb128> sponsoring (g-s-d/trusty, gtk3, eog)
[16:00] <seb128> • desktop updates (eog)
[16:00] <seb128> • handled CI landings (indicator-keyboard, u-g-m, ubuntu-themes, libdbusmenu-qt)
[16:00] <seb128> • landed the u-s-s wizard and then some bluetooth improvements
[16:00] <seb128> • debugged unity8-desktop issues (online accounts segfault, packagekit issues, indicator not starting, platform-api/backend issues)
[16:00] <seb128> • looked at some ubuntu-system-settings bugs, fixed a few UI issues in the updates panel
[16:00] <tkamppeter> seb128, sorry, I have missed it.
[16:00] <seb128> with the usual "reviewed errors.ubuntu.com, launchpad, kept an eye on SRUs, etc"

[16:00] <tkamppeter> seb128, here is what I did:
[16:00] <didrocks> seb128: how is that handover for u-s-s going?
[16:00] <seb128> tkamppeter, ok, your turn
[16:01] <tkamppeter> - Mentoring of GSoC students
[16:01] <tkamppeter> - Some organizational stuff for OpenPrinting Summit.
[16:01] <tkamppeter> - Bugs.
[16:02] <seb128> tkamppeter, thanks
[16:02] <FJKong> hey I am still working on sogou Input method project
[16:03] <seb128> FJKong, ok, thanks
[16:03] <seb128> didrocks, not so handed over yet, I know Pat is looking at the bug and trying to organize work
[16:03] <seb128> well, we have people doing work
[16:03] <seb128> cyphermox did some bluetooth improvements
[16:03] <didrocks> seb128: hoping for you it's happening soon to free you more cycles ;)
[16:03] <seb128> Ken is looking at some ofono changes
[16:04] <seb128> yeah
[16:04] <seb128> to be honest we didn't spent to much efforts on it recently, I mostly ignored it for over a months
[16:04] <seb128> just did some landing recently and looked at some UI issues/bugs today
[16:04] <seb128> but yeah
[16:04] <seb128> ok
[16:04] <seb128> is there any other topic?
[16:05] <seb128> seems not
[16:05] <seb128> let's wrap then
[16:05] <seb128> thanks everyone
[16:06] <Laney> thanks!
[16:06] <didrocks> thanks everyone!
[20:35] <seb128> jdstrand, thanks for the work on adding an apparmor profile to ubuntu-system-settings ... do you plan to do a merge request with the changes?  (you added debdiffs ... do you plan to upload directly?)
[20:45] <seb128> robert_ancell, hey
[20:45] <robert_ancell> hello
[20:45] <seb128> how are you?
[20:46] <seb128> robert_ancell, desrt mentioned today, during the weekly meeting, that we should discuss landing the GTK Mir backend
[20:46] <seb128> what do you think? does it same ready for that?
[20:46] <desrt> specifically, in the standard gtk packages in the distro
[20:47] <seb128> right, sorry, landing = upload to utopic
[20:47] <desrt> if we want this in by U we need to figure out the workflow
[20:47] <desrt> ie: periodically generate one mega-patch from an upstream gtk branch, or what?
[20:48] <robert_ancell> We just need the overlay scrollbar changes to land really and then we might as well. It's not amazing but there's no real cost to releasing it
[20:48] <robert_ancell> I'd say one mega-patch
[20:48] <seb128> that seems the easiest way to include it yes
[20:48] <seb128> robert_ancell, why do we need the overlay change?
[20:48] <desrt> one thing to consider is that this causes gtk to take a dependency on the mir client library
[20:48] <robert_ancell> It would mean that libmirclient is included on the image, has anything else pulled it in yet?
[20:48] <seb128> robert_ancell, I'm going to make that land tomorrow
[20:48] <robert_ancell> seb128, otherwise that GTK+ module will crash
[20:49] <jdstrand> seb128: working on it now. awe is going to coordinate the landing
[20:49] <seb128> jdstrand, ok, please go through the CI landing, otherwise you are going to invalidate silos/force them to rebase
[20:49] <jdstrand> seb128: yes, he said he would do that
[20:49] <seb128> great
[20:49] <seb128> jdstrand, thanks
[20:49] <robert_ancell> libmirclient seems fairly lightweight
[20:50] <seb128> robert_ancell, shrug, that's going to be an issue
[20:50] <jdstrand> I'm just doing the lowlevel stuff for the feature they wanted, they get to land it :)
[20:50] <desrt> robert_ancell: only crashes if you run with the mir gdk backend, right?
[20:50] <robert_ancell> desrt, yes
[20:50] <seb128> ;-)
[20:50] <seb128> robert_ancell, ignore what I just said
[20:50] <robert_ancell> these modules were just assuming the GDK backend was the X11 one
[20:50] <seb128> mir is already in main
[20:50] <seb128> I though it was not
[20:50] <desrt> seb128: but CD?
[20:51] <desrt> hah.  "CD"
[20:51] <robert_ancell> yeah, it's not the mainness, just the image size and any related dependencies
[20:51] <seb128> desrt, adding a small library to the iso is not an issue, we have libwayland there for example
[20:51] <desrt> cool -- didn't know if it was properly split out
[20:52] <seb128> robert_ancell, how much dependency/space are we talking about?
[20:52] <seb128> can't be more than a few hundred kbs
[20:52] <robert_ancell> Installed-Size: 629
[20:52] <seb128> right
[20:52] <seb128> that's fine
[20:52] <desrt> but any depends on gtest/gflag/boost/etc?
[20:52] <desrt> you're going to be taking at least boost asio... dunno if this is already in the image for something else
[20:52] <robert_ancell> + Installed-Size: 162 for libmirclientplatform-mesa
[20:52] <robert_ancell> do we already have boost on the images?
[20:53] <robert_ancell> libboost-system1.55.0 is Installed-Size: 83
[20:53] <robert_ancell> so, that's approx 874 total I think?
[20:54] <robert_ancell> oh, plus 393 for libmirprotobuf0
[20:54] <desrt> and protobuf itself...
[20:54] <robert_ancell> and 1083 if we don't have libprotobuf8 already
[20:54] <robert_ancell> We might?
[20:54] <seb128> you guys are doing it wrong
[20:54] <desrt> surprised not to see asio on this list...
[20:54]  * seb128 boots iso and run apt
[20:55] <desrt> seb128 is so damn high tech :p
[20:55] <robert_ancell> desrt, asio is all templates I think
[20:55] <desrt> with his VMs and ISOs
[20:55] <robert_ancell> woo
[20:55] <robert_ancell> What is installed size units again? k?
[20:56] <jdstrand> seb128: you probably saw the profile and the changelog, but just to be clear, this isn't about confining system-settings. this is about having it run with an apparmor label so that ofono is able to allow it access on DBus (phonedations wanted to restrict access to ofono's DBus interface to only a few services, excluding unconfined)
[20:56] <jdstrand> this should effectively be no change for system-settings
[20:56] <seb128> jdstrand, ok, that makes sense to me, thanks for explaining it ;-)
[20:57] <seb128> robert_ancell, yes
[20:58] <seb128> robert_ancell, desrt: that install the 3 libs previously listed and that counts for 243kb of deb and 1Mb installed
[20:59] <robert_ancell> do we have image budgets anymore?
[20:59] <seb128> no
[20:59] <robert_ancell> so that's probably acceptable thewn
[20:59] <seb128> we try to be reasonable though
[20:59] <seb128> yeah, without doubt
[20:59] <desrt> larsu: dunno if you followed, but removing "schema" property didn't go over too well....
[20:59] <seb128> there are other stuff we would axe before that
[21:00] <seb128> robert_ancell, ok, so i'm going to land the scrollbar change tomorrow ... then what, is the GTK patch good to go, or do you need more work?
[21:00] <desrt> seb128: almost all of the 'more work' required is blocked on mir changes
[21:00] <robert_ancell> that's it - we can just keep updating the GTK+ patch as needed
[21:00] <seb128> right
[21:00] <seb128> desrt, that shouldn't block us to land "what we have"
[21:00] <desrt> nope.  certainly not.
[21:00] <seb128> robert_ancell, https://bugs.launchpad.net/ubuntu/+source/unity8-desktop-session/+bug/1300925 btw
[21:01] <seb128> robert_ancell, that has that mention "   * Show desktop applications when CLICK_SCOPE_SHOW_DESKTOP_APPS is set"
[21:01] <seb128> robert_ancell, we might just want to export that in the unity8-desktop script
[21:01] <seb128> I didn't test it yet
[21:01] <robert_ancell> the main issue blocking for it to be usable is bug 1333029
[21:01] <seb128> robert_ancell, see what I just wrote ;-)
[21:02] <robert_ancell> ag
[21:02] <robert_ancell> ah
[21:02] <seb128> if I understand correctly that changelog, exporting that env should make unity8 not require the desktop key
[21:02] <seb128> need testing though
[21:02] <robert_ancell> that's a dupe right?
[21:02] <seb128> yes
[21:03] <seb128> though Saviq/mhr3 were unsure if we still need that filter or if it's the right way
[21:03] <seb128> the intend is to not list a ton of entries that don't work
[21:03] <robert_ancell> sure
[21:03] <seb128> we are still going to have the issue that if we don't filter we show e.g libreoffice
[21:03] <seb128> or java stuff
[21:03] <seb128> or wxwidgets apps
[21:03] <seb128> or gtk2 ones
[21:04] <seb128> not sure how we can best resolve that
[21:04] <robert_ancell> it's a bit tricky, because you really don't know unless you whitelist and that's not practical
[21:04] <seb128> the desktop key might be the best way
[21:04] <robert_ancell> we need to ld_preload something and detect if your accessing a blacklisted library and stop and show a dialog in that case
[21:04] <seb128> it means somebody has to review that the app works under Mir
[21:04] <seb128> well
[21:04] <seb128> or we need to get XMir
[21:05] <robert_ancell> I should talk to RAOF and see if I can help out there. That would open up more options for us
[21:06] <seb128> right
[21:06] <seb128> if we get XMir we solve the issue
[21:06] <seb128> if we don't, I would say the best solution might to flag things that are "known to be working"
[21:06] <seb128> either by patching those, or building a whitelist
[21:06] <seb128> either way would work but is work
[21:06] <seb128> the whitelist might be less work than carrying delta on debian packages
[21:07] <robert_ancell> seb128, right, I was thinking of patches for each package but just a big-ol-whitelist in unity of .desktop file names would work fine
[21:08] <seb128> +1 for the whitelist
[21:08] <seb128> or export the variable and deal with the fact that stuff in the list are going to not run
[21:08] <robert_ancell> anyone working on that? Shall we have a go?
[21:08] <seb128> until we get XMir
[21:08] <robert_ancell> I think that would be worse
[21:08] <seb128> right
[21:08] <seb128> can you get info on how likely XMir is for trusty?
[21:08] <seb128> ups
[21:08] <seb128> utopic
[21:08] <robert_ancell> Yeah, I'll ask
[21:08] <seb128> thanks
[21:09] <seb128> if it's not, so let's do the whitelist thing
[21:09] <robert_ancell> Anything else higher priority?
[21:10] <seb128> not that I know
[21:10] <robert_ancell> seb128, oh, what happened with that branch you wanted me to review
[21:11]  * robert_ancell tries to remember what it was...
[21:11] <seb128> when was that?
[21:11] <robert_ancell> last week sometime
[21:11] <seb128> oh, making u-s-d include the old libgnome-desktop code?
[21:11] <robert_ancell> You take a few days off and you loose track of everything :)
[21:11] <robert_ancell> yes, that one
[21:11] <seb128> that didn't happen
[21:12] <robert_ancell> You want me to look at that one?
[21:12] <seb128> I looked at it, but u-s-d uses gnome-desktop for other things in other plugins
[21:12] <seb128> it's not easy
[21:12] <seb128> if you want, sure
[21:12] <robert_ancell> are those other things changing too?
[21:12] <seb128> but I think we should just ship libgnome-desktop3.8 as a separate source and build u-s-d with it
[21:12] <seb128> no
[21:12] <seb128> but it makes a lot of code to copy
[21:13] <robert_ancell> I thought there was some reason we couldn't copy the lib, but it is just basically helper functions right?
[21:13] <seb128> we can't use the system lib and a local one, or we need to rename symbols
[21:13] <robert_ancell> was there a bug?
[21:13] <seb128> it's quite some code/functions
[21:13] <seb128> not sure, I don't think so
[21:13] <seb128> the reason for not copying the lib was "let's try to avoid having another lib copy in the archive", but that's not a blockerr
[21:14] <robert_ancell> I'll have a look.
[21:15] <seb128> robert_ancell, thanks, let me know your conclusion after looking at it, mine was that the copy of the old lib is the easiest way
[21:15] <seb128> on that note calling it a day
[21:15] <seb128> good night (or day for those on the other side of the world) everyone ;-)
[21:15] <robert_ancell> btw, this is my list of things blocking gtk-mir https://bugs.launchpad.net/bugs/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporte
[21:15] <robert_ancell> r=&field.bug_commenter=&field.subscriber=&field.tag=gtk-mir&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_bluep
[21:15] <robert_ancell> rints=on
[21:16] <robert_ancell> night
[21:16] <robert_ancell> desrt, were you happy with the a-s solution I put into utopic for large UIDs?
[21:17] <seb128> robert_ancell, https://bugs.launchpad.net/bugs/+bugs?field.tag=gtk-mir
[21:17] <seb128> nicer url
[21:17] <robert_ancell> hah, I was just trying to find a nicer url
[21:18] <seb128> ;-)
[21:18] <seb128> ok, on that note, bye