[03:33] <pitti> Good morning
[04:30] <larsu> morning!
[04:48] <larsu> pitti: hi! seen this already? https://tecnocode.co.uk/2015/06/01/checking-d-bus-api-stability/
[04:48] <pitti> hey larsu!
[04:48] <pitti> larsu: fun, mbiebl just pointed it to me one minute ago
[04:48] <pitti> no, I didn't see it yet
[04:48] <pitti> looks great!
[04:49] <larsu> ha cool. pwhithnall just released it yesterday :)
[06:54] <seb128> good morning desktopers
[06:57] <seb128> Mirv, hey, easy question for you, why do we rebuild gsettings-qt on minor .1 qt updates (eg https://launchpad.net/ubuntu/+source/gsettings-qt/0.1+14.10.20140807-0ubuntu4)
[06:59] <larsu> seb128: morning (and thanks ;) )
[06:59] <seb128> larsu, hey (yw ;-)
[07:27] <willcooke> Guten Morgen!
[07:28] <larsu> morning willcooke
[07:28] <willcooke> How goes larsu?
[07:28] <larsu> willcooke: tired. Got up at 6:30
[07:28] <larsu> you?
[07:29] <willcooke> :/
[07:29] <willcooke> I've got a cold *again*
[07:29] <larsu> ugh sorry man. Get better!
[07:31] <seb128> hey willcooke
[07:31] <larsu> woah new meeting routine
[07:32] <seb128> new routine?
[07:33] <larsu> seb128: send emails with the updates befpre
[07:33] <seb128> read again? :p
[07:33]  * seb128 hands larsu some tea
[07:33] <seb128> oh
[07:33] <larsu> seb128: hm? Typo? It
[07:33] <seb128> willcooke, you meant "can't" there right?
[07:33] <larsu> says "if you CAN make it, send updates"
[07:33] <seb128> larsu, that sentence doesn't make sense
[07:33]  * larsu drinks tea that he actually just made before seb128 mentioned it
[07:34] <seb128> hehe
[07:34] <larsu> it's very good, thanks
[07:34] <seb128> yw! :-)
[07:34] <seb128> I'm so used to do that sort of typo that my brain autocorrect them on reading, I didn't even notice it was wrong/different from other weeks :p
[07:35] <larsu> seb128: it's very important that you read willcooke's emails thoroughly
[07:35] <larsu> especially the meeting ones. He's testing us.
[07:38] <seb128> yeah, I almost falled for it, thanks for watching Lars ;-)
[07:40] <larsu> :)
[07:44] <willcooke> doh
[07:45] <willcooke> Good job you guys are pros
[07:45] <willcooke> ;)
[07:45] <larsu> willcooke: but it was actually a typo?
[07:45] <willcooke> yes
[07:46]  * larsu feels better now
[07:49] <seb128> larsu, oh, so you didn't trust me? :p
[07:52] <larsu> seb128: of course not! :P
[07:53] <seb128> lol
[07:58] <willcooke> wheee - 50 MPH wind later on today
[08:03] <Laney> yo
[08:03] <seb128> hey Laney, wie gehts?
[08:04] <willcooke> yo yo yo
[08:04] <seb128> hey didrocks who is on London time, how is the office today?
[08:04] <didrocks> seb128: less sunny than yesterday
[08:04] <didrocks> back to classical London weather
[08:04] <didrocks> otherwise, good!
[08:04] <seb128> good :-)
[08:04] <Laney> yeah doing okay
[08:05] <Laney> i had the fire on last night though
[08:05] <Laney> on the first day of summer
[08:05] <Laney> crapseason
[08:05] <willcooke> :/
[08:05] <larsu> morning Laney, bonjour didrocks!
[08:06] <Laney> chimney definitely needs to be swept
[08:06]  * Laney smells of smoke
[08:06] <willcooke> Cure some meats first :)
[08:06] <seb128> Laney, it's not summer yet ;-)
[08:06] <seb128> but yeah, it's cold here as well
[08:06] <Laney> yesterday was the first day of summer, i heard it on the news!
[08:07] <seb128> lie!
[08:07] <Laney> it was the local news though
[08:07] <Laney> the work experience kid probably read the internet wrong
[08:07] <didrocks> hey larsu!
[08:07] <Laney> didrocks: what colour did you have your shower this morning?
[08:07] <didrocks> aubergine
[08:07] <didrocks> (no kidding)
[08:08] <larsu> good choice
[08:08] <Laney> you company man
[08:08]  * didrocks feels very corporate
[08:08] <larsu> Laney: he's on a work trip
[08:08] <larsu> it's the only option that makes sense, really
[08:08] <ochosi> any reason wily can't be selected on packages.ubuntu.com yet?
[08:08] <Laney> adroitly observed
[08:08] <didrocks> ahah
[08:09] <Laney> ochosi: go ask rhonda @ #ubuntu-motu
[08:09] <ochosi> Laney: thanks, will do
[08:09] <larsu> lol
[08:10] <Laney> ochosi: btw, eta 8th june ;-)
[08:10] <seb128> Laney, didrocks, k, so Colin merged the cdimage changes and it seems the system is trying to build a snappy image now, https://launchpadlibrarian.net/208044896/buildlog_ubuntu_wily_i386_ubuntu-desktop-next_BUILDING.txt.gz
[08:10] <seb128> it hits " system-image-snappy-cli : Conflicts: system-image-cli but 3.0-0ubuntu2 is to be installed" though
[08:11] <seb128> so I guess some of the phone stuff tries to bring the system-image-cli and create issue
[08:11] <ochosi> Laney: mine is still in the state "order received" with the same ETA :'( already tried to contact dell, but it seems they have shut down all their phone lines etc, meh
[08:11] <seb128> it could be the settings
[08:12] <Mirv> seb128: hey. because of bug #1426335
[08:12] <Laney> seb128: do they provide the same interface?
[08:12] <seb128> Laney, I don't know, need to check
[08:12] <didrocks> seb128: yeah, that's possible
[08:12] <seb128> in fact ubuntu-touch-core depends on system-image-cli
[08:12] <seb128> I guess -desktop includes -core?
[08:12] <Laney> that's the common stuff
[08:12] <didrocks> IIRC, yeah
[08:13] <seb128> I wonder if we need a snappy-core
[08:13] <seb128> Mirv, thanks
[08:13] <seb128> larsu, ^ see bug from Mirv
[08:18] <larsu> seb128: uh!
[08:18] <larsu> how am I not getting bugmail on that project...
[08:18] <Laney> seb128: if they provide the same interface then you could make it Provide and then seed it from desktop or something
[08:18] <larsu> seb128: thanks!
[08:18] <Laney> otherwise we need to fix uss or whatever it is to work with both I guess
[08:18] <Laney> and then move it out from core to touch and desktop
[08:18] <seb128> Laney, right, I'm going to look at that, but the issue is not coming from settings there
[08:19] <seb128> touch-core depends on system-image-cli
[08:19] <ochosi> Sweet5hark1: since the PPA doesn't seem ready yet i tried LO 5.0 from the LO website, but the icon themes are hardcoded there, so i can't really test anything with it...
[08:19] <seb128> larsu, yw!
[08:19] <ochosi> Sweet5hark1: just to be sure, 5.0beta1 will pop up in the "fresh" PPA?
[08:21] <Laney> seb128: try something like http://paste.ubuntu.com/11515737/
[08:22] <seb128> Laney, oh, good idea ... want to commit it since you did the change? ;-)
[08:24] <Laney> sneaky
[08:24] <Laney> but ok, this one time!
[08:24] <seb128> thanks :-)
[08:25] <Laney> oh wait, there's some weird thing around not being able to upload the package isn't there
[08:25] <seb128> I'm looking at the interface things for settings
[08:25] <seb128> you mean?
[08:25] <Laney> didrocks had problems with it the other day
[08:25] <seb128> was it on friday when infra went down?
[08:25] <Laney> no
[08:26] <Laney> something to do with the overlay ppa
[08:26] <Laney> ogra_: can I just upload touch-meta to wily as normal?
[08:31] <didrocks> Laney: the seed is fixed now, it wasn't due to the overlay ppa, but missing package in the seed
[08:31] <didrocks> so you should be able to regenerate as usual and upload
[08:31] <Laney> ok
[08:34] <ogra_> Laney, sure, just verify the generated changelog twice
[08:34] <ogra_> (as usual i guess ;) )
[08:34] <Laney> measure twice, cut once
[08:39] <Sweet5hark> ochosi: no, beta and rcs for the first release of a new major series appear in libreoffice-prereleases ppa. its not there yet.
[09:01] <ochosi> Sweet5hark: oh ok, good to know! will there be any sort of announcement or call for testing when it lands?
[09:02] <Sweet5hark> ochosi: usually I do twiiter/g+ posts, but not blog posts.
[09:05] <ochosi> Sweet5hark: okeydoke, will look out for those! thanks!
[09:15] <Sweet5hark> hmmm, its not even noon yet and on #libreoffice-dev "plastic rooster porn" is being discussed.
[09:29] <larsu> Sweet5hark: it's noon somewhere...
[09:31] <willcooke> :)
[10:04] <Laney> is there any point to a M-A: Same -dbg package?
[10:04] <Laney> s/S/s/
[10:08] <pitti> Laney: wouldn't they file-collide left and right?
[10:09] <pitti> unless the source builds multiple -dbg packages of course, in particualr separate ones for librarires
[10:09] <pitti> but in that case, it seems easier to just drop the -dbg in ubuntu and use our ddebs :)
[10:09] <Laney> not if it's /usr/lib/debug/usr/lib/triplet/...
[10:10] <Laney> but in this case we have /usr/lib/debug/usr/bin/stuff already too
[10:12] <Laney> (so the :same doesn't work, so I'll drop it)
[10:12] <Laney> was wondering about this piece of delta on gtk+3.0
[10:25] <Laney> NOOOOOOOOOOOOOOoooooooooooooo
[10:25]  * pitti hugs Laney, what happened?
[10:27] <Laney> in the last few days there's been a mir upload which broke the build of the gtk mir backend
[10:29]  * larsu hugs Laney and offers to help
[10:29] <Laney> although
[10:29] <Laney> it should have been broken by this one on the 12th https://launchpad.net/ubuntu/+source/mir/0.13.0+15.10.20150512-0ubuntu1
[10:29] <Laney> but I never got that?!
[10:30] <Laney> larsu: I wonder if trunk is fixed
[10:30] <Laney> was hoping we'd get at least one upload without an update-mir-from-git patch :|
[10:30] <larsu> Mirv: I've tracked down the issue, it's from a header in qt. Are you sure this is a private symbol? I read somewhere that QObjectPrivate may be used from subclasses
[10:31] <larsu> Laney: bah...
[10:31] <Laney> attente: do you know if gtk-mir is fixed upstream to build with current mir?
[10:31] <larsu> is that patch we're using from upstream?
[10:32] <larsu> a couple of weeks ago we had additional changes on there
[10:32] <Mirv> larsu: our marking of private symbols should be working correctly. you should be able to manually call dh-shlibdeps -- -v -v -v to see how that symbol brings the qtbase-abi dependency
[10:32] <Mirv> and the qtbase-abi comes from using symbols in qtbase5-private-dev
[10:33] <Laney> no patch atm, 3.16.3's version was working
[10:33] <larsu> "was"
[10:33] <Laney> until may 29th
[10:34] <Laney> I'm going to add this test this week so they can't break it again
[10:34] <larsu> Mirv: how do we mark private symbols? (Asking to include some useful information in an upstream bug report)
[10:34] <larsu> Laney: I'm starting to regret that we have this in upstream gtk
[10:35] <Laney> looks like https://git.gnome.org/browse/gtk+/commit/gdk/mir?id=ea190a339a9e61a52db9d307568f12e0a234f52b
[10:35] <Laney> thanks attente!
[10:35] <Mirv> larsu: pkgkde-mark-private-symbols debian/qtbase5-private-dev/usr/include , http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/pkg-kde-tools/wily/view/head:/pkgkde-mark-private-symbols
[10:35] <larsu> it doesn't benefit anyone, since not everyone is using unstable ubuntu
[10:36] <Laney> is the api expected to stabilise any time soon?
[10:36] <larsu> hahahahahhahaaaaaah
[10:36] <larsu> hahahahahah
[10:36] <larsu> haha
[10:36]  * Laney weeps
[10:36] <larsu> funny.
[10:37] <Laney> well, then creating some consequences is interesting to me
[10:37] <larsu> Mirv: that's out definition of private, right? If upstream uses something in a header file, surely that's not their bug?!
[10:37] <larsu> s/out/our
[10:37] <attente> Laney: are you doing a release?
[10:38] <Laney> ya, soon
[10:38] <Laney> can we put build/api fixes like that into the stable gtk branches?
[10:39] <Mirv> larsu: yes, upstream can use private headers within itself, but the private symbol usage shoudn't be brought to our code. sorry, I don't actually understand what gsettings-qt is doing to use that symbol, so I'm just talking generally.
[10:39] <attente> Laney: there's a branch wip/mir-unstable which fixes some things
[10:41] <attente> i might just merge that in now
[10:41] <Mirv> larsu: so it's something like you're using public headers only but somehow using those bring a private symbol usage anyway?
[10:41] <Mirv> larsu: it seemed strange to me, but it's only gsettings-qt that's affected
[10:44] <Laney> attente: ok, do you want to make a new debian/patches/mir-backend patch on top of our bzr branch?
[10:44]  * Laney pushes that
[10:45] <larsu> Mirv: yes. Removing the call to the QQmlPropertyMap constructor in gsettings-qml.cpp makes it not link against that symbol
[10:45] <attente> Laney: are you basing it off master? i'm just going to make sure it works on top of it and merge it in
[10:45] <larsu> Mirv: (but it also breaks functionality)
[10:45] <Laney> attente: 3.16.3
[10:46] <Laney> might go to 3.17 if it eases mir backend pain though, but not straight away
[10:46] <Laney> so we need a patch on 3.16 for now
[10:46] <larsu> Mirv: qqmlpropertymap.h dereferences a QObjectPrivate - and has for quite a while
[10:46] <larsu> the thing is that nobody is using that class really
[10:46] <Laney> i'm guessing it will apply mostly cleanly
[10:46] <attente> ok, can you take those patches then? i don't think gtk-mir is in a good state without it
[10:46] <didrocks> Mirv: feel free to close bug #1461034 once everything if uploaded (if any), it's more for tracking
[10:47] <Laney> attente: probably easiest if you provide an MP or a .patch
[10:47] <Laney> I'm worried I will miss something
[10:47] <Laney> good idea to merge your wip branch into master too I think
[10:48] <larsu> hi attente :)
[10:48] <attente> Laney: sure
[10:48] <Mirv> didrocks: thanks. I started yesterday but didn't commit yet since it was a bit more complicated and I need kalikiana to confirm some bits of what he needs for building UITK's own html documentation. but I can push the seed changes anyhow even if not cleaning everything from UITK itsef.
[10:48] <attente> larsu: hi larsu :)
[10:49] <Laney> thanks!
[10:49] <Laney> lp:~ubuntu-desktop/gtk+3.0/ubuntugtk3 is what I was hoping to upload
[10:51] <larsu> Mirv: do you want to look into this again? Not sure an upstream bug is warrented just yet
[10:54] <Mirv> larsu: well, I filed the bug because I couldn't fix it myself :( I thought you might have an educated guess what should be changed in the QML plugin to avoid the symbol.
[10:54] <larsu> Mirv: I cannot avoid the symbol. I'm using qt's API as documented
[10:55] <larsu> Mirv: and I don't think it's private API (as defined by upstream)
[10:56] <Mirv> larsu: right, it's not also in the sense that you're not build depending on qtbase5-private-dev. it might be their bug that using a public API brings that private symbol into play, but I can't say for sure.
[10:58] <larsu> Mirv: QObjectPrivate is in a _p.h, but it is marked as Q_CORE_EXPORT and includes a macro named Q_DECLARE_PUBLIC
[10:59] <Mirv> larsu: oh.. then it might be a bug in marking the symbols. mitya57 did we have a case like Q_DECLARE_PUBLIC before with the symbols?
[10:59] <mitya57> No, I think the script doesn't handle it
[10:59] <mitya57> Maybe we should fix it
[10:59] <larsu> not sure what exactly those mean, but declare_public sounds ... obvious :)
[10:59] <Mirv> larsu: well then it's Invalid for gsettings-qt
[10:59]  * mitya57 looks
[10:59] <Mirv> larsu: and a bug for qtbase
[11:00]  * larsu closes tab with upstream bug
[11:00] <larsu> Mirv, mitya57: cool. reassigning. Thanks
[11:02] <Mirv> larsu: thanks for looking into it!
[11:02] <larsu> Mirv: no worries. sorry for taking so long. I wasn't subscribed to gsettings-qt bugs for some reason
[11:03] <larsu> (am now, of course)
[11:03] <mitya57> Mirv, larsu: Q_DECLARE_PUBLIC is not for declaring classes public
[11:03] <mitya57> #define Q_DECLARE_PUBLIC(Class)                                    \
[11:03] <mitya57>     inline Class* q_func() { return static_cast<Class *>(q_ptr); } \
[11:03] <mitya57>     inline const Class* q_func() const { return static_cast<const Class *>(q_ptr); } \
[11:03] <mitya57>     friend class Class;
[11:03] <mitya57> It is for defining some internal stuff in the class
[11:03] <mitya57> (To be used later using Q_Q macro)
[11:04] <Mirv> hmm, that explains why it's in _p.h after all
[11:04] <Sweet5hark> willcooke: see? all the hard work you missed in Cambridge: https://libreoffice-from-collabora.com/libreoffice-uk-hackfest-after-action-report/
[11:04]  * willcooke reads
[11:04] <mitya57> So if it's in _p.h, then it's private
[11:05] <Mirv> mitya57: well that's at least easier that there are no such corner cases upstream. the problem larsu is facing is that he's only using public API (qtbase5-dev) but ends up with that symbol.
[11:05]  * mitya57 reads the backlog
[11:05] <larsu> mitya57: is that macro documented anywhere?
[11:06] <mitya57> larsu: It's only for internal use within Qt
[11:06] <larsu> mitya57: in short: gsettings-qt is using QQmlPropertyMap() protected constructor (as documented) and that pulls in this symbol
[11:06] <larsu> mitya57: well yeah, but I'd like to know what it's supposed to do
[11:06] <mitya57> I think it's documented in https://wiki.qt.io/D-Pointer
[11:06] <mitya57> Let me look at what can pull private symbols in your case
[11:07] <mitya57> larsu: do you have qtbase >= 5.4.0+dfsg-6?
[11:08] <mitya57> Nevermind, it's quite old and already in vivid
[11:08] <larsu> I'm on updated-this-morning W
[11:14] <mitya57> larsu: Hm, I believe we can't do anything about this
[11:15] <larsu> mitya57: how do you mean?
[11:15] <mitya57> As that constructor is really using a private QObject constructor, and is effectively inline as it's a template
[11:15] <Mirv> this is the current shlibdeps output http://paste.ubuntu.com/11518643/
[11:16] <mitya57>     template<class DerivedType>
[11:16] <mitya57>     QQmlPropertyMap(DerivedType *derived, QObject *parentObj)
[11:16] <mitya57>         : QObject(*allocatePrivate(), parentObj)
[11:17] <mitya57> I think it was not intended for public use (and was only for use by Qt's own QQmlPropertyMap subclasses)
[11:17] <larsu> no, it's definitely intended for public use
[11:17] <larsu> we've fixed a couple of bugs with it already
[11:19] <larsu> why are these "private" symbols exported in the first place? Because other qt libraries need them?
[11:19] <mitya57> Currently pkgkde-mark-private-symbols considers not only QSomePrivateClass methods as private, but also all other functions accepting an instance/pointer of a QSomePrivateClass
[11:19] <mitya57> Yes, other Qt modules need them
[11:19] <mitya57> And also bindings like PyQt
[11:22] <larsu> I fail to see how this is an upstream bug then, as they don't really consider those symbols private
[11:22] <mitya57> They do
[11:22] <larsu> if some projects are using them, they must keep stability
[11:22] <mitya57> ABI stability is guaranteed only for classes defined in public headers
[11:23] <mitya57> I am thinking if we should allow methods *taking* private class instance to be public
[11:23] <larsu> fair enough, it's a qt bug then
[11:23] <larsu> mitya57: will you file it upstream please?
[11:24] <mitya57> On Qt side this can be fixed by using a different constructor, but that will look like a workaround
[11:24] <mitya57> I will ask lisandro for his opinion and then file a bug
[11:24] <larsu> thanks
[11:24] <larsu> I will go out for a run. bbiab
[11:25] <Mirv> thanks mitya57 for looking into it too!
[11:25] <mitya57> YW!
[11:29] <mitya57> larsu: I have just noticed that that code dereferences a QObjectPrivate* pointer, so it actually passes an instance, not a pointer.
[11:29] <mitya57> And as sizeof(QObjectPrivate) will change in future, then that constructor definitely is not ABI stable
[11:32] <mitya57> So we can't really do anything about it, and it's an upstream (minor, not-easily-fixable) bug
[11:55] <seb128> Laney, what test do you want to add? making sure that mir update don't stop gtk from building? is that really something we should block uploads on? we don't block gcc uploads on any ftbfs they create in the archive
[11:56] <Laney> doko does test rebuilds and we try to fix as many as possible before uploading
[11:58] <Laney> I don't think randomly finding out that the api has broken when we come to want to upload gtk is a good situation
[11:59] <seb128> we can assume that any mir update is going to require updating the gtk backend
[12:00] <seb128> so maybe just enforce that through packaging rules
[12:00] <Laney> how?
[12:02] <seb128> Depends >> libmir_current, << libmir_nex
[12:02] <seb128> nex
[12:02] <seb128> next
[12:02] <seb128> grrr
[12:02] <Laney> ...
[12:03] <Laney> you mean you want to force a rebuild of gtk every time?
[12:03] <Laney> I don't see how it helps - if it's broken then it needs fixing at this point anyway and if it's not then you rebuild for no reason
[12:03] <seb128> yes
[12:03] <seb128> oh well
[12:04] <seb128> go for a build test if you want
[12:04] <seb128> it feels boggus to me to "block" on such changes
[12:04] <Laney> maybe a daily build recipe if those work still
[12:04] <seb128> we should flag the issue
[12:04] <seb128> unsure we should block
[12:04] <seb128> buildtime is not running, it doesn't impact users
[12:06] <Laney> could also put it in their CI
[12:07] <Laney> but then where to target fixes
[12:08] <seb128> hey, unsure, they could build from our packaging trunk
[12:08] <seb128> but we could have unrelated changes stacked there
[12:08] <seb128> so it's suboptimal
[12:09] <Laney> ya
[12:09] <larsu> mitya57: they could pass a reference, no? Or move the constructor into the .cpp
[12:14] <Laney> kgunn: got a sec to chat mir landings?
[12:14] <Laney> kgunn: Wondering if I can add a step to the pre-upload checklist for a gtk rebuild so that we always keep it building in the archive
[12:15] <seb128> Laney, kgunn, do we ensure that the qt qpa still builds before mir uploads?
[12:15] <kgunn> Laney: sound like a good idea, something we could automate
[12:15] <seb128> if not we should do that as well
[12:16] <Laney> would be good, especially if automated
[12:16] <kgunn> seb128: you mean qtubuntu yes
[12:16] <Laney> kgunn: got a URL?
[12:16] <kgunn> Laney: to?
[12:16] <seb128> kgunn, k, good, so just need to do the same for gtk ;-)
[12:16] <Laney> $checklist
[12:16]  * Laney will edit it
[12:16] <kgunn> Laney: https://wiki.ubuntu.com/Process/Merges/TestPlans/Mir
[12:17] <kgunn> camako: ^ we need to inform vogons
[12:17] <Laney> got it
[12:17] <larsu> mitya57: anyway. got a bug?
[12:17] <kgunn> camako: and put a card on backlog to automate
[12:17] <kgunn> Laney: thanks
[12:17] <Laney> thanks for agreeing!
[12:18] <larsu> Laney: nice!
[12:18] <Laney> done
[12:53] <mitya57> larsu, Mirv: https://bugreports.qt.io/browse/QTBUG-46433 (sorry for the delay)
[12:53] <larsu> mitya57: thanks :)
[12:54] <xclaesse> seb128, any progress on fixing GtkFileChooser for sorting folders first?
[12:55] <xclaesse> seb128, upstream has commit 2aa3eea781ed21a02ecdf1e3c753a1ec5694d6c8
[12:56] <seb128> xclaesse, I forgot about that, do you know if there is a bug open about it on launchpad?
[12:56] <xclaesse> but it's not in 3.14 that ubuntu has
[12:56] <xclaesse> seb128, don't know, but will open it now if I can't find one ;)
[12:56] <seb128> xclaesse, yeah, as said we are not going to add an UI to the stable version, rather just change the default there
[12:56] <seb128> Laney, ^ can you do that if you do a gtk upload?
[12:57]  * xclaesse is always lost in lp for search/report bugs 
[12:58] <seb128> xclaesse, https://launchpad.net/ubuntu/+source/gtk+3.0/+bugs?orderby=-id&start=0 doesn't seem to have one
[12:58] <seb128> just click on "report a bug" on the right
[12:59] <Laney> I don't remember this
[12:59] <Laney> we disagree with upstream?
[12:59] <seb128> dunno what upstream thinks
[12:59] <Laney> you want to change the default
[12:59] <seb128> they add an UI back to change the preference
[12:59] <seb128> in 3.16
[13:00] <seb128> yes, xclaesse asked if we could make the old behaviour still the default
[13:00] <seb128> or backport the UI
[13:00] <seb128> the UI would mean new string
[13:00] <xclaesse> reported https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1461085
[13:00] <seb128> Laney, it's just restoring things the way they were, I think it makes sense for at least 3.14 which doesn't have an UI for users who want the old way
[13:00] <seb128> for 3.16 we can argue
[13:01] <seb128> since it has the UI users can tweak it to their liking
[13:01] <Laney> I don't really care, *but* it is changing the behaviour in a stable release
[13:02] <seb128> right, back to a sane one :-)
[13:02]  * xclaesse consider it fixing a regression
[13:03] <seb128> also to a consistent one with nautilus/gtk2/qt
[13:03] <xclaesse> as seb128 said, if we had an setting then I wouldn't care much about the default tbh
[13:03] <seb128> well, I still think the default should be consistent between toolkits, or at least between gtk versions
[13:03] <Laney> that means they have to maintain gtk2?
[13:03] <seb128> yes
[13:04] <seb128> or that we have to be conservative with our changes
[13:04] <xclaesse> it's also inconsistent with nautilus. IMO if we want to change the default, it should be changed in both.
[13:04] <seb128> +1
[13:04] <seb128> I think that change was just not properly thought through
[13:04] <seb128> so we should revert the behaviour to the old one
[13:04] <seb128> it's only a settings so it's easy
[13:08] <seb128> Laney, in fact that seems like more an ubuntu-settings tweak, let me do that change
[13:09] <Laney> ok, as you wish
[13:10] <alan_g> kgunn: I think that past mistakes are being fixed both in Mir and in the process. I'd prefer we only fix them in Mir.
[13:16] <seb128> xclaesse, uploaded to wily and SRUed to vivid
[13:17] <xclaesse> \o/
[13:17] <xclaesse> seb128, thanks !
[13:17] <seb128> yw!
[13:21] <kgunn> alan_g: if you mean "let's not add another manual step, but an automated test" agreed....
[13:22] <alan_g> kgunn: I mean like we accidentally had clients-side users linking to libmircommon and that meant we didn't realise that a libmircommon ABI bump would break them
[13:23] <alan_g> Which is why we had to pull qtubuntu into the release process
[13:24] <alan_g> We should have checks /in Mir/ that this can't happen, not have steps in the release process
[13:27] <mitya57> larsu: upstream pointed me that I'm wrong
[13:27] <alan_g> I don't think it scales to require a rebuild of qtmir, platform-api, libubuntu-application-api, sdl, xserver, gtk, egl1-mesa, etc. for a Mir release that maintains ABI.
[13:35] <alan_g> kgunn: we're breaking the client ABI with the 0.14 series so we'll have to pay the price for that release. But many of the changes are intended to give better ABI and API stability. And just when we deliver that the intention appears to be to gate the release on rebuilding all the rdepends anyway.
[13:41] <attente> hi, i just did a dist-upgrade, but my machine is no longer passing the boot stage
[13:41] <attente> wondering if anyone else has this problem? this is my boot.log: http://paste.ubuntu.com/11521041/
[13:42] <kgunn> alan_g: ah, i get you now @abi, but i do think we should have a sanity integration test for gtk-mir somewhere in the release process
[13:42] <kgunn> i was kinda thinking this during the sprint anyhoo
[13:45] <alan_g> kgunn: I'm not sure of the names, but I thought packages could specify some smoke tests to run when dependencies update. But that these would typically be running the archive binaries, not rebuilding from source.
[13:46] <alan_g> so gtk-mir-smoke-test would gate its upstreams including Mir
[13:47] <Laney> alan_g: I proposed that, we can definitely do it but it's quite late in the process
[13:47] <Laney> unless you want to run these also as part of mir's CI or something
[13:48] <alan_g> Laney: I'd suggest Mir's autolanding definitely. CI would depend on their cost
[13:49] <Laney> you mean proposed-migration?
[13:49] <alan_g> But I don't think we should be gate on FTBFS
[13:50] <alan_g> Laney: what's "proposed-migration"?
[13:50] <Laney> the tests that run after you upload a package
[13:50] <larsu> mitya57: that bug report doesn't describe the issue we're seeing though...
[13:51] <Laney> gating on build failures is exactly what I want, we shouldn't have gtk broken in the archive at any point
[13:51] <larsu> mitya57: the size of the struct doesn't need to be known, that's true. You were arguing that an application using qqmlpropertymap shouldn't link against a private constructor
[13:53] <alan_g> Laney: Mir changes autoland on an integration branch that is pulled into the releases. That's when I think we should first identify downstream incompatibilities. (Not stop the merge but flag some action is needed before release.)
[13:54] <Laney> Fair enough, if that's how you want to implement it - the end result is what I care about
[13:55] <alan_g> But that's not <Laney> "kgunn: Wondering if I can add a step to the pre-upload checklist for a gtk rebuild so that we always keep it building in the archive"
[13:56]  * Laney shrugs
[13:56] <Laney> That's what *I* can do
[13:56] <Laney> you can optimise the process if you want
[13:58]  * alan_g wants to "ensure the downstreams in archive works", not to "always rebuild all the downstream"
[14:00] <Laney> Fine. You don't have to hammer it home. If we never get a broken build then I'm happy.
[14:01]  * Laney is going for late lunch now
[14:03] <seb128> attente, try #ubuntu-devel for boot issues
[14:03] <seb128> not sure what's going with that log
[14:04] <attente> seb128: sure, thanks
[15:30] <willcooke> What time is it?
[15:30]  * qengho hides.
[15:30] <seb128> it's meeting time!
[15:30] <desrt> it's that time
[15:30] <willcooke> \o/
[15:30] <willcooke> #startmeeting Desktop Weekly Meeting - 2015-06-02
[15:30] <meetingology> Meeting started Tue Jun  2 15:30:48 2015 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] <willcooke> June already!?
[15:30] <didrocks> yep! :)
[15:31] <didrocks> crazyness
[15:31] <willcooke> Roll call:  attente, desrt,  dgadomski (out), didrocks (maybe out), fjkong, happyaron (out), laney, larsu, qengho, seb128, sweet5hark, tkamppeter, themuso (out), robert_ancell (out)
[15:31] <desrt> o/
[15:31] <willcooke> Ah, didrocks is not out
[15:31] <Sweet5hark> heya
[15:31] <didrocks> never *ever*
[15:31]  * FJKong online
[15:31] <larsu> \o
[15:31] <willcooke> Let's do this thing
[15:31] <willcooke> #topic attente
[15:32] <attente> hey, not much from me
[15:32] <attente> i proposed kernel patch to the apparmor mailing list, they asked for something more optimized and future-proof so i ended up re-writing it
[15:32] <attente> still need to make the corresponding changes on the apparmor client api before i can propose it again
[15:32] <attente> (eof)
[15:32] <willcooke> merci attente
[15:32] <willcooke> #topic desrt
[15:32] <desrt> also not a lot from me
[15:33] <desrt> met up with attente and synced up on the apparmor stuff a bit and progressed the work on my side
[15:33] <desrt> but there have been many distractions this week
[15:33] <desrt> eof
[15:33] <willcooke> Schönen dank desrt
[15:33] <willcooke> #topic didrocks
[15:33] <didrocks> * Rebased the desktop next image system image base on latest trunk version and wily. Uploaded those. Now, it's up to seb128 ;)
[15:33] <didrocks> * Finished reading advanced QML/Qt technics and found tutorials on QML debugging as well as where ubuntu designer is heading.
[15:33] <didrocks> * Ubuntu Make bug triaging + code review on arduino's support (will do finale work after the SDK sprint).
[15:33] <didrocks> * At SDK sprint, lot of discussions and filing feedback on the past week noticed roadblocks.
[15:33] <didrocks> eof
[15:33] <willcooke> xie xie didrocks
[15:34] <willcooke> #topic FJKong
[15:34] <FJKong> * bug#1454200 qimpanel window position wrong on high-dpi screen Edit
[15:34] <FJKong> under going
[15:34] <FJKong> after debuging, this position comes from fcitx, give a comment
[15:34] <FJKong> * right click on input window it will disappear
[15:34] <FJKong> continue debug on this
[15:34] <FJKong> * dash research on progress
[15:34] <FJKong>   fix some bugs and make it run faster
[15:34] <FJKong> eof
[15:34] <willcooke> tack FJKong
[15:34] <willcooke> #topic happyaron
[15:35] <willcooke> 1. Prepare to make fcitx default for Korean and Vietnamese languages
[15:35] <willcooke> 2. Follow up UKSC comments issues with NUDT
[15:35] <willcooke> 3. Various sponsorship for input method stuff at Debian
[15:35] <willcooke> #topic Laney
[15:35] <Laney> • Update: gtk-doc (+ debian) gobject-introspection (+ debian) yelp grilo-plugins tracker vte gnome-terminal adwaita-icon-theme
[15:35] <Laney> • Patch pilot
[15:35] <Laney> • Upstream de-headerbar patches for yelp & gnome-disk-utility
[15:35] <Laney> • Merge gtk 3.16.3 with Debian both ways, just built, about to upload
[15:35] <Laney> ∘ larsu updated the theme to fix worst issues, get this uploaded
[15:35] <Laney> ∘ Mir backend build broke, some chat about how we can avoid this in future
[15:35] <Laney> • Finish libmediaart transition
[15:35] <Laney> • Small testfix in dbusmock (ofono made an incompatible change)
[15:35] <Laney> • release: fix boottest to have fewer spurious failures (don't download huge things which fill up the phones)
[15:36] <Laney> • some fixes to g-t wrapper script (block in --disable-factory mode, some bugfixes)
[15:36] <Laney> ☀
[15:36] <willcooke> köszönöm Laney
[15:36] <willcooke> #topic larsu
[15:36] <larsu> hi!
[15:36] <larsu> too slow today...
[15:36] <larsu> - finished up the totem menu work (upstream bug is filed with a patch)
[15:36] <larsu> - started thinking about (and implementing) a way to do the dynamic parts of our menus more easily
[15:36] <larsu>   * apps have to jump through hoops right now to do this and it breaks things like totem wanting to inster the same menu section into the fullscreen menu and he menubar
[15:36] <larsu>  - updated the worst offenders in the theme
[15:36] <larsu> (thanks Laney for uploading)
[15:37] <Laney> that is good cross referencing
[15:37] <larsu> - looked into that gsettings-qt queued-signal issue again that popped up in brussels
[15:37] <larsu> (they needed it now and wanted to do The Bad Thing)
[15:37] <larsu> found out it's a qt bug
[15:37] <larsu> as suspected...
[15:38] <larsu> found a better workaround and did some back and forth on the review
[15:38] <larsu> - looked into gsettings-qt using private symbols
[15:38] <larsu> there's still some discussion if this symbol is actually private or if debian just thinks it is
[15:39] <larsu> - started looking into timezonemap using offline db on desktop (again), but got distracted by the qt issues
[15:39] <larsu> - preparing my sales thing next week \o/

[15:39] <willcooke> dankon larsu
[15:39] <willcooke> #topic qengho
[15:40] <qengho> - Chromium 43.0.2357.81 focus still weird. Still testing. I'm the only person who notices, so I might be crazy.
[15:40] <qengho> - Bridging users onto newer, official Flash plugin via install Help button to wiki.u.c. Ripped out previous idea of start-up time dialog.
[15:40] <qengho> - Trying to get Precise running. Backstory: New toolchain to support C++11. ABI breakage somehow. Just starting this. Reported by CCC.
[15:40] <qengho> - Chromium autopkgtest fails intermittently, as of two weeks ago. Appears to be infrastructure problem, downloading or copying files. Anyone else seen?
[15:40] <qengho> EOF
[15:40] <willcooke> ありがとう qengho
[15:40] <qengho> Nihongo?
[15:40] <willcooke> #topic seb128
[15:40] <seb128> • shotwell: included fix from mardy for online account/facebook issue, fixed autopkgtests for the new version
[15:40] <seb128> • cleared out a bit of the approved ubuntu-system-settings approved merges with a wily landing
[15:40] <seb128> • update eog to use traditional titlebar under Unity
[15:40] <seb128> • spent most of a day dealing with devices upgrade issues/buggy images
[15:40] <seb128> • tried to get snappy to work on an uefi laptop without luck :-/
[15:41] <seb128> • dialer-app: fixed some UI issues in the history view
[15:41] <seb128> • dialer-app: fixed bug where + symbol was inserted at the wrong position
[15:41] <seb128> • telephony-service: submitted fix for dialpad sound playing in silentmode
[15:41] <seb128> • looked at missing translations in the phone messaging/dialer applications, updated the templates on launchpad
[15:41] <seb128> • changed ubuntu-settings to enable "sort folder first" back by default in GTK

[15:41] <willcooke> grazie seb128
[15:41] <willcooke> #topic Sweet5hark
[15:41] <Sweet5hark> - LibreOffice 4.4.3/vivid SRU is uploaded, thanks seb128
[15:41] <Sweet5hark> - upstream regression swipe:
[15:41] <Sweet5hark> -- tdf#89515: couldnt reproduce
[15:41] <Sweet5hark> -- tdf#91145: fixed upstream on master, backported for 5.0~beta2
[15:41] <Sweet5hark> - preparing 5.0~beta1 right now: currently at the 'care and feeding of a 42KLOC ./configure script' stage
[15:41] <Sweet5hark> - found that Debian packages LibreOfficeKit headers as a package in 5.0, which helps for snappy stuff. Thanks _rene_!
[15:41] <Sweet5hark> => next weeks plans: LibreOfficeKit demo, refresh backups, cleanups/create new pbuilder jails etc.
[15:41] <Sweet5hark> EOF
[15:41] <willcooke> баярлалаа Sweet5hark
[15:42] <willcooke> #topic tkampetter
[15:42] <willcooke> No Till by the looks of things
[15:42] <willcooke> #topic TheMuso
[15:42] <willcooke> * Uploaded alsa-lib, alsa-plugins, and alsa-utils to wily.
[15:42] <willcooke> * More unity a11y text entry accessibility enablement work.
[15:42] <willcooke> * More upstream speech dispatcher work, code cleanup and bug fixing being the primary focus. Need to switch configuratino to using gsettings for better use and integration for Qt folks to use it as a text to speech backend.
[15:42] <willcooke> #topic robert_ancell
[15:43] <willcooke> - Got XMir compiling in wily (not working yet)
[15:43] <willcooke> - GNOME 3.16 package updates
[15:43] <willcooke> - Package update sponsoring
[15:43] <willcooke> - Worked on e-d-s 3.16 updates, made branch for indicate-datetime for
[15:43] <willcooke> when this migration occurs
[15:43] <willcooke> - Worked with jpds to get cryptsetup-tpm into a proper Launchpad project
[15:43] <willcooke> - Fixed documentation error in Mir
[15:43] <willcooke> #topic Any other business
[15:43] <qengho> Fastest meeting ever.
[15:43] <willcooke> larsu, good luck with the training course - let me know if you need anything
[15:44] <willcooke> Anyone got anything they would like to talk about?
[15:44] <qengho> I asked if anyone with large packages had noticed autopkgtest errors. Anyone?
[15:44] <qengho> I can't decide if it's new or just new to me.
[15:44] <larsu> willcooke: thanks. I spoke to maria earlier. Everything's good so far
[15:44] <qengho> Maybe Cr passed some invisible size barrier.
[15:44] <larsu> willcooke: ya: what will you do when we have more people in the team than languages in which you can say thanks?
[15:45] <seb128> qengho, unsure, maybe Sweet5hark can share some experience there :-)
[15:45] <willcooke> larsu, I'll make them up instead of Googling them
[15:45] <larsu> sounds like a plan :D
[15:46] <Laney> qengho: https://jenkins.qa.ubuntu.com/job/wily-adt-chromium-browser/lastBuild/ looks passed to me, where's the error?
[15:46] <Sweet5hark> seb128, qengho: yes, saw some 'tooling failures' (aka during downloads/deb install etc.) too on jenkins
[15:46] <qengho> Laney, it's up and down. Not consistent.
[15:46] <Sweet5hark> seb128, qengho: not sure though if its getting more -- I dont have a good long term metric
[15:47] <Laney> You should go ask 'cihelp' on #ubuntu-ci-eng
[15:47] <qengho> https://jenkins.qa.ubuntu.com/job/wily-adt-chromium-browser/29/   https://jenkins.qa.ubuntu.com/job/wily-adt-chromium-browser/29/ARCH=i386,label=adt/artifact/results/log/*view*/
[15:47] <Laney> they ought to be aware of infrastructure issues
[15:47]  * qengho nods.
[15:48] <larsu> Laney: did you take that totem patch or are we waiting for a sign from upstream?
[15:48] <larsu> asking because I'm afraid hadess might take a whlie
[15:50] <Laney> didn't yet
[15:50] <Laney> why's that?
[15:51] <willcooke> hey tkamppeter, can you give us your weekly update?
[15:51] <tkamppeter> Yes.
[15:51] <willcooke> #topic tkamppeter
[15:51] <larsu> Laney: just a general feeling
[15:52] <tkamppeter> I did more upstream work on cups-filters, fixing bugs, improving support for auto-discovered IPP network printers.
[15:53] <tkamppeter> I also fixed some bugs in CUPS' implementation of a PPD generator for IPP network printers, which is also used by cups-filters.
[15:53] <tkamppeter> Sorry for typing life and having arrived late, I got a new (cable) internet access and also needed to do some electric installations.
[15:53] <larsu> cable \o/
[15:54] <willcooke> np tkamppeter, thanks for the update
[15:54] <willcooke> #topic Any Other Business
[15:54] <willcooke> Ok, anything else or are we done?
[15:55] <willcooke> 1m timeout
[15:56] <seb128> thanks ;-)
[15:56] <willcooke> #endmeeting
[15:56] <meetingology> Meeting ended Tue Jun  2 15:56:26 2015 UTC.
[15:56] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2015/ubuntu-desktop.2015-06-02-15.30.moin.txt
[15:56] <willcooke> thanks everyone
[15:56] <willcooke> (that one was in "American")
[15:57] <seb128> hehe
[16:51] <Laney> seb128: just did some tweaks to the snaptop build
[16:51] <Laney> https://launchpadlibrarian.net/208100551/buildlog_ubuntu_wily_amd64_ubuntu-desktop-next_BUILDING.txt.gz seems that might come from system-image-dbus
[17:02] <seb128> Laney, hum, I guess we shouldn't install system-image-dbus on the snappy image
[17:03] <Laney> don't know
[17:04] <Laney> I guess there's a thing to do updating
[17:04] <seb128> right, but settings is not ready for that atm...
[17:06] <Laney> well anyway, up to you
[17:06] <Laney> I just found some broken bits of the switch and fixed them
[17:06] <seb128> thanks
[17:06] <Laney> so it will at least try to build the right kind of image now It hink
[17:06] <seb128> well I'm unsure how to resolve that yet
[17:07] <seb128> need to look at u-s-s and if we can make it work on snappy
[17:07] <seb128> but it might not be trivial and I don't want to delay the iso to start on that
[17:08] <Laney> is this going to need a channel or whatever snappy thing?
[17:09] <Laney> maybe just make uss hide its updates plugin if there's no s-i or click
[17:11] <Laney> see you tomorrow
[17:14] <seb128> Laney, yeah, I'm unsure if snappy has a dbus service for updates
[17:14] <seb128> mvo_, ^? ;-)
[17:14] <seb128> Laney, but yeah, otherwise I'm going to make that more dynamic/hide the panel and lower the depends to a recommends or suggests (do we have recommends enabled on desktop-next?)
[17:16] <mvo_> Laney: no dbus, no. there will be a rest service though
[17:18] <seb128> mvo_, k, thanks
[18:33] <mitya57> larsu, I tried to look at how we can change our pkgkde-m-p-s script, but it turned out it's now always easy to detect if a function accepts only a pointer/reference or also an instance
[18:34] <mitya57> I.e. if a function signature is void(foo *, foo) then the symbol will end with P3fooS_
[18:34] <mitya57> So if we will ignore P#classname and R#classname, it will be ignored false-positively
[18:36] <mitya57> Of course we can invent a more complex logic, but in the world of GCC symbols it will be always error-prone. So it's better to have the current implementation, I think.
[18:36] <mitya57> What's wrong with rebuilding gsettings-qt with every new Qt release?
[18:37] <mitya57> Mirv, ^
[21:04] <robert_ancell> desrt, are you on a rocking chair?
[21:05] <desrt> robert_ancell: i was on a swing
[22:06] <RAOF> That swing looked nice.
[22:10] <willcooke> g'night all
[22:10] <willcooke> thanks for being available for the meeting chaps