[00:01] <robert_ancell> RAOF, Given we know the dimensions of the output, we want to know our logical position within that box. Where we are on screen is actually up to the shell, a client just wants its windows to be logically layed out inside that bo
[00:01] <robert_ancell> x
[00:02] <robert_ancell> In a multi-window app, the windows are not relative to eachother, but we probably want to place them in a particular space
[00:04] <RAOF> What do you mean by a particular space?
[00:05] <RAOF> Oh, by “surface relative” I *don't* mean “moves with the parent surface” (except for special types, like popovers).
[00:06] <robert_ancell> I mean I have two windows in my app (both toplevel) which are rectangles in some particular space (i.e. the monitor size). They should be placed so they relate to eachother in some way (one on the left, one on the right perhaps)
[00:06] <robert_ancell> It would be arbitrary to say place window B relative to A
[00:06] <robert_ancell> They are really placed more based on the monitor than each other
[00:07] <robert_ancell> Decorations of course make this a bit impossible
[00:09] <RAOF> But people are going to be able to move those windows freely around?
[00:09] <robert_ancell> yeah, the shell can do what it likes
[00:10] <robert_ancell> It feels like relative positioning where the windows aren't linked in movement (i.e. useful for things like tooltips) doesn't give us any advantages
[00:12] <RAOF> Well, I can easily give you an abstract coordinate space to work in, as long as you don't mind that it doesn't map to an output.
[00:12] <robert_ancell> RAOF, that seems appropriate to me
[00:13] <RAOF> But this also seems like an API that's there because that's how it's currently done; will an app ever care that the window is 10 units to the right rather than 20 units to the right?
[00:13] <RAOF> ie: Would it perhaps make more sense for the API to allow the application to say “put this window to the right of that one”
[00:14] <robert_ancell> But do we have a good definition of what "to the right of" means? Won't that be shell dependent
[00:14] <RAOF> Yes.
[00:14] <RAOF> But that's the case with a coordinate space, too.
[00:15] <RAOF> And, in your example, the user can move the windows around themselves, so it's clearly not critical that the A be to the left of B.
[00:16] <RAOF> And if the API has _explicit_ semantics, rather than the implicit semantics of a coordinate space, shells have a better chance of doing the right thing.
[00:17] <RAOF> eg: I'm a tiling shell; I care not at all for your pesky coordinates! But “please put A left of B” still makes sense in the tiled world.
[00:17] <robert_ancell> I'd like to see the list of logical positioning
[00:18] <robert_ancell> RAOF, ok, but subwindows (i.e. tooltip/menus) they do use a co-ordinate space relative to their parent window?
[00:18] <RAOF> Right.
[00:19] <robert_ancell> so when can I have that :)
[00:19] <RAOF> After you get eventloopyness :)
[00:19] <RAOF> That bit shouldn't be terribly hard to do.
[00:20] <RAOF> Although it means fiddling with IPC, which I find endlessly awkward.
[00:20] <robert_ancell> RAOF, and grabs - are they just "this child surface receives all events for its relatives"?
[00:21] <RAOF> Of course, that's the Mir bit that you can get; Unity8 will get support for that on its own timeline.
[00:21] <RAOF> Urgh, grabs.
[00:21] <robert_ancell> yes
[00:21] <RAOF> Yeah, need to work out exactly what we mean by them.
[00:21] <robert_ancell> Client level grabs seem fairly sound to me, I can't think of another method to do them
[00:22] <robert_ancell> Obviously anything higher than that is not allowed
[00:22] <robert_ancell> You could almost implement client level grabs entirely in libmirclient I guess
[00:22] <RAOF> Yes.
[00:22] <RAOF> Is that what we want, though?
[00:23] <RAOF> That means we'll have different behaviour for eg: menus to what we currently have.
[00:24] <RAOF> Actually, you could implement client-level grabs in the toolkit.
[00:25] <robert_ancell> But is that just a hangover of the "X way to doing things"? As I can see all we want for menus is to get the motion events and click events inside the menu surface, and just handle clicks outside them (to dismiss them). Any other clients surface that gets an event should give some sort of focus out event which is sufficient to dismiss the menus
[00:27] <RAOF> That does mean that you need to click on the owner's surface in order to dismiss menus without doing something else.
[00:27] <RAOF> I'm not sure to what extent that's a problem.
[00:28] <RAOF> What I was thinking of doing is handling the dismissal for you - when clicking outside a surface of type popover (or whatever) we kill the popover.
[00:28] <RAOF> (And don't otherwise deliver the event)
[00:28] <robert_ancell> I was also wondering if that's sufficient (I think it might be)
[00:34] <robert_ancell> food for thought. Speaking of food... bye!
[00:34] <RAOF> Lunch!
[06:48] <didrocks> mvo: hey! tell me when you get some time to have a look at this "done" callback which is called
[06:49] <mvo> didrocks: now?
[06:50] <didrocks> mvo: sure!, so git clone git@github.com:didrocks/ubuntu-developer-tools-center.git
[06:50] <didrocks> then, the easiest is to create a virtualenv I guess (as per README.md):
[06:50] <didrocks> $ virtualenv --python=python3 env
[06:50] <didrocks> $ env/bin/pip install -r requirements.txt
[06:50] <didrocks> $ source env/bin/activate
[06:50] <didrocks> and finally, to get a test which pass, but with all debug infos:
[06:50] <mvo> didrocks: hm, ubuntu-.*-center is taken ;) and is has to be centre and its a bad omen :P
[06:51]  * mvo hugs didrocks - just kidding of course
[06:51] <didrocks> nosetests -c log-confs/debug_test.cfg tests/small/test_requirements_handler.py:TestRequirementsHandler.test_error_in_dpkg
[06:51] <didrocks> mvo: ahah, really true! Totally forgot about that discussion
[06:51]  * didrocks hugs mvo back
[06:52] <didrocks> tell me if you see the test_error_in_dpkg test running (and passing) with all debug logs printed
[06:58] <mvo> didrocks: its building
[07:00] <mvo> didrocks: ok, tests is there now and runs and passes, what should be different :) ?
[07:01] <didrocks> mvo: so, you should have as debug message:
[07:01] <didrocks> 2014-06-12 09:01:05,002 [udtc.network.requirements_handler] DEBUG: ['testpackage'] install update: 0.0
[07:01] <didrocks> 2014-06-12 09:01:05,114 [udtc.network.requirements_handler] DEBUG: Install for ['testpackage'] ended.
[07:01] <didrocks> I wouldn't expect the last one (the install ended)
[07:01] <didrocks> look at udtc/network/requirements_handler.py
[07:02] <didrocks>                 logger.debug("Install for {} ended.".format(self._bucket['bucket']))
[07:02] <didrocks> line 161
[07:02] <didrocks> in finish_update()
[07:02] <didrocks> from         class _InstallProgress(apt.progress.base.InstallProgress):
[07:02] <didrocks> which is the install progress handler I installed on commit()
[07:07] <mvo> didrocks: ok, give me a sec to read over the test etc
[07:28] <mvo> didrocks: sorry, took a while to read through this stuff (and I was distracted for a sec)
[07:28] <mvo> didrocks: so, why should finish_update() not be called? its done, even thought there is a error
[07:29] <mvo> didrocks: don't get me wrong, I'm asking so that I can improve the docstrings :)
[07:29] <mvo> didrocks: not to blame you that you use it wrong :)
[07:29]  * mvo creates a feature/didrocks branch
[07:30] <didrocks> :)
[07:30] <didrocks> mvo: yeah, and you told error() were for errors outside of dpkg, right?
[07:30] <mvo> (and I should add that the name "finish_update" really sucks
[07:30] <mvo> didrocks: yeah, error() is called for error message that dpkg --status-fd generates
[07:30] <didrocks> (sounds like a method naming chosen by a French :p)
[07:31] <mvo> didrocks: its terrible, sometimes I whish I could have a timemachine
[07:31] <mvo> to talk to my former self about certain decisions :/
[07:31] <didrocks> hum, so the only way is the exception that is raised… which is fine I guess, but the docstring should mention finish_update is always called unless error() is called, and that error is only for errors in…
[07:32] <didrocks> mvo: but that would create some time corruption!
[07:32] <didrocks> don't do it, please ;)
[07:32] <didrocks> at most, leave a paper on your former desk :p
[07:33] <mvo> didrocks: hm, finish_update should be always called, is that different from what you see?
[07:34] <didrocks> hum, let me try to see if I can raise an error()
[07:38] <mvo> didrocks: how does http://paste.ubuntu.com/7632429/ look?
[07:38] <didrocks> mvo: sounds good!
[07:38] <mvo> didrocks: I will look into the other issues you raised too (i.e. returning boolean states for the mark_install and friends) and provide a installprogress that logs or some file etc but one step at a time :)
[07:38] <didrocks> I can't reproduce the error though
[07:38] <mvo> didrocks: so keep the feedback coming
[07:39] <didrocks> mvo: will do! thanks for fixing those :)
[07:39] <mvo> didrocks: you can't reproduce that finish_updates() is not always called?
[07:39] <didrocks> no, I thought I would raise an error first for my current test case
[07:39] <didrocks> like testpackage and testpackage2
[07:39] <didrocks> trying to install them together
[07:39] <didrocks> with testpackage2 breaks (I tried conflicts as well) testpackage
[07:40] <mvo> didrocks: it seems like the (few) people using python-apt are so used to its warts that they don't see those (obvious) problems, so your feedback is very valuable
[07:40] <mvo> didrocks: best is to have a breaking maintainer script
[07:40] <mvo> didrocks: i.e. postinst with exit 1
[07:40] <mvo> didrocks: to trigger the error() method
[07:40] <didrocks> mvo: will create a package like that in a sec
[07:41] <didrocks> mvo: on the other one, shouldn't I get any feedback when I try to ask for something I can't?
[07:41] <didrocks> like this testpackage and testpackage2
[07:41] <didrocks> it's installing happily testpackage2, unmarking testpackage for install
[07:41] <didrocks> before commit()
[07:41] <mvo> didrocks: the resolver will not allow it
[07:42] <mvo> didrocks: yeah, it will "fix" it for you unless you use "auto_fix=False" in mark_install()
[07:42] <mvo> didrocks: in which case iirc commit() will raise a exception if you try to commit a broken cache (might be worth double checking though and is probably a good test-case for python-apt itself)
[07:42] <didrocks> ah ok, it's not on of my use case I guess (handling that manually), but as I was trying to get some more testing… :)
[07:42] <didrocks> let me check with auto_fix=False
[07:42] <didrocks> just to see :)
[07:43] <didrocks> mvo: yeah, so it sent error()
[07:44] <didrocks> as I tried to commit a broken cache()
[07:44] <didrocks> (so not only broken maintainer script)
[07:44] <didrocks> no exception though
[07:44] <didrocks> ah, sorry, one exception as well
[07:44] <didrocks> so:
[07:44] <didrocks> 1. calling error()
[07:45] <didrocks> 2. raising SystemError
[07:50] <mvo> ok
[08:05] <Laney> hey hey
[08:05] <seb128> good morning desktopers
[08:05] <seb128> hey Laney!
[08:05] <seb128> how are you?
[08:06] <Laney> I got told off in #ubuntu-ci-eng overnight!
[08:06] <Laney> other than that good ;-)
[08:06] <seb128> lol
[08:06] <seb128> what did you do this time?
[08:06] <Laney> it's quite fine today 22°
[08:06] <seb128> same here, nice to be back to less hot weather
[08:06] <Laney> "broke the rules by doing an upload without using ci train in the first  place.
[08:06] <Laney> "
[08:06] <seb128> lol
[08:07] <seb128> tell them than french train are not working this week (which is true, they are unhappy about changes being discussed)
[08:07] <Laney> grrrr
[08:07] <seb128> what source did you upload?
[08:07] <Laney> I think it was dbus-test-runner like months ago
[08:07] <Laney> I even did a merge proposal ...
[08:08] <seb128> oh
[08:08]  * Laney grump
[08:08] <seb128> right, they landed that this night
[08:08] <seb128> ignore them, they like to complain
[08:14] <didrocks> hey seb128, Laney!
[08:14] <seb128> lut didrocks, wie gehts?
[08:14] <didrocks> seb128: don't start speaking about french train…
[08:14]  * didrocks will have to suffer from this in few hours :)
[08:14] <didrocks> otherwise, good!
[08:14] <seb128> heh
[08:15] <seb128> did you go for morning exercice today?
[08:15] <didrocks> not yet, was planning to go in 15 minutes
[08:15] <Laney> hey didrocks
[08:15] <didrocks> finishing up as many tests as possible before :)
[08:15] <Laney> how's being an apt client treating you?
[08:17] <didrocks> for testing, I'm getting a lot of questions ;)
[08:17] <didrocks> but nicely, mvo is fixing up the documentation on my feedbacks :)
[08:17] <didrocks> so I should be done in a couple of hours to finish those tests (already at 70%)
[08:18] <mvo> Laney: I'm looking at the aptdaemon adt issue right now
[08:18] <Laney> mvo: awesome, thanks!
[08:19] <Laney> did you fix the apt issue too? ;-)
[08:19] <mvo> Laney: almost!
[08:19] <didrocks> Laney: apart from being grumpy to be layed off the train, everything's good? :)
[08:20] <mvo> Laney: for some reason my adt-run behaves differently from the jenkins one for the apt tests, but I'm close
[08:21] <Laney> mvo: I meant bug #1328838
[08:21] <Laney> are you running adt in the proper VM-y way?
[08:22] <Laney> or is it lxc?
[08:22] <Laney> I forgot what the proper way is currently. :(
[08:22] <mvo> Laney: I guess not, schroot or lxc
[08:22] <seb128> mvo, Laney: slangasek reverted to gcc-4.8 default because of an ABI change in c++ in 4.9 it seems ... maybe that's what hit libapt there?
[08:23] <seb128> gcc-defaults (1.128ubuntu4) utopic; urgency=medium
[08:23] <seb128>   * Revert default to 4.8, due to as-yet-undiagnosed C++ ABI breakage
[08:23] <seb128>     (LP: #1329089).
[08:23] <seb128> just mentioning it in case
[08:23] <Laney> oh, could be
[08:23] <mvo> yeah, that sounds more like it
[08:23] <Laney> can you do a uss cross-build to see?
[08:23] <Laney> that apt went to release so it should happen there too
[08:23] <Laney> now
[08:24]  * seb128 tries
[08:27] <seb128> Laney, do I need to do anything to update my chroot or just run the sbuild command and see if that success?
[08:27] <Laney> it updates itself before building, so you should be fine
[08:28] <seb128> k, seems it's doing that
[08:28] <Laney> you can do sbuild-update -udcar <chroot> every now and again to update in the base chroot which means it has to do less each time
[08:28] <seb128> it's upgrading gcc and installing 4.9
[08:28] <seb128> ok, thanks
[08:29] <didrocks> actually, I was really pessimistic telling a couple of hours. All tested now :)
[08:30] <didrocks> (creating the framework is always soooo long compared to add tests once it's done)
[08:31] <seb128> ;-)
[08:38] <didrocks> and https://travis-ci.org/didrocks/ubuntu-developer-tools-center/builds/27384556 \o/
[08:38] <didrocks> I should try to disable fsync() for dpkg, I guess it's what are making the tests long…
[08:39] <didrocks> hum, --force-unsafe-io
[08:41] <didrocks> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613428 -> seems raphaël doesn't really agree to use that though
[08:49] <Laney> seb128: Still breaks here
[08:49] <ochosi> arr, tiheum just left. anyhow, hi everyone! wanted to ask whether there were plans for moving to the new icon theme in 14.10
[08:49] <Laney> hmm I didn't get apt 3 yet though
[08:49] <seb128> Laney, where does it stop? it's 45% built here
[08:49] <Laney> same
[08:49] <seb128> ochosi, wait for tiheum to be back
[08:49] <seb128> we don't know
[08:49] <seb128> ochosi, ^
[08:49] <seb128> lol
[08:49] <seb128> or not
[08:50] <ochosi> oh crap :)
[08:50]  * seb128 is afaik for a bit
[08:50]  * ochosi has the feeling he's being ducked
[08:51] <ochosi> tiheum: hi there! quickly wanted to ask whether there were any plans yet for the new icon theme in 14.10 (we talked about it during the 14.04 cycle, i'd be interested to add support for xubuntu to it)
[08:51] <ochosi> :/
[08:51] <Laney> haha
[08:51] <ochosi> someone has an unstable connection there
[08:52] <didrocks> ok, the win is 9s with eatmydata, let's keep it
[09:00] <Laney> mvo: waah, indeed it does build again with apt ubuntu3
[09:00] <Laney> which used 4.8 ...
[09:00] <mvo> Laney: cool
[09:01] <Laney> uncool!
[09:01] <mvo> hm? at least we know the issue now
[09:01] <mvo> no?
[09:01] <Laney> well we know it's not apt's fault
[09:01] <Laney> still don't like toolchain bugs :)
[09:01] <mvo> we know its a subtle abi break in 4.8 vs 4.9
[09:03] <mvo> and we even have a bugnumber
[09:03]  * Laney throws this hot potato to doko
[09:15] <chrisccoulson> mvo, my ears prick up at "4.8", "4.9" and "subtle abi break"
[09:15] <chrisccoulson> what's this? :)
[09:17] <mvo> chrisccoulson: https://bugs.launchpad.net/ubuntu/+source/gcc-4.9/+bug/1329089
[09:18] <chrisccoulson> mvo, ah, interesting. I wonder if it contributes to bug 1328697?
[09:48] <mvo> didrocks: https://github.com/mvo5/python-apt/compare/feature;didrocks?expand=1
[09:49] <mvo> didrocks: more after lunch
[10:38] <seb128> Laney, I've a silo with u-s-s, https://launchpad.net/~ci-train-ppa-service/+archive/landing-001/
[10:38] <seb128> Laney, do you want me to include lp:~laney/ubuntu-system-settings/timedate-tests-wait in it?
[10:38] <Laney> might be a good idea
[10:38] <Laney> let's wait for CI
[10:38] <seb128> k
[10:39] <seb128> the silo is a bit stucked atm anyway, so no hurry
[10:39] <seb128> need to wait mterry
[10:39] <seb128> he added depends on libunity-mir
[10:39] <seb128> which is not available on all archs and restricted our set
[10:40] <Laney> what's that for?
[10:42] <seb128> Laney, http://irclogs.ubuntu.com/2014/05/13/%23ubuntu-touch.html#t18:48
[10:42] <seb128> is the reply I got back then when I asked
[10:42] <Laney> I see
[10:57] <seb128> Laney, u-s-s crossbuild worked for me btw, though dpkg-shlibdeps displayed some weird unresolved symbol errors for c++ atexit symbols
[10:57] <Laney> yeah don't know what that is
[10:57] <Laney> did you try with proposed?
[10:57] <Laney> apt only migrated 33 minutes ago
[10:57] <seb128> no
[10:57] <Laney> you might have had the old one then
[10:58] <Laney> I think I got confused by the versions and thought it had gone in earlier
[10:58] <seb128> well, it migrated now?
[10:58] <Laney> still, this new one works
[10:58] <seb128> great
[11:03]  * Laney looks at colord/gtk transition
[11:22] <darkxst> hey seb128, Laney
[11:23] <Laney> larsu: it failed again :(
[11:23] <Laney> colorchooser
[11:24] <Laney> hey darkxst
[11:24] <Laney> what up homie
[11:24] <larsu> Laney: impossible!
[11:24] <darkxst> have had a pretty bad cold this week, so not a whole lot really
[11:24]  * larsu wonders why it works for him
[11:25] <darkxst> am liking the cool weather though!
[11:26] <Laney> hah
[11:26] <Laney> I bet it's still warmer than here
[11:27] <Laney> larsu: http://paste.ubuntu.com/7633244/
[11:27] <Laney> 10149
[11:27] <Laney> sorry for the huge log
[11:27] <darkxst> seb128, Larsu so CSD's etc are fixed in the gtk+ 3.12 upload? i.e. ok to upload things that use GtkHeaderBar once gtk propagates?
[11:28] <darkxst> Laney, aren't you guys having a heat wave? we have winter so a somewhat mild 10-15C most days
[11:28] <Laney> it's about what you'd expect for june
[11:28] <Laney> 20-ish
[11:29] <larsu> darkxst: there are no fixes for header bars on windows in those patches
[11:29] <larsu> and there won't be
[11:30] <darkxst> larsu, so what is happening with headerbars then?
[11:30] <darkxst> apart from the usual Ubuntu GNOME wants them, and Ubuntu doesnt....
[11:31] <larsu> we're keeping the old apps afaik
[11:31] <larsu> and make header bars work on compiz if people want to use an app without a title bar
[11:31] <Laney> you can do patches to make them conditional
[11:31] <Laney> Trevinho is fixing compiz to at least make them work properly
[11:32] <Laney> so for non-Ubuntu-default apps you can update them I think
[11:32] <Laney> I'd wait until this compiz work goes in though
[11:32] <darkxst> Laney, I don't think its possible to patch the apps, that properly use the GtkHeaderBar API
[11:33] <darkxst> in that case gtk needs to be patched
[11:34] <seb128> hey, csd apps are not ok, no
[11:34] <seb128> compiz/unity still don't handle them
[11:34] <larsu> darkxst: I looked into that and came the conclusion that it's not feasible without a big amount of work
[11:34] <seb128> even when they do, we need to see how much UI regression it creates
[11:35] <seb128> well, that's only about things used by default on Ubuntu desktop, universe apps ... it's up to app writers to let their users down, we can't fix the universe
[11:36]  * larsu remembers that quote. "We can't fix the universe"
[11:36] <ochosi> darn, what good are MOTUs if they can't ^ ?
[11:37] <darkxst> quite a few of our core apps are in main, since you guys stole them ;)
[11:37] <Laney> sure you can patch things to not set a headerbar
[11:37] <seb128> "stole" them
[11:37] <seb128> it's rather that GNOME took over things just because they happen to be hosted on their infrastructure
[11:38] <ochosi> can't headerbars be shown conditionally, depending on the environment/desktop?
[11:38] <seb128> but let's not start arguing over that, it's not going to be constructive
[11:38] <seb128> ochosi, they can, it's "just" extra code for upstreams
[11:38] <seb128> but they need to get used that they don't get and UI working on GNOME and other desktops for free
[11:38] <ochosi> sounds like a snippet that should be provided upstream, i guess that's always going to be the same code, no?
[11:38] <seb128> they have to do work to support the different envs
[11:39] <seb128> which most don't like, because it used to not be this way
[11:39] <Laney> no, it's modifying part of your UI
[11:39] <Laney> you have to put the stuff in the header somewhere else instead
[11:39] <Laney> which is going to be different per app
[11:39] <ochosi> simple: toolbar
[11:39] <seb128> iit would be weird to have a toolbar with a cog icon only in it
[11:40] <ochosi> i actually patched our theme in xubuntu (as a test) and when you hide the "close" button (we had the double-window-border issue) it looks just like a toolbar
[11:40] <darkxst> seb128, I was being somewhat sarcastic with that comment, but it is a real problem!
[11:40] <ochosi> right, that would be weird, but often headerbars have >1 item
[11:40] <seb128> darkxst, I know it is :/
[11:40] <larsu> let's please not talk about this again
[11:40] <larsu> changing application's UI under their feet is not a good idea
[11:40] <seb128> so yeah, we are making unity handle those
[11:40] <larsu> if they want to support different desktops, it's pretty easy to do so
[11:40] <seb128> then we need to sort out the core apps issue
[11:40] <larsu> *how* it is done depends on the app
[11:41] <seb128> the default is "do not update, we need to sort them on the case by case"
[11:41] <seb128> the solutions can be
[11:41] <larsu> like seb128 said, it's not just a matter of converting a headerbar to a toolbar
[11:41] <seb128> - changing the app/patching it
[11:41] <seb128> - using a different one for Ubuntu
[11:41] <seb128> - doing a fork of the current version to use in Ubuntu
[11:41] <seb128> - other ideas?
[11:42] <darkxst> seb128, headerbar dropping window controls and traditional titlebar (for unity etc)
[11:42] <seb128> dropping control is not enough
[11:42] <seb128> you end up with having the app title in the wm decoration and then under it in a weird bar
[11:43] <Laney> aaaaaaaaaanyway!
[11:44] <seb128> do we have a list of the apps that people want to update and are blocked on that?
[11:44] <seb128> gedit is likely on that list
[11:44] <seb128> nautilus
[11:45] <seb128> we should have a blueprint with the list, so we can take notes for each case
[11:45] <darkxst> seb128, nearly all the 3.12 apps are using headbars
[11:46] <seb128> I tried eog this week and it didn't seem to have those
[11:46] <darkxst> terminal is the only one I can think of that isnt, but that is blocked by other stuff
[11:46] <darkxst> right, eog might not, sushi doesnt but thats not in main
[11:47] <seb128> well, so
[11:47] <seb128> step 1 is to land the unity support
[11:47] <seb128> then we can start testing and see how things look
[11:48] <darkxst> and step 2, UG runs of time again!
[11:49] <seb128> better suggestion?
[11:49] <seb128> "let's update, screw Ubuntu Desktop users, and see what we can do to sort it out" is not a better option
[11:50] <ochosi> i know flavors maybe aren't as important as unity, but it'd also screw over xfce-based flavors
[11:51] <seb128> right
[11:51] <darkxst> seb128, no that is not an option, and you know good well, we (well mostly I) have spent a good deal of time, making things compatible
[11:51] <seb128> likely some other less-used desktops as well
[11:52] <Laney> it's not just you
[11:52] <Laney> larsu did some patches last cycle
[11:52] <seb128> Trevinho is adding support to unity
[11:52] <seb128> so we are working on it
[11:53] <darkxst> Laney, I meant from the ubuntu GNOME side
[11:53] <seb128> but yes, it's likely to take some time and put Ubuntu GNOME in a difficult position again
[11:53] <seb128> the easiest way to avoid that is to just fork the apps that you really want to update
[11:53] <seb128> the forks could be on our side
[11:53] <Laney> urgh
[11:53] <seb128> but just have a source for the old version and one for the new one
[11:53] <darkxst> seb128, it totally makes no sense for us to for upstream code
[11:54] <darkxst> ^fork
[11:54] <seb128> well, we have choise between, screw users, fork, patch, find other apps to use
[11:54] <Laney> decide we like headerbars
[11:56] <seb128> that's the "screw users" option
[11:56] <seb128> they are never going to be consistent with things using wm decorations
[11:57] <seb128> nor they fit our design
[11:58] <darkxst> yes I get that but there needs to be a solution
[11:59] <seb128> well, I listed the options I see
[11:59] <seb128> neither are great
[11:59]  * larsu votes for "screw users"
[11:59] <seb128> not sure how much patching having different UIs required
[12:00] <larsu> seb128: a lot. If we want the newest apps in the gnome flavor, we should think about forking
[12:00] <larsu> but that's probably a lot of work as well
[12:02] <Laney> I don't know how fair it is to call it screwing users
[12:02] <Laney> it's not like we have a massive amount of consistency currently
[12:02] <darkxst> right there are already apps in main using psuedo-headerbars like nautilus
[12:03] <Laney> anyway I think patching to work without headerbars is most desirable and forking would be very sad
[12:03] <Laney> they're like opposite ends of the spectrum to me
[12:03] <larsu> darkxst: nautilus uses a pseudo-headerbar? How so?
[12:04] <larsu> Laney: also the most work
[12:04] <larsu> Laney: I agree though, that would be the best outcome
[12:04] <darkxst> larsu, like the top toolbar minus window controls etc
[12:04] <seb128> Laney, we are mostly consistent on things like menus and windows behaviours
[12:05] <larsu> darkxst: but it has a titlebar and a proper window menu
[12:05] <larsu> but yeah, this is where the line between headerbars and toolbars gets blurry
[12:06] <Laney> like did we screw users by including the webbrowser-app?
[12:06] <Laney> I think it's not very good to use that kind of term
[12:07] <Laney> but yeah, first we need to get the support in compiz
[12:08] <seb128> Laney, yeah, I don't think the new webbrowser-app fits well on desktop atm
[12:08] <seb128> sorry for the wording :/
[12:08] <seb128> would "user experience regression" be betteR?
[12:09] <larsu> firefox -> webbrowser app is quite a UX regression
[12:09] <seb128> webbrowser-app is a user experience regression yes, and I'm not happy about it either
[12:11] <Laney> I'd rather you avoid trying to label it at all :)
[12:11] <Laney> You present a list of options and each has different positives and negatives
[12:11] <Laney> eventually we take a decision
[12:11] <seb128> that's fair enough
[12:12] <Laney> It's clear that the csd fix is a prerequisite to anything which involves using that stuff though
[12:13] <Laney> now, /me moves on to fixing stuff :P
[12:13] <Laney> there's a weird problem with dbus-activation of whoopsie-preferences in u-s-s
[12:14] <darkxst> Laney, I have hit a couple of wierd dbus-activation bugs since mid-way through trusy
[12:14] <darkxst> trusty
[12:14] <Laney> I blame Qt or my own shitty code :)
[12:14] <Laney> what problems?
[12:15] <Laney> actually it's evan's code, not mine ;)
[12:15] <darkxst> no Qt, just stuff not activating
[12:15] <darkxst> somewhat randomly at that
[12:15] <Laney> it activates if I poke the interface with gdbus
[12:15] <Laney> so I blame our code
[12:15] <darkxst> but it always works when you call it with gdbus
[12:16] <Laney> ha
[12:20] <darkxst> Laney, I orginally thought it might have been related to changes in glib, but couldnt track anything down
[12:20] <darkxst> well not anything useful
[12:20] <Laney> mmm
[12:20] <Laney> this is totally not random
[12:21] <darkxst> Laney, I don't have a solid test case though
[12:32] <Laney> gtk went in
[12:32] <seb128> \o/
[12:32] <seb128> thanks mvo!
[12:32] <seb128> Laney, thanks for looking at it and pinging people about the issues as well ;-)
[12:33] <Laney> and doing the colord transition!
[12:33] <Laney> :P
[12:33] <Laney> it was a good team effort
[12:34] <seb128> heh
[12:34] <mvo> seb128: your welcome, sorry for causing the blockage in the first place
[12:34] <seb128> no worry ;-)
[12:36] <Laney> larsu and seb128 and mvo and ricotz
[12:36] <Laney> gooooo team
[12:36] <seb128> indeed! ;-)
[12:38] <larsu> a "gooooo team" is a team made of goo?
[12:38] <Laney> funny, I did just see this video from chrisccoulson ...
[12:38]  * larsu tries to figure out Laney's build failure now
[12:39] <chrisccoulson> hah
[12:40]  * seb128 notices that chrisccoulson is there when people talk about funny videos
[12:40] <seb128> chrisccoulson, hey ;-)
[12:40] <chrisccoulson> hi seb128 :)
[13:07] <larsu> Laney: did you build gtk from my branch or did you copy the patches over?
[13:07]  * larsu is wondering whether you forgot to copy a11y-test-update-color-chooser-output.patch
[13:18] <seb128> mterry, hey
[13:19] <seb128> mterry, how busy are you with the split greeter crazyness?
[13:19] <mterry> seb128, a little busy, what you got?
[13:19] <seb128> mterry, the wizard is creating issues, see my comments on the merge request
[13:20] <seb128> mterry, basically we need to make either the wizard or the unity-mir code optional and turn it off on archs where unity-mir doesn't exists
[13:20] <mterry> seb128, ah right, I saw that comment
[13:20] <mterry> seb128, yeah OK.  I can look into making unity-mir optional
[13:20] <seb128> mterry, do you think you can work on that or do you need help doing it?
[13:30] <seb128> bregma, hey, do you need help testing the unity update for utopic? I see it's in a silo for some days
[13:31] <bregma> seb128, no, we've been using it to test running AP tests against silos so we can get back to the level of automated tech we used in 2013
[13:31] <bregma> we're done with that for now, I'll be marking it as tested soon
[13:32] <seb128> bregma, great, thanks
[13:56] <Laney> larsu: I merged the branch
[13:57] <Laney> look at the log, you can see the patch being applied at the top
[13:58] <Laney> larsu: http://paste.ubuntu.com/7633244/ line 2045
[13:59] <Laney> you should set up sbuild so you can reproduce ;-)
[14:00] <larsu> Laney: ah, right. Fun.
[15:02] <seb128> bregma, not sure if something changed, or if it was random behaviour and I'm lucky today, but unity8-desktop-mir keeps working after suspend/resume cycles now (using the platform-api ppa that is about to land)
[15:03] <bregma> goody, because taht was causing me inconvenience
[15:03] <seb128> is it working for you as well?
[15:07] <bregma> seb128, I'll be testing it in a few minutes, I'm bottlenecked on test machines at the moment
[15:07] <seb128> k
[15:14] <bregma> seb128, Unity8 now wakes up properly when I close my laptop lid and re-open, except I seem to lose the keyboard input after that
[15:15] <bregma> mouse and touch seem to work, though
[15:15] <seb128> same here
[15:15] <bregma> I'll test on my other machine
[15:15] <seb128> I didn't test keyboard at first
[15:16] <seb128> I was happy being able to scroll on the dash with the touch screen ;-)
[15:17] <bregma> there's a brief time when it wakes up after sleeping where the keyboard send input to the terminal, then a flash on the screen and the input stops
[15:17] <bregma> you need to be quick to see it
[15:19] <bregma> hmm, my other machine does not seem to want to run Unity 8 after I install the PPA, investigating....
[15:22] <bregma> I see "Ubuntu Platform API: Selected module is invalid -- Aborting" in the log, I'll try again....
[15:22] <seb128> bregma, do you have qtubuntu-desktop installed/uptodate?
[15:23] <bregma> all I did was a dist-upgrade with the PPA in the sources
[15:23] <seb128> bregma, dpkg -l | grep ubuntu-application-api2-desktop
[15:24] <bregma> yes, everything seems to be installed from the PPA
[15:25] <seb128> k, I was getting that error before upgrading qtubuntu-desktop and getting ubuntu-application-api2-desktop
[15:25] <seb128> you probably have another issue
[15:26] <bregma> ah, yes, I had a custom upstart script for the session (to handle changing the scaling factor)
[15:26] <bregma> I moved it out of the way, Unity 8 starts fine
[15:27] <bregma> if by fine you mean teeny-weeny 300 DPI display
[15:28] <bregma> ...aaaand yes, I get the same lost keyboard when I close and open the laptop lid
[15:33] <Trevinho> seb128, larsu, Laney: as I said (to larsu) the only concern I've with headerbars in unity (excluding the design point of view, which is is pointless now), is that if the LIMs are enabled, then you'll  miss the application menu. But the good Larsu told me that the idea is to move out things from menubar and showing a menu-button, instead... And this would do
[15:33] <Trevinho> the work.
[15:33] <seb128> Trevinho, oh, I overlooked that issue :/
[15:34] <Laney> mmm
[15:35] <Trevinho> seb128: for 14.04 there won't the the problem, since not exporting the hint will make us free to use the title-bar anyway with no troubles... But for U is different
[15:37] <seb128> Trevinho, indeed
[15:38] <seb128> Trevinho, the LTS also doesn't have apps using CSD
[15:38] <Trevinho> seb128: yes, not the main one,... but you know people will install from universe or with time passing, from ppa...
[15:38] <Laney> where does shell put it?
[15:39] <seb128> Trevinho, right, well that's the issue of those app writers and their users then
[15:39] <Laney> at the top always isn't it
[15:57] <Trevinho> Laney: by shell you mean unity? Becase if you use local menus, they will go into the app decoration itself...
[15:59] <Laney> Trevinho: I meant gnome-shell
[16:00] <Trevinho> Laney: ah, ok... that was my 1st guess, but then you mentioned "top", and you know... :)
[16:00] <Laney> :P
[16:06] <nessita> hello everyone! question, I'm running trusty will all updates installed, and the X is crashing a lot to me (not sure whether is X, unity or something else)
[16:06] <nessita> I thought nouveau drivers were the issue, so I installed nvidias, but I still get often X freezes and crashes
[16:06] <seb128> nessita, hey!
[16:07] <nessita> any recommended procedure to debug?
[16:07] <seb128> what happens exactly?
[16:07] <nessita> seb128, the X session freezes, but audio keeps going if I was listening to music, for example
[16:07] <nessita> I can not change to a text console
[16:08] <nessita> after 2 minutes, I get the lightdm screen again
[16:08] <seb128> no apport report?
[16:08] <nessita> when I re-login, I get the crash report window, I enter the root password and click on 'Yes' (willing to help)
[16:08] <seb128> could you send your Xorg.0.log(.old) after getting the issue?
[16:08] <nessita> seb128, but I never get a LP page opened
[16:08] <nessita> so I'm not sure which bug is this (if there is any)
[16:08] <seb128> right, reports are sent to errors.ubuntu.com on stable release
[16:09] <seb128> you can go to system-settings -> privacy, there is a link to your reports
[16:09] <nessita> ah!
[16:09] <nessita> checking
[16:09] <seb128> or you could look manually to the crash report
[16:10] <nessita> so I can not see my report, apparently, link is https://errors.ubuntu.com/oops/ad871aca-f245-11e3-9ffa-fa163e339c81
[16:10] <nessita> but I get "Sorry, you are not a member of a group that is allowed to see the data from error reports. Please fill out this form to request access."
[16:11] <nessita> the othe report I have is https://errors.ubuntu.com/oops/33c9fac2-f1a0-11e3-88c1-fa163e707a72
[16:13] <nessita> seb128, this is my /var/log/Xorg.0.log.old https://pastebin.canonical.com/111604/ (I just rebooted from a crash that never recover by itself)
[16:13] <nessita> I don't see any obvious error in there, though
[16:13] <nessita> seb128, can you see my reports?
[16:15] <seb128> yes
[16:15] <seb128> one is a systemd-logind/cgmanager one
[16:15] <seb128> the other one an Xorg one
[16:16] <nessita> so today I had a crash this morning, re-login, installed nvidia drivers and rebooted. Then I had another crash I just rebooted from, but I got no apport crash prompt
[16:16] <nessita> I had to hard-reboot
[16:16] <seb128> do you have any recent crash in /var/crash?
[16:16] <nessita> not even alt+sysrq was responding and CPU usage was super high
[16:16] <nessita> checking
[16:16] <seb128> seems like a kernel issue to me
[16:17] <seb128> it's weird in those cases that vt switch doesn't work
[16:17] <seb128> or sysrq
[16:17] <nessita> seb128, crashes from today are _lib_systemd_systemd-logind.0.crash and _lib_systemd_systemd-logind.0.upload only
[16:20] <seb128> nessita, your report matches https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1322679
[16:21] <seb128> nessita, some comment mentioning removing cgroup-lite or lxc to resolve the issue
[16:21] <seb128> stgraber is assigned to the bug
[16:21] <seb128> the assert are not the same on both bugs, not sure if they got wrongly duplicated or not
[16:21] <nessita> hum, my daily work depends on LXC
[16:21] <seb128> stgraber, ^ do you know if that's a correct duplicate?
[16:22] <seb128> nessita, that report might be another issue than your xorg one though
[16:22] <nessita> right, I was about to ask
[16:23] <seb128> the Xorg one seems to be in libexa.so but doesn't have debug infos
[16:23] <larsu> Trevinho, seb128: the application menu is merged with the menu bar when shelshowsappmenu is false
[16:23] <seb128> do you still have the report in /var/crash?
[16:23] <nessita> seb128, I haven't removed anything from there
[16:23] <nessita> also, grepping on older logs in /var/log, I see things like
[16:23] <nessita> /var/log/kern.log.1:3710:Jun  7 22:25:03 dali kernel: [38658.518253] compiz[9565]: segfault at 81dcec90 ip 00007f41ae7c6e56 sp 00007fff8b995d20 error 6 in libdrm_nouveau.so.2.0.0[7f41ae7c5000+5000]
[16:23] <seb128> larsu, that's a bit orthogonal to LIM relying on compiz decorations?
[16:24] <seb128> nessita, seems like that's yet another issue, in nouveau this time
[16:24] <nessita> seb128, right, but I switched to nvidia this morning and had a crash as well (of course I can not confirm is the same issue)
[16:24] <larsu> seb128: well, if LIM is enabled and we don't have compiz decorations (because of csd), then the app will get a traditional menu bar
[16:24] <larsu> which has the app menu merged with the win menu
[16:25] <seb128> larsu, is it?
[16:25] <seb128> or are we going to "eat" the menu
[16:25] <larsu> if we unset the xsettings, it is
[16:25] <seb128> but not have it render anywhere, because that particular window has no decoration
[16:25] <larsu> afaik
[16:25] <stgraber> seb128: it's probably the same issue, yes. We're yet to actually understand what the issue is though...
[16:25] <seb128> stgraber, ok, thanks, I just wanted to make sure the duplicate status is correct
[16:25] <larsu> seb128: no. GtkApplicationWindow inserts a menu into the window when ShellShowsMenubar is false
[16:26] <seb128> larsu, but are those settings by-app?
[16:26] <larsu> ah wait
[16:26] <larsu> right.
[16:26] <larsu> they aren't
[16:26] <larsu> so we'll eat the menus in that case :)
[16:26] <seb128> right
[16:26]  * larsu <-- a bit slow today apparently
[16:27] <seb128> blame the heat!
[16:27] <larsu> this is a weird edge case, because most applications using a header bar won't have a window menu
[16:27] <larsu> but might have an app menu, which can be displayed in the header bar, but again only when the xsetting is false
[16:28] <larsu> I hate LIM
[16:29] <nessita> seb128, I think the crash from this morning is related to nouveau indeed, my first freeze today matches this from the kernel log:
[16:29] <Laney> like add it to or create a gear menu in there?
[16:29] <nessita> Jun 12 11:34:26 dali kernel: [ 8609.142610] nouveau E[  PGRAPH][0000:01:00.0] DATA_ERROR INVALID_VALUE
[16:29] <nessita> Jun 12 11:34:26 dali kernel: [ 8609.142618] nouveau E[  PGRAPH][0000:01:00.0]  DATA_ERROR
[16:29] <nessita> Jun 12 11:34:26 dali kernel: [ 8609.142626] nouveau E[  PGRAPH][0000:01:00.0] ch 2 [0x001fb14000 Xorg[1559]] subc 2 class 0x502d mthd 0x0604 data 0x00104600
[16:29] <nessita> Jun 12 12:04:49 dali kernel: [10431.572929] nouveau E[Xorg[1559]] failed to idle channel 0xcccc0000 [Xorg[1559]]
[16:39] <nessita> stgraber, anything I can help regarding debugging? I'm hving crashes once a day approx (not completely sure is that exact issue though)
[16:39] <nessita> seb128, anything you need from my /var/crash?
[16:39] <seb128> nessita, clean it and ping me again next time you have a lock/issue/report, so we have a clean state to work on
[16:40] <seb128> nessita, the current situation is a bit of a mix and not easy to debug
[16:40] <nessita> seb128, ack!
[16:40] <nessita> seb128, confirm you want me to run sudo rm /var/crash/* ?
[16:41] <seb128> nessita, yes
[16:41] <seb128> Laney, your cinnamon upload is blocked in proposed because it wants cogl15 and we are on cogl20, could you have a look to it?
[16:42] <Laney> seb128: my upload?!?!?!?!?!">£K$?£K4w/r.s/fs
[16:42] <Laney> is it blocking $stuff?
[16:42] <seb128> Laney, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#cinnamon
[16:43] <Laney> wasn't that blocked manually?
[16:43] <seb128> Laney, https://launchpad.net/ubuntu/+source/cinnamon/1.7.4-2ubuntu6 has your name on it!
[16:43] <Laney> did it get fixed?
[16:43] <seb128> Laney, I removed the tag, it didn't seem to make sense
[16:43] <seb128> since that package is neither in trusty nor utopic
[16:43] <seb128> but the bug mentioned is an nvidia one, I don't have hardware to try
[16:45] <Laney> I'm not sure it's a great idea
[16:45] <Laney> this has rcbugs in Debian and isn't in testing
[16:45] <Laney> I think we want someone to merge 2.x
[16:48] <seb128> right, that sounds like a better idea indeed
[16:48] <Laney> I know people do want this in, but what it misses is someone looking after it
[16:48] <Laney> that's how it ended up out of the release
[16:49] <Laney> if we get that, great
[16:49] <Laney> hopefully it's syncable so that might just be a matter of watching bugs
[16:58] <seb128> right, I noticed it because it's showing on the update-excuses list
[16:58] <seb128> and it seemed desktopish
[16:58] <seb128> +1 if we can sync from Debian
[16:58] <seb128> it would make some happy users, without extra work from our side
[17:07] <Laney> okay, climbing time, see you!
[17:08] <seb128> Laney, have fun!
[23:31] <robert_ancell> RAOF, Was there a reason why XI2 wasn't a new extension? Seems kind of odd to completely replace all the requests of XI1 but still live in the same extension
[23:43] <RAOF> robert_ancell: Versioning makes it reasonable.
[23:43] <RAOF> robert_ancell: There's no reason a client should do both XI v1 and XI v2 at the same time, so...
[23:44] <RAOF> (Except, you know, toolkits)
[23:44] <robert_ancell> RAOF, obviously it works fine, but it means that you drag around the legacy of XI1 forever for no benefit
[23:45] <robert_ancell> Perhaps it was easier to implement in xorg that way since both extensions would use the same code
[23:45] <RAOF> XI1 was going to hang around forever anyway.
[23:45] <robert_ancell> really?
[23:46] <RAOF> I think there have been 2 extensions removed in the history of the X server?
[23:47] <robert_ancell_> I think I saw more than that, perhaps they weren't in xfree86/sorg