[07:21] <duflu> RAOF: EOD merge proposals then? :)
[07:21] <duflu> All the proposals
[09:21] <mlankhorst> duflu: you know the mesa side better right?
[09:22] <duflu> mlankhorst: Better than Android at least
[09:23] <mlankhorst> I'm playing around with XMir, and I have sw rendering working
[09:23] <mlankhorst> but my egl knowledge is lacking, how can I get glamor working, possibly with multiple windows? (in case of rootless xmir)
[09:25] <duflu> mlankhorst: I'm not sure it ever did. RAOF would know what's missing. I think something was
[09:25] <mlankhorst> was thinking of using some egl calls instead of raw mir in a couple of places
[09:26] <duflu> mlankhorst: Yes, Mir likes you to use egl
[09:27] <mlankhorst> oh.. some interacting with eglCreateWindowSurface might work
[09:27] <duflu> mlankhorst: Yeah see mir's examples/
[09:37] <anpok_> alan_g: are you currently working on exposing something like the fake-event-hub, for acceptance testing?
[09:38] <alan_g> anpok_: not currently - I was hoping you or racarr would get to it first.
[09:40] <duflu> alan_g: Is it intentional that Server does not have virtual methods? That's not what I thought it would be...
[09:40] <anpok_> duflu: for abi stability .. to have those as symbols
[09:40] <alan_g> duflu: it is intentional
[09:40] <anpok_> instead of table entries
[09:41] <duflu> alan_g: So a "Shell" would contain a "Server" then?
[09:41] <anpok_> ok.. just rememberd your recent change there and thought you might be starting something
[09:41] <duflu> I'm confused because Server has shell methods...
[09:41] <anpok_> alan_g: I am about to form a mir replacement of what EventHub does using the stuff RAOF added there
[09:42] <alan_g> duflu: yes, there's a spike here: https://code.launchpad.net/~alan-griffiths/qtmir/migrate-to-mir-Server-API/+merge/240451
[09:42] <alan_g> and here: https://code.launchpad.net/~alan-griffiths/unity-system-compositor/migrate-to-mir-Server-API/+merge/240566
[09:44] <duflu> alan_g: It might be more instructive for me to see how you convert demo-shell...?
[09:44] <duflu> If I wait for that instead of trying myself
[09:44] <alan_g> duflu: basic shell has been converted if that's of use
[09:45] <duflu> I think basic shell was too basic to answer my questions but will look again
[09:45] <alan_g> (And minimal, but that's not useful for this)
[09:46] <duflu> alan_g: I think I need to learn how your design protects the ABI first
[09:47] <alan_g> No vtab index changes, no implementation changes, fewer customization points
[09:47] <duflu> I do wonder if it's helpful that we distinguish between "shell" and "server". I think "shell" is just a server with customized behaviour
[09:51] <alan_g> Mir handles a number of concerns that are of no direct interest to the shell (IPC, graphics and input drivers, ...)
[09:51] <duflu> alan_g: Yeah I can see some line...
[09:53] <duflu> alan_g: Consider however Server.override_the_placement_strategy() -- it's a shell feature so if Shell can't inherit from Server then functions like that need to move into some generic Shell class instead
[09:54] <alan_g> I'm not following, can you give an example?
[09:56] <duflu> alan_g: "placement strategy" is a shell feature. It changes according to which shell you're using. So in the end I think placement behaviour needs to be a feature of a shell class, somewhere. The issue is you can't make a shell class that inherits from Server so it would have to contain a Server. But then you still have "placement strategy" in the server and not the shell
[09:56] <duflu> I think that feature is misplaced, and it's something I'm working on directly right now... so need to figure it out
[09:57] <duflu> Agreed however that most of Server is indeed server stuff and not shell
[09:58] <alan_g> You just have to tell the server which placement class to use
[09:59] <duflu> alan_g: I think you will find when there exists a Shell class separate to Server then the server no longer cares about placement strategy. It's entirely a shell concern
[09:59] <duflu> The server should send all policy queries (e.g. placement) to the shell to decide
[10:00] <duflu> alan_g: Maybe we need a function of Server to "set_shell(Shell ..)" to begin with?
[10:01] <alan_g> duflu: your saying all queries should be answered by one shell interface, what I see is have is specific queries being answered by specific shell interfaces.
[10:01] <duflu> alan_g: Absolutely, it scales better and fits peoples' mental models. Instantiating N different policy classes is a nightmare
[10:01] <duflu> I'm trying to improve on it
[10:02] <duflu> Also, what you think is PolicyX might need to talk to PolicyY and PolicyZ (e.g. state settings depend on current type)
[10:03] <duflu> So, one class can do that trivially with much less effort and coupling
[10:03] <alan_g> I disagree, but you can define your interface simply by subclassing all the existing ones
[10:03] <duflu> alan_g: I'm handwaiving again and it's after hours. I'll try and do a prototype and see if it improves things at all
[10:04]  * alan_g waves goodbye
[10:04] <alan_g> Have a good evening
[10:07] <duflu> alan_g: I think a good example to think about is how to eliminate the poorly-named "WindowManager" in demo-shell. I think that should just become a more capable "DemoShell" class
[10:07] <duflu> And then logical cleanups should follow
[10:12] <alan_g> anpok_: if you have a design that plays nicely with mir::Server that will help my migration task
[10:54] <anpok_> alan_g: not sure yet.. whether we want a testing-(input)platform with an interface to create fake devices and emit user input or just some sort of always available interface to inject devices and events..
[10:56] <alan_g> anpok_: we have more-or-less the same question with the graphics. The existing stub graphics platform doesn't (yet) allow customization for testing scenarios
[11:36] <mlankhorst> how much effort would be it to use client-side allocation for mir-mesa?
[11:57] <anpok_> u need that for glamor?
[12:28] <greyback> is there a mir_demo_client which prints out the frame rate any more?
[12:39] <mlankhorst> anpok_: hm I just found a way around it using some internal glamor copy thing
[12:39] <mlankhorst> but now I need the stride for the fd that was passed by mir
[12:41] <mlankhorst> oh oops, it exists ;P
[12:42] <mlankhorst> yay, glamory eyes that work
[12:44] <alf_> greyback: You can set MIR_CLIENT_PERF_REPORT=log for any client now
[12:44] <greyback> alf_: ah ok, thanks!
[12:48] <mlankhorst> yay, xeyes on glamor working \o/
[13:10] <alf_> mlankhorst: great!
[13:11] <anpok_> mlankhorst: yay for xeyes!
[13:16] <mlankhorst> I seem to get some minor visual glitches, not sure where they're coming from
[13:16] <mlankhorst> and they're probably gone if I invalidate the entire screen each time, looks like some stale damage :/
[14:43] <mlankhorst> alf_: you were the one that helped me debug nested mir right?
[14:47] <alf_> mlankhorst: could be, I don't remember
[14:55] <alf_> mlankhorst: Is there something I could help with?
[22:55] <Trevinho> robert_ancell: hi
[22:55] <robert_ancell> Trevinho, hi
[22:56] <Trevinho> robert_ancell: today I gave a look at the new gdkgl thing... and I've made an implementation for gdkmir...
[22:56] <robert_ancell> Trevinho, cool. I had a look yesterday too but it seemed non-trivial :)
[22:56] <Trevinho> robert_ancell: I've pushed it at https://github.com/3v1n0/gtk/compare/wip/mir-gdkgl for now, but I might move that to a new branch in git.gnome if you prefer...
[22:56] <Trevinho> robert_ancell: things work... *but*...
[22:57] <robert_ancell> It would be better in git.gnome.org as a wip/mir-gl
[22:57] <Trevinho> ok, cool
[22:57] <Trevinho> robert_ancell: as you can see http://people.ubuntu.com/~3v1n0/gdkgl-mir-ok.avi
[22:57] <Trevinho> it does the job
[22:57] <robert_ancell> Trevinho, nice work!
[22:58] <Trevinho> robert_ancell: thanks :).. but here (radeon) not when using eglSwapBuffersWithDamageEXT it has some problems
[22:58] <Trevinho> robert_ancell: see http://people.ubuntu.com/~3v1n0/gdkgl-mir-bad1.avi
[22:58] <Trevinho> robert_ancell: it's like there's a corruption somewhere
[22:59] <robert_ancell> You'll have to ask the Mir guys about that one
[22:59] <Trevinho> robert_ancell: yes, that's also why I'm here...
[22:59] <robert_ancell> RAOF, hah, timing!
[22:59] <Trevinho> RAOF: hi... (speaking of the devil...)
[22:59] <Trevinho> :D
 You'll have to ask the Mir guys about that one
 robert_ancell: yes, that's also why I'm here...
[23:00] <robert_ancell> --> RAOF<EMAIL_ADDRESS>has joined #ubuntu-mir
[23:00] <Trevinho> or maybe not :P
[23:01] <Trevinho> robert_ancell: anyway, how dow we want to track it? should I also open a bug on bugzilla?
[23:05] <Trevinho> robert_ancell_: also I pushed a backend for cogl, that should then make also clutter working (not sure what will be the future of these, but we still need them I guess)
[23:07]  * robert_ancell_ -> lunch, bbl
[23:28] <RAOF> robert_ancell, Trevinho: You rang?
[23:29] <Trevinho> RAOF: yep...
[23:29] <Trevinho> it's for this https://www.youtube.com/watch?v=xQyfvEvQ_G0
[23:30] <Trevinho> RAOF: that's gdkgl support in mir... I've been working on it few hours and got mostly working... But....
[23:31] <Trevinho> all you see there happens when using an eglSwapBuffer call... when instead using eglSwapBuffersWithDamage, I get some corruption (like you can see at http://people.ubuntu.com/~3v1n0/gdkgl-mir-bad1.avi)
[23:32] <Trevinho> RAOF: basically if this if: https://github.com/3v1n0/gtk/blob/wip/mir-gdkgl/gdk/mir/gdkmirglcontext.c#L146 is false it works, otherwise it seems that it swaps garbage...
[23:35] <RAOF> Hm. That .avi quite effectively freezes my session.
[23:35] <racarr> haha
[23:35] <Trevinho> RAOF: ops... try with vlc, or mplayer... mencoder did it
[23:36]  * RAOF suspects gstreamer's vaapi support; the intel drivers seem to be a bit flaky on Vivid.
[23:36] <RAOF> Trevinho: Anyway, while I think we implement SwapBuffersWithDamage we don't actually do anything with the damage.
[23:36] <RAOF> Ahem.
[23:36] <RAOF> DANCING MENUBAR!
[23:37] <RAOF> (Care of unity-panel-service bouncing, it seems)
[23:37]  * Trevinho might be involved on that as well :P
[23:38] <Trevinho> RAOF: mh, I'm not sure whether it's fully using it (it looked the case when I tried), but I've also made a cogl backend and it uses SwapBuffersWithDamage... And I didn't see these troubles
[23:41] <RAOF> Hm. That crazy vid looks like you're only drawing every second frame.
[23:42] <Trevinho> RAOF: yes,m it looks like that
[23:42] <Trevinho> RAOF: if you see http://people.ubuntu.com/~3v1n0/gdkgl-mir-bad2.avi
[23:42] <Trevinho> RAOF: there it's even different.. it only draws when something changes on the screen,
[23:43] <Trevinho> RAOF: you can't see the mouse cursor, but I was just moving the cursor over the gtk widgets to make them change state
[23:43] <Trevinho> and thus to make the ui redraw
[23:48] <RAOF> Hm.
[23:52] <Trevinho> RAOF: in some other cases it happens that the surface seems to swap between a the new state and a very old one... So, every few ms you see the old look of the window and then the new one... While the old one doesn't seem to update
[23:52] <Trevinho> (it's like the very first frame swapping with the new ones)
[23:53] <RAOF> Hm. Could you shoot me the code?
[23:53] <RAOF> I can have a look.
[23:54] <Trevinho> RAOF: ah you maybe misseed my link before... it's at https://github.com/3v1n0/gtk/blob/wip/mir-gdkgl/gdk/mir/gdkmirglcontext.c#L146
[23:54] <RAOF> I probably did; thanks to unstable session :)
[23:54] <Trevinho> no worries
[23:58] <racarr> transition scheme in place for event 2.0...semantics worked out for pointer ev v. touch event implementation of key event finished
[23:58] <racarr> think I am 4-5 hours of work from having the transition path to propose :)
[23:58] <racarr> but not today :(
[23:59] <Trevinho> RAOF: basically at the point I linked you, if using the simple eglBufferSwap works, but I'm not sure it's still perferct in terms of rendering


[01:27] <callmepk> goood morning
[01:59] <jamesh> hi callmepk
[02:01] <callmepk> hey jamesh
[03:02] <duflu> Oh hi callmepk and jamesh
[04:23] <callmepk> hey duflu
[07:00] <oSoMoN> good morning desktoppers
[07:07] <duflu> Morning oSoMoN
[07:07] <oSoMoN> good afternoon duflu
[07:13] <callmepk> morning oSoMoN
[07:20]  * duflu tries bisecting the kernel while also doing regular mutter work and suddenly needs a lot more CPU cores
[07:21] <oSoMoN> hey callmepk
[07:27] <seb128> goood morning desktopers
[07:30] <duflu> Morning seb128
[07:30] <seb128> hey duflu , how are you?
[07:30] <duflu> seb128, another sinus headache, another change in air pressure but otherwise good. You?
[07:31] <seb128> I'm fine, I mostly recovered from my stomach bug now
[07:32] <duflu> Sounds like good progress
[07:33] <oSoMoN> salut seb128
[07:47] <callmepk> morning seb128
[07:59] <didrocks> good morning
[08:01] <duflu> Hi didrocks
[08:03] <didrocks> good afternoon duflu
[08:33] <marcustomlinson> morning callmepk jamesh duflu oSoMoN seb128 didrocks999
[08:34] <duflu> Morning marcustomlinson
[08:36] <callmepk> morning marcustomlinson didrocks999
[08:57] <didrocks999> hey marcustomlinson, callmepk
[09:02] <Laney> ahoy
[09:02] <marcustomlinson> hey Laney
[09:08] <Laney> ^sup marcustomlinson
[09:08] <Laney> ^^^
[09:08] <Laney> ^^^^^^^^^
[09:09]  * cpaelzer hands Laney a few more ^ to use
[09:10] <Laney> thanks cpaelzer
[09:10] <Laney> was just typing them out in case my ^ key breaks and I need to have a few left around
[09:11] <cpaelzer> well corona-time, some gather piles of toilet pager others need some ^ in reserve :-)
[09:12] <seb128> hey marcustomlinson , Laney , callmepk
[09:12] <Laney> ah don't remind me of that, first day of the 'second lockdown' here in england today
[09:12] <Laney> sup seb128
[09:12] <seb128> sunny day today!
[09:13] <seb128> also I'm going to get some old fashioned today!
[09:13]  * seb128 got pointed to https://github.com/chrisglass/ubuntu-old-fashioned yesterday, sounds like what I needed for my ISO builds experiments
[09:14] <duflu> Morning Laney
[09:14] <seb128> collection of scripts to do ISO building locally the same way they are done in launchpad
[09:14] <seb128> you can even use multipass as a backend
[09:15] <callmepk> Morning Laney
[09:15] <Laney> hey duflu callmepk
[09:15] <Laney> seb128: what are you doing with iso builds?
[09:15] <Laney> I tried that script once, didn't make it work for me, maybe it changed since
[09:15] <seb128> Laney, trying to fix the canary build
[09:15] <Laney> don't think it had multipass back then even
[09:16] <Laney> huh
[09:16] <Laney> interesting
[09:16] <callmepk> that old fashioned repository is super helpful I have to say, used it to run test WSL and Hyper-V builds
[09:16] <seb128> Laney, we probably want that kind of image for the desktop installer refresh
[09:16] <seb128> Laney, no?
[09:16] <didrocks> hey seb128, Laney
[09:17] <Laney> ^hey didrocks
[09:17] <Laney> WHAT
[09:17] <seb128> mut didrocks!
[09:17] <Laney> where are these ^s coming from
[09:17] <seb128> spending the ones you collected earlier? :p
[09:17]  * didrocks feels ^^^^ a little bit too much :p
[09:17] <Laney> seb128: I guess we need *an* image there, dunno if that layer stuff was going to be used there, was that decided?
[09:17] <Laney> still having a target is nice
[09:18] <seb128> Laney, we need something that's compatible with the subiquity stack
[09:19] <seb128> it was made with that goal in mind and should fit what we need
[09:19] <seb128> anyway it's a v0.1 experiment to get started, we can iterate if needed
[09:21] <seb128> also people seemed ok with the idea but we don't have really experts on the images topic who were interested to give their input or telling us otherwise
[09:22] <seb128> anyyyway, I do plan to play with those scripts today and see if I can get that to work for me :)
[09:24] <Laney> ok, I guess I missed the chance to give input, would have asked this question then
[09:24] <Laney> good luck!
[13:53] <seb128> GunnarHj, the new issue you are commenting on the pango bug seems clearly a gtk one, I think it would make sense to open a new bug there for the segfault, that's a new problem introduced by the recent commit you cherrypicked
[13:54] <seb128> the assertion is from gtkfontchooserwidget
[13:54] <seb128> could be from pango where the code you mentioned is but then can reassign there is wanted
[14:42] <hellsworth> good morning desktopers
[14:42] <kenvandine> good morning
[14:42] <marcustomlinson> morning hellsworth and kenvandine
[14:42] <marcustomlinson> how's america doing today?
[14:43] <kenvandine> same as yesterday :)
[14:43] <hellsworth> waiting with bated breath..
[14:43] <kenvandine> still nervous :-D
[14:43] <hellsworth> very
[14:43] <marcustomlinson> i'm hardly as invested and the suspense is killing me
[14:44] <marcustomlinson> so I can only imagine
[14:44] <marcustomlinson> that came out wrong. I have invested interest in the good of mankind
[14:46] <ogra> marcustomlinson, the US is moving from MAGA to MAWA
[14:46] <ogra> (amke america wait again)
[14:46] <ogra> *make
[14:47] <ogra> (and after that hopefilly back to sanity)
[14:47] <marcustomlinson> well, hopefully indeed
[14:52] <oSoMoN> good morning hellsworth, kenvandine
[14:52] <hellsworth> hi oSoMoN (and marcustomlinson )
[14:52] <hellsworth> MAWA - haha well played ogra :)
[14:56] <ogra> 😄
[14:56] <oSoMoN> kenvandine, do you know what the status of the yaru SRU (the one that's blocking the gtk-common-themes update) is?
[14:58] <kenvandine> i'll ask
[15:01] <seb128> oSoMoN, kenvandine, Trevinho uploaded that to focal a while ago and it's waiting for review, seems like a case where you can nag SRU team. Though Frederik pinged yesterday to ask if we could include https://github.com/ubuntu/yaru/pull/2470 as well in the upload so I don't know if that's worth reuploading
[15:01] <gitbot> ubuntu issue (Pull request) 2470 in yaru "Focal groovy gtk theme button shadow sync" [Open]
[15:02] <seb128> Trevinho, ^
[15:02] <oSoMoN> thanks seb128
[15:02] <seb128> np!
[15:03] <Trevinho> yeah, taht should be included as well
[15:03] <seb128> I would say get another upload up and then we can nag the SRU team
[15:03] <Trevinho> ok
[15:03] <seb128> they always say they are fine being pinged about reviewing things people wait on
[15:10] <Trevinho> seb128: problem is still that yaru is blocked by the shell saga...
[15:10] <seb128> ah, I didn't know that, they need to go in sync?
[15:10] <seb128> we should get the shell unblocked...
[15:10] <Trevinho> seb128: i could revert changes and re-upload but that makes me sad
[15:10] <seb128> no, let's go forward
[15:11] <Trevinho> seb128: no there's no dependency actually
[15:11] <Trevinho> but yaru team decided that since we included upstream theme fixes, then....
[15:11] <Trevinho> it was considered as part of the gnome change and so blocked for now
[15:11] <seb128> wait?
[15:11] <Trevinho> even though such changes are independent by the code change
[15:12] <seb128> can the yaru SRU go before the shell one?
[15:12] <seb128> or would it create some visual problems?
[15:12] <Trevinho> no problem at all
[15:13] <Trevinho> those are the changes https://github.com/ubuntu/yaru/commit/02e00bed590562a8ec67beebfba782643f6ee93d
[15:14] <Trevinho> which will fix the visual issues even for previous shell versions, as they are unrelated to the logic changes in js
[15:14] <seb128> k, so why is it blocked on the shell to be sorted out?
[15:16] <Trevinho> seb128: well I assume because the changelog mentioned the same SRU bug...
[15:16] <Trevinho> seb128: I've uploaded that though
[15:17] <Trevinho> seb128: see the discussion here https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1896334
[15:17] <Trevinho> I think i explained that at the time
[15:17] <Trevinho> not sure the explaination that the changes are actually not connected was in a different discussion though
[15:19] <seb128> Trevinho, ah, do we need to mention the other SRU?
[15:19] <seb128> I didn't notice that
[15:20] <seb128> Trevinho, Robie wrote
[15:20] <seb128> 'I don't think it makes sense to proceed with yaru-theme either until this is resolved, since I understand that's based on the gnome-shell update that is not concluded yet.'
[15:20] <seb128> you didn't reply to say that was not true so he probably still assume that
[15:21] <Trevinho> well, at the time there was no much pressure in having yaru out... but I think we had a private conversation where i said that
[15:21] <seb128> k, so I think we want yaru unblock and shell moving but that could take a bit more work
[15:21] <seb128> what about you create another bug for yaru only that basically copy the one you just mentioned
[15:22] <seb128> so it's clear they don't need to go together
[15:22] <seb128> reference that in the changelog, include the new fix, upload
[15:22] <seb128> I will go handle the SRU team and getting things unblocked then
[15:23] <seb128> Trevinho, ah, you already reuploaded?
[15:23] <seb128> let me see if I can convince a SRU member to approve that
[15:23] <Trevinho> yeah, well I can do it again if you remove though
[15:27] <seb128> Trevinho, I tried to ping Robie as step 1, let's see
[15:27] <Trevinho> ok
[15:35] <tseliot> seb128, Wimpress  just FYI, I have just uploaded fixes for LP: #1872950 (for groovy and hirsute)
[15:37] <seb128> tseliot, ah great, thanks!
[15:37] <tseliot> yw
[15:38] <seb128> thanks for taking some time to fix that one despite being busy with other things
[15:39] <tseliot> :)
[15:39] <seb128> tseliot, I'm updating the 'regression potential' section if that's ok with you, SRU team expect 'what could regress' and not 'low' there and they started being more picky about it
[15:40] <tseliot> seb128, sure, thanks
[15:41] <seb128> np!
[15:43] <seb128> Laney, thanks for pushing forward with actual proposed changes on the SRU discussion!
[15:43] <Laney> np
[15:43] <seb128> I just crossed some cases of 'low' impact today
[15:46] <Laney> I think I saw it back when I wrote that stuff too
[15:46] <Laney> good job I had pushed it to Launchpad as I deleted the text on my computer 😬
[15:46] <Laney> need to stop working in ~/temp/
[16:07] <ricotz> hello desktopers
[16:08] <ricotz> please retry amd64 tests of liborcus https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#liborcus
[16:09] <seb128> ricotz, hey, done now
[16:09] <ricotz> and firebird3.0 https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#firebird3.0
[16:09] <ricotz> and xmlsec1 https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#xmlsec1
[16:09] <ricotz> seb128, ty
[16:10] <seb128> & the others
[16:13] <seb128> kenvandine, shouldn't the portal enablement have been automagic with gnome-3-34?
[16:13] <kenvandine> yes
[16:14] <kenvandine> seb128: why?
[16:15] <seb128> kenvandine, I modified thunderbird recent to set it remember?
[16:15] <kenvandine> oh, i thought that was to update it to gnome-3-34 from gnome-3-28
[16:16] <seb128> no, I added env: in the snapcraft
[16:16] <seb128> kenvandine, anyway, I think that's the issue/fix, https://github.com/snapcore/snapcraft/pull/3356/files
[16:16] <gitbot> snapcore issue (Pull request) 3356 in snapcraft "extensions: correctly spell the GTK_USE_PORTAL variable" [Open]
[16:16] <seb128> kenvandine, I just noticed when testing something else than GTK_USE_PORTAL and GTK_USE_PORTALS were set
[16:17] <seb128> using the right spelling should help :)
[16:17] <kenvandine> oh my!
[16:17] <seb128> right...
[16:18] <marcustomlinson> oh wow
[16:19] <marcustomlinson> good find seb128
[16:19] <seb128> :-)
[16:20] <seb128> kenvandine, also I guess I can delete the removable-media use from thunderbird if it uses portals?
[16:20] <kenvandine> yeah
[16:20] <kenvandine> in theory you can also remove home
[16:22] <seb128> in theory only? ;-)
[16:23] <marcustomlinson> all software is magic
[16:23] <seb128> I will try that locally first
[16:42] <seb128> hum, how do we handle things like bug #1902915 happening because the portal deb isn't installed? :/
[16:43] <seb128> I wonder if we should have a dbus api or something that suggest to install on demand when it's missing, was something like that ever discussed?
[17:00] <kenvandine> that's been seeded by default since 18.04
[17:00] <kenvandine> it would be nice to install on demand
[19:34] <seb128> kenvandine, sorry, was away for diner & co, it's seeded by only on Ubuntu, what if people install e.g xubuntu?


[11:53] <michagogo> Hey, could I perhaps get some attention to bug 1314616?
[11:54] <michagogo> (feel free to point me elsewhere if I'm asking in the wrong channel)
[13:14] <hggdh> michagogo: it is probable that you would get a better chance on #ubuntu-devel


[03:40] <Scary_Guy> Well the obvious answer is compile it from source and install manually.  But ain't nobody got time for that.
[13:31] <jrwren> openssl? lol.
[13:31] <jrwren> that means all the deps too, which is probably 90% of server repo :p
[13:44] <cmaloney> heh
[14:00] <Scary_Guy> I never said it'd be easy :P
[14:00] <Scary_Guy> May as well do Gentoo or Linux From Scratch at that point.
[14:15] <jrwren> LMAO.
[14:15] <jrwren> That would probably be a half years work in this environment.
[14:16] <jrwren> possibly more.
[14:16] <jrwren> actually... no... not that much. I wouldn't have to do the whole environment.
[14:17] <jrwren> but can't do either of those. AWS CloudHSM supported environment is one of the requirements in this case.
[14:50] <cmaloney> Unrelated: I really, really hate the new Ubuntu logo
[14:50] <cmaloney> it looks like a shitty piercing.
[14:52] <cmaloney> jrwren: I just said that this bug affects me too, so it's now "Confirmed"
[15:17] <Scary_Guy> First I've heard of it, and it does look like a horrible piece of jewelry.
[15:18] <Scary_Guy> I wonder how much they paid for it.
[15:36] <cmaloney> Too much
[15:44] <Scary_Guy> Well that part was obvious :P
[15:45] <greg-g> cmaloney: hah, I think I dated a person with that piercing :)
[18:07] <jrwren> thanks cmaloney
[18:07] <jrwren> and noow it is closed, because I can't read ;;)
[18:08] <jrwren> still, i feel like that was a good exercise and does point to a whole in the entire patching process.
[18:09] <jrwren> or whole in the docs/changelog IMO
[18:18] <Scary_Guy> hole*  You really can't read can you?   I read that whole, and it looked wrong and then I thought no, that is right.
[18:26] <jrwren> TY for correcting me. I hate getting homonyms wrong.
[23:35] <soundlogic> good evenin michiganders


[01:52] <happyaron> JackYu: ping
[01:54] <JackYu> hapyyaron, pong
[06:58] <didrocks> hey robru, still around to update me on the Unity8/Upstart app launch things?
[06:59] <robru> didrocks, haha. so mirv filed a bug about upstart, and unity8 never landed due to merge conflicts in trunk.
[07:00] <robru> didrocks, also i had a power outage here and it resulted in corruption on my boot drive, so I've spent most of the day reinstalling and recovering my system :-/
[07:01] <didrocks> robru: argh, I hope you can recover :/
[07:01] <didrocks> robru: what's this merge conflicts in trunk? This is for the branch we are waiting on landing?
[07:01] <robru> didrocks, almost there...
[07:02] <didrocks> robru: also, having a link to this branch we wait on for releasing would be appreciated ;)
[07:02] <robru> didrocks, yeah, sil told me the MP that we should watch, and I saw it get approved, and then jenkins failed to merge it due to flaky tests, so I went for a manual merge and there were conflicts, it wouldn't merge after that. I told them on the MP to rebase on trunk
[07:02] <didrocks> making sense
[07:02] <robru> didrocks, https://code.launchpad.net/~aacid/unity8/broken_collapse/+merge/197844
[07:03] <didrocks> robru: excellent thanks!
[07:03] <didrocks> robru: btw, do not add any other landing please until we promote an image
[07:03] <didrocks> especially risky ones like ubuntu-ui-toolkit
[07:03] <robru> didrocks, they told me it fixed test failures ;-)
[07:03] <didrocks> we want to be able to go back to a good state before putting cracks in
[07:03] <didrocks> robru: yeah, fixes and regressions :p
[07:03] <didrocks> (potential at least)
[07:04] <didrocks> apart if they only touch codes in tests/
[07:04] <robru> didrocks, ok, please let t1mp know that you veto'd it, since I already said i would do it
[07:04] <didrocks> robru: will do
[07:04] <didrocks> yeah, look at trunk
[07:04] <didrocks> quite a lot of changes
[07:05] <didrocks> let's hope we can promote an image today
[07:21] <robru> didrocks, ahhhhh, I need the VPN details. is there a wiki for that somewhere?
[07:34] <didrocks> robru: hum, I think I sent an email about that 3 weeks ago :)
[07:35] <didrocks> robru: sent
[07:35] <didrocks> robru: I hope you recovered your emails
[07:36] <robru> didrocks, emails? those are all in gmail!
[07:36] <robru> the cloud is great ;-)
[07:36] <robru> didrocks, yeah, personal files were well backed up, but I lost the system partition, so things like vpn config tokens are gone
[07:40] <didrocks> robru: oh, mine in my ~ dir
[07:41] <didrocks> thanks for network-manager
[07:41] <didrocks> to*
[07:41] <robru> didrocks, where does it hide? i was using network manager...
[07:42] <didrocks> robru: IIRC, it's in gsettings
[07:43] <robru> didrocks, how do I extract gsettings from a not-running user directory? ~/.local where?
[07:43] <didrocks> robru: hum, forget about it? I don't find them in a dconf dump
[07:45] <robru> didrocks, anyways, it's midnight. i'll get back on the VPN tomorrow
[07:45] <didrocks> yep, sounds better :)
[09:02] <seb128> good morning desktopers
[09:02] <seb128> happy friday!
[09:03] <Laney> hey!
[09:03] <Laney> xnox: w o w !
[09:03] <seb128> Laney, hey, how are you?
[09:03] <pitti> bonjour seb128, hey Laney
[09:03] <seb128> pitti, salut, ça va ?
[09:03] <Laney> hey seb128 pitti
[09:03] <pitti> ça va bien !
[09:03] <Laney> pretty decent, glad that it's friday :-)
[09:03] <seb128> Laney, congrats on defeating webkitgtk
[09:04] <Laney> crazy eh?
[09:04] <seb128> ;-)
[09:04] <Laney> just have to test build every future upload on 4 arches from now on
[09:04] <seb128> I'm surprised you didn't go "I never want to upload webkit ever again"
[09:05] <Laney> there is that
[09:05] <seb128> ;-)
[09:06] <larsu> Laney: I don't even think we need it much longer. The web seems to be a passing fad
[09:06] <Laney> port all to oxide
[09:06] <Laney> then deprecate webkitgtk and let attente maintain it
[09:06] <seb128> you guys are just mean to attente!
[09:06] <larsu> attente already had his troll friday last night
[09:06] <seb128> oh, wait, it's friday
[09:06] <seb128> ok then
[09:06] <larsu> haha
[09:07] <larsu> I thought you redeclared them to learn-something-Fridays?
[09:07] <larsu> I guess we all learned how much we like trolling...
[09:07] <seb128> lol, indeed
[09:07] <seb128> larsu, btw, gtk 3.10.6 in the ppa, seems to work fine there
[09:08] <seb128> I'm pondering uploading to trusty today or give it the W.E and upload on monday
[09:09] <larsu> give it the weekend, please :)
[09:09] <Laney> oh, invisible cursor
[09:09] <seb128> k
[09:09] <Laney> haven't had that bug in a couple of weeks :P
[09:09]  * larsu doesn't want to wake up to angry emails on Saturday
[09:09] <seb128> Laney, :-(
[09:09] <seb128> Laney, when did you last update/restart xorg? is that happening at boot/login?
[09:09] <Laney> i just turned it on today
[09:09] <Laney> and after starting the session, don't know if it was there on the greeter
[09:09] <seb128> is that current trusty?
[09:10] <Laney> ish
[09:10] <seb128> no ish
[09:10] <Laney> I think I dist-upgraded yesterday
[09:10] <Laney> not today
[09:10] <seb128> Laney, https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1238410
[09:10] <ubot2`> Launchpad bug 1238410 in X.Org X server "Inconsistent cursor visibility with cursor plugin enabled" [Medium,In progress]
[09:10] <seb128> Laney, it was supposed to be fixed with xorg's update on wednesday
[09:10] <seb128> Laney, can you make sure if you have that version or not?
[09:10] <Laney> xorg-server?
[09:10] <seb128> see comment 24
[09:10] <seb128> on that bug
[09:11] <Laney> ok /me looks
[09:12] <Laney> ah
[09:12] <Laney>   Installed: 2:1.14.3-5ubuntu1
[09:12] <Laney>   Candidate: 2:1.14.4-1ubuntu1
[09:13] <ali1234> tedg: what do we need to do in xfce4-indicator-plugin to handle upstart indicator activation?
[09:13] <ali1234> just system("init ..."); ?
[09:13] <seb128> Laney, I prefer that ;-)
[09:13] <tedg> ali1234, Yeah, did you see the commit to unity-greeter?
[09:13] <ali1234> tedg: yes
[09:13] <Laney> indeed
[09:13] <tedg> ali1234, I think that's the best way.
[09:14] <ali1234> i guess i need to use something that doesn't wait for the process to finish, ie fork()
[09:14] <tedg> ali1234, Though, I'd really recommend switch XFCE over to Upstart User Sessions :-)
[09:14] <ali1234> xubuntu uses upstart
[09:15] <tedg> System session, probably not user session.
[09:15] <ali1234> it uses upstart for the user session
[09:15] <tedg> Really?
[09:15] <ali1234> yes really. we had to get it fixed
[09:15] <tedg> Cool.  Then you shouldn't need to do anything.
[09:15] <ali1234> well, ok then, your new indicators are broken :(
[09:15] <tedg> Oh, you need to emit that event.
[09:15] <ali1234> half the time they don't load up
[09:16] <tedg> So just a "initctl emit-event indicator-service-start"
[09:16] <ali1234> hmm.
[09:16] <tedg> So just a "initctl emit-event indicator-services-start"
[09:16] <tedg> (notice typo in first one)
[09:18] <ali1234> assuming you meant initctl emit
[09:18] <ali1234> is that command supposed to hang forever?
[09:18] <tedg> Yes, sorry it's early :-)
[09:18] <tedg> Shouldn't be forever...
[09:18] <ali1234> oh i see... i already had run the command that starts the job direct
[09:18] <tedg> You can use --no-wait if you want it exit right away.
[09:19] <ali1234> ok. so what should emit this event?
[09:19] <ali1234> the indicator plugin? or something earlier in the session startup?
[09:19] <seb128> Laney, why did you put a block on webkitgtk again? (did I ask before?)
[09:19] <Laney> just to test it
[09:19] <Laney> I'll remove it shortly
[09:19] <seb128> ok
[09:20] <Laney> then start on the g-o-a transition
[09:20] <seb128> \o/
[09:22] <tedg> ali1234, I'd say the indicator plugin, then you can emit the end as well to manage the full lifecycle if it gets added or removed.
[09:24] <ali1234> tedg: ok, thanks.
[09:26] <Laney> oh come on
[09:27] <seb128> Laney, don't tell me that webkit is buggy
[09:27] <Laney> no
[09:27] <Laney> my session won't open
[09:27] <seb128> won't open?
[09:27] <seb128> do you need help debugging?
[09:27] <Laney> greeter goes away, hangs
[09:27] <Laney> well, not hang, but no compiz
[09:28] <Laney> sec, checking logs
[09:28] <seb128> no compiz or no unity?
[09:28] <Laney> both
[09:28] <seb128> hum
[09:33] <Laney> I've got various things like this in logs: (gnome-settings-daemon:3897): Gdk-WARNING **: gnome-settings-daemon: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
[09:33] <ali1234> silly question, but is your hard drive full?
[09:34] <Laney> /dev/sda5       120G  102G   13G  90% /
[09:37] <seb128> Laney, what do you have in your gnome-session.log ?
[09:37] <seb128> Laney, those seems like xorg is closing/have an issue
[09:37] <Laney> a load of those
[09:38] <seb128> does it work to start a guest session?
[09:39] <Laney> no, it's the same
[09:40] <seb128> using nouveau?
[09:40] <Laney> yeah
[09:40] <seb128> well, you can try to ruling out lightdm by going to a vt and do startx : --1 or something
[09:51] <asac> hey ho ... my trusty desktop system just came to stall (no mouse/keyboard input for 20+ seconds) with oneconf-service and x*apt-something looping at 100% at the same time
[09:52] <asac> maybe there is an unfortunate timed cron job that kicks both at the same time?
[09:53] <ogra_> it is just not storm safe
[09:53] <ogra_> check the ropes ;)
[09:53] <seb128> asac, I'm not sure they are croned, they might just react to apt index changes, didrocks probably knows since he wrote oneconf
[09:54] <seb128> ogra_, do you still get s-c to hit that Xerror?
[09:54] <ogra_> seb128, dunno, will test when i'm at the machine
[09:54] <ogra_> (and report back)
[09:54] <seb128> ogra_, thanks (could use debug infos from somebody having the issue)
[09:54] <ogra_> yup
[09:59] <didrocks> they aren't cronned but trigger by dpkg
[09:59] <didrocks> well for oneconf at least
[10:04] <seb128> Laney, did you figure it out?
[10:05] <Laney> no :(
[10:05] <seb128> is startx working?
[10:10] <Laney> It waits for ages and eventually I get a timeout locking .Xauthority
[10:10] <Laney> even if I rm it beforehand
[10:16] <ali1234> tedg: the indicator services don't start up fast enough and i just get an empty panel
[10:22] <tedg> ali1234, Hmm, but they do start?
[10:22] <ali1234> yes
[10:22] <tedg> ali1234, Do you then populate as they come up?
[10:22] <ali1234> no
[10:23] <tedg> ali1234, Are you using the libindicator code?  I thought it handled that.
[10:23] <ali1234> libindicator3, yes
[10:24] <ali1234> it doesn't handle it
[10:25] <ali1234> i'm building with a long delay to see what happens
[10:25] <tedg> K
[10:33] <ali1234> tedg: i see what is happening
[10:34] <ali1234> when it runs "initctl emit indicator-service-start" it hangs, because the service is already running for some reason
[11:00] <ali1234> tedg: libappindicator is falling back to systray for no good reason
[11:05] <Laney> larsu: http://ubuntuone.com/1GS1IppvwNFus6HMOZEXeA ← see the white bars on the toolbar - is that a gtk / theme problem?
[11:08] <ali1234> http://bazaar.launchpad.net/~ted/indicator-application/upstart-job/revision/245
[11:10] <ali1234> tedg: you just broke appindicators for gnome-panel and xubuntu
[11:13] <tedg> ali1234, That's just application indicators, but I expected those folks to use the XDG autostart file.  Happy to change it around.
[11:14] <ali1234> xdg-autostart doesn't work for appindicator-service
[11:14] <ali1234> it immediately exits if nothing is using it
[11:14] <ali1234> actually, i don't see how it can work with upstart either
[11:14] <ali1234> at the very least there's a nasty race condition
[11:17] <ali1234> my logs are full of "service respawning" spam because of this shutdown-if-nothing-is-using-me functionality
[11:17] <ali1234> this is probably why they only load up half of the time too
[11:18] <ali1234> also the indicator-services-end signal doesn't appear to do anything
[11:20] <tedg> Yeah, probably removing those timeouts makes sense now that they're managed by the session management.
[11:20] <ali1234> sometimes they get killed because of respawning too fast
[11:21] <ali1234> i'm not sure if xubuntu is using upstart or xdg-autostart to start these services, but all i know is that half of them are already loaded when i log in, sending the startup event hangs initctl, and appindicator-service is impossible to start or use in any way
[11:21] <larsu> Laney: looks like it, yes. Which version of epiphany is that?
[11:22] <Laney> larsu: it's epiphany-browser 3.8.2-4ubuntu1 from trusty-proposed
[11:22] <larsu> ah okay, that's why I'm not seeing that yet
[11:22] <Laney> just about to unblock webkit, so you'll get it soon :P
[11:23] <larsu> yay
[11:23] <larsu> I'll have a look into that, then. Thanks for pointing it out
[11:23] <Laney> yw
[11:23] <seb128> Laney, you really use web from browsing?
[11:23] <seb128> or did you just test webkit?
[11:23] <Laney> EPARSE
[11:23] <seb128> web = epiphany
[11:23] <Laney> was just to test webkit
[11:23] <Laney> s/from/for/
[11:23] <seb128> oh, right
[11:24] <seb128> do you need extra testers for webkit?
[11:24] <seb128> did you figure out your login issues btw?
[11:24] <Laney> yeah, was a non-executable file which broke an upstart job that blocked the session login
[11:25] <seb128> shrug
[11:25] <seb128> that seems like unreliability
[11:26] <Laney> the design of upstart allows any job to block any other job
[11:26] <Laney> so you'll get things like this, unfortunately
[11:26] <Laney> I'm sure there could be better troubleshooting though
[11:27] <seb128> fair enough, and the real issue seems like your -x file
[11:27] <Laney> yes, I uploaded a fix for that
[11:27] <Laney> you could have like upstart watching for failed job starts or something
[11:28] <Laney> or unity not coming up, and dumping its state to errors
[11:28] <seb128> right
[11:30] <ali1234> tedg: via use of INDICATOR_ALLOW_NO_WATCHERS env var, i was able to make the service work properly
[11:30] <Laney> feel free to bash on webkit but I'm going to unblock it anyway; can fix stuff in release :P
[11:30] <Laney> also, src:webkit can be removed now
[11:30] <tedg> ali1234, Great, that makes sense.  Makes more sense to do it that way.
[11:30] <Laney> well, once it migrates
[11:32] <ali1234> and luckily this timeout is implemented in libindicator3, so it only has to be removed in one place for all of them :)
[11:35] <ogra_> uhm ... so after todays upgrade evolution goes constantly to 100% CPu usage :(
[11:46] <pitti> seb128: FYI, bug 1258458 is a dupe, fixed already two weeks ago
[11:46] <ubot2`> Launchpad bug 1252305 in apport (Ubuntu) "duplicate for #1258458 dpkg-divert not found" [Critical,Fix released] https://launchpad.net/bugs/1252305
[11:47] <pitti> people ought to upgrade their trusty a bit more often :)
[11:57] <seb128> pitti, thanks, we should also block reports from outdated systems (same way apport is doing it)
[11:57] <seb128> ogra_, weird, we didn't change a lot yesterday
[11:57] <seb128> ogra_, what did you get in your round of upgrades?
[11:57] <ogra_> glib perhaps ?
[11:58] <ali1234> Laney: if you put INDICATOR_ALLOW_NO_WATCHERS=yes in /etc/environment this may provide a temporary workaround for missing indicators
[11:58] <ogra_> though the changes dont look like they could cause issues
[11:58] <seb128> I doubt it
[11:58] <seb128> that's only adding some python debug stuff
[11:58] <ogra_> right
[11:58] <seb128> did you get the new webkit?
[11:58] <Laney> ali1234: cheers
[11:58] <ogra_> is it in the archive ? then i should have gotten it
[11:59] <Laney> are you going to do a MP to remove the check?
[11:59] <ogra_> with the new update manager it is really hard to say what i got
[11:59] <ali1234> Laney: yes
[11:59] <Laney> look in /var/log/dpkg.log
[11:59] <ogra_> the list of stuff is completely useless
[11:59] <Laney> webkit migrated about 2 minutes before you mentioned the issue
[12:00] <Laney> so i doubt you have that, unless you're running proposed
[12:00]  * ogra_ wonders why we show the list at all ... it doesnt really help anymore they way it is
[12:00] <seb128> ogra_, what list?
[12:01] <ogra_> seb128, update-manager
[12:01] <seb128> why is it not useful?
[12:02] <pitti> seb128: yeah, except that whoopsie circumvents that check
[12:02] <seb128> pitti, I wonder if that's a good idea...
[12:02] <ogra_> because it uses weird cryptic package descriptions i would have to decypher first before knowing what i get
[12:02] <seb128> ogra_, we need to put better descriptions in our control files then...
[12:03] <Laney> well... we're asking him for the name of the software
[12:03] <ogra_> the description doesnt say something like "webkit foo bar baz" .... but says "very fast html rendering engine"
[12:04] <ogra_> thats absolutely not helpful without the exact package name ...
[12:04] <ogra_> (i'm making up the texts, just an example)
[12:04] <seb128> you are too technical, that tools is aiming at being user friendly
[12:04] <ogra_> well
[12:05] <ogra_> my mom wouldnt bother ...
[12:05] <ogra_> i wouldnt show that list at all
[12:05] <seb128> the intend is to list end user applications in the main list
[12:05] <seb128> with their icon
[12:05] <seb128> that works quite well
[12:06] <seb128> the technical items are under base OS
[12:06] <ogra_> for the tree apps that get updated along the 200 other packages, yes
[12:06] <ogra_> *three
[12:06] <ogra_> so just show apps with .desktop files or so
[12:07] <ogra_> i think what we show now is confusing
[12:09] <ogra_> btw, no webkit in dpkg.log
[12:09] <seb128> k
[12:09] <seb128> and you can reproduce the bug after restarting evo?
[12:13] <seb128> ogra_, http://ubuntuone.com/32sd5Xmv7NIgIry7ESlXir
[12:13] <seb128> ogra_, that looks a fine list to me...
[12:14] <seb128> ogra_, the security view is a bit weird, on a normal upgrade you would have the technical items under "Ubuntu base"
[12:15] <seb128> but the top of the list is nice, archive manager, desktop sharing, firefox web browser, etc
[12:15] <seb128> those are quite useful descriptions/items
[12:17] <Sweetshark> seb128: https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-quantaltest-20120601/+build/5306216 :(
[12:18] <Sweetshark> seb128: I updated the mdds version to the latest upstream, still happens on the trusty toolchain. I gotta check updating to the latest LO41 is of help otherwise it means digging deeper.
[12:18] <seb128> Sweetshark, can we just build with gcc-4.7 or something?
[12:19] <Sweetshark> seb128: hmm, good point.
[12:19] <Sweetshark> seb128: Ill try.
[12:19] <seb128> Sweetshark, thanks
[12:23] <ogra_> seb128, yes, the top looks fine ... further down not so much ... i would exclude libs and all
[12:25] <ali1234> how do i build libindicator from bzr into a package? http://paste.ubuntu.com/6529519/
[12:32] <seb128> bah, webkit
[12:33] <seb128> dbg = 350M, installed 1.5G
[12:40] <seb128> qengho, hey
[12:40] <seb128> qengho, do you have any news about the autopkgtest blocking chromium in trusty-proposed?
[12:58] <Laney> ali1234: how did you invoke the build?
[12:58] <ali1234> "debuild"
[12:58] <Laney> use bzr bd from bzr-builddeb
[12:59] <ali1234> do i have to commit changes for that to work?
[12:59] <Laney> no, but you have to bzr add new files
[13:00] <ali1234> noted, thanks
[14:05] <desrt> hihi, peeps
[14:20] <seb128> desrt, hey, happy friday!
[14:21] <seb128> Laney, so, I need to do a webkit upload, anything you wanted added there?
[14:24] <desrt> holy crap.  it's friday!
[14:25] <seb128> yeah, a good friday so far
[14:25] <JackYu> :)
[14:25] <seb128> Laney even managed to finally get webkit to build on all archs, including arm*
[14:25] <desrt> building webkit on arm?
[14:26] <JackYu> I'm in the night of Friday...
[14:26] <seb128> JackYu, you shouldn't be on the computer, that's not what friday nights are for!
[14:27] <desrt> ...says seb, who will be here 8 hours from now
[14:27] <JackYu> seb128, that's right. I will go to bed soon:)
[14:28] <larsu> desrt: morning! Should g_settings_get() disallow non-copying format strings? It calls g_variant_unref() after all
[14:28] <larsu> or is that a non-issue with all backends?
[14:28] <desrt> larsu: it's a very complicated question, to which the answer is "yes"
[14:28] <larsu> I find the question quite simple. Patch welcome?
[14:29] <desrt> yes please
[14:29] <desrt> the question is complicated by a few things
[14:29] <larsu> okay. This will break at least evince
[14:29] <desrt> because all backends do in fact support this
[14:29] <desrt> but only 99% of the time
[14:29] <larsu> hm?
[14:29] <desrt> if the gvdb gets replaced and reopened then your string could disappear under you if you unreffed the gvariant
[14:30] <larsu> which happens on writes, doesn't it?
[14:30] <desrt> yup
[14:30] <desrt> which don't happen 99% of the time
[14:30] <desrt> also: you have to do another read on the client side as well
[14:30] <desrt> because that's when it checks for the gvdb needing to be reopened
[14:30] <desrt> in theory it's possible to ensure that this isn't happening in your process
[14:30] <larsu> g_settings_get (settings, "&s", &str); g_settings_set (settings, whatever, bar); /* str is dangling */
[14:30] <desrt> in practice... threads, etc...
[14:30] <larsu> correct? ^
[14:31] <desrt> no.  in this case str would still be OK
[14:31] <larsu> why? Because you still have the old mmap even though the file link is gone`
[14:31] <desrt> yes
[14:31] <desrt> you have still mmaped the unlinked database
[14:31] <larsu> interesting
[14:31] <desrt> so the pointer is still good
[14:31] <desrt> as i said -- it's complicated
[14:31] <desrt> but i agree with your original idea to limit it
[14:31] <larsu> but best avoided...
[14:31] <desrt> yup
[14:32] <larsu> I mean, you can always get 0-copy with g_settings_get_value()
[14:32] <desrt> the other complicating factor: the API for checking format strings for copy-only was added long after g_settings_get()
[14:32] <desrt> precisely.
[14:32] <larsu> I know, I remember when you added it
[14:32] <desrt> also: if you're storing something for which you care about zero-copy in gsettings then you're doing it wrong
[14:32] <larsu> I came across someone doing it today, which is why I started wondering
[14:33] <desrt> ya... so this is an API break
[14:33] <desrt> i recommend doing two patches... first one should throw a critical but not return
[14:33] <larsu> didn't bother you in gmenumodel...
[14:33] <larsu> (same api break)
[14:33] <Laney> seb128: what do you want to upload it for?
[14:33] <Laney> but no
[14:33] <desrt> gmenumodel was very new when i made this break
[14:33] <desrt> gsettings is very old
[14:33] <larsu> fair enough
[14:34] <larsu> I'll do a critical first
[14:34] <larsu> with a note that this won't work much longer :D
[14:34] <desrt> party
[14:34] <larsu> party?
[14:35] <desrt> instead of saying 'awesome' or some other word
[14:35] <larsu> you and your Canadian slang!
[14:35]  * desrt discovers the hard way that bijiben's owncloud notes storage backend is ... unreliable
[14:36] <desrt> "oh... look at all of these text files in my homedir containing useful information... i should turn those into bijiben notes"
[14:36] <desrt> "okay... now i can delete the originals..."
[14:36] <larsu> it does that?!
[14:36] <desrt> larsu: no.  i did that.
[14:36] <larsu> ah. lol.
[14:36] <larsu> I mean, sorry for your data
[14:36] <desrt> "hm.  let's open this again.... hey.... why is this empty?"
[14:37] <desrt> larsu: don't be sorry for me.  mterry is on my side.
[14:37] <Laney> there's a new tomboy?
[14:37] <desrt> Laney: ish?
[14:37] <larsu> Laney: yes, but it destroys your data
[14:37] <desrt> the local storage backend is working nicely, fwiw
[14:37] <desrt> but uh... owncloud... ya
[14:37] <desrt> don't use that :)
[14:38] <Laney> canonical destroyed my tomboy notes too, don't worry
[14:38] <desrt> Laney: it's actually kinda nice.  it looks attractive and is integrated with gnome-shell search
[14:38] <larsu> the reason I went back to editing notes with vi ^^
[14:38] <desrt> (full text)
[14:38] <seb128> Laney, I've been getting debug infos and pinging people about that software-center Xerror that tops e.u.c since raring and Company has a tentative fix
[14:38] <Laney> ok, well I'd rather you get confirmation in a ppa
[14:39] <Sweetshark> anyone having seen stuff like this (on trusty): http://pastebin.com/x4qyVXsD ?
[14:39] <seb128> Laney, are you able to reproduce?
[14:39] <Laney> no
[14:39] <seb128> Laney, I was going to get confirmation through e.u.c stats
[14:39] <Laney> we know a german man who can though
[14:39] <Laney> at least judging by the frequency he complains about it
[14:39] <larsu> desrt: the faux ruled paper is a bit annoying
[14:39] <seb128> ok; let me throw it in a ppa then
[14:39] <desrt> larsu: i actually like that
[14:40] <Laney> i like that fix
[14:40] <seb128> me too ;-)
[14:40] <Laney> there should be a new point release along shortly so we might not need to upload explicitly for it anwyay
[14:40]  * desrt likes dejadup for pulling his ass from the fire once again
[14:40] <Laney> but good to know if it works
[14:40] <seb128> Laney, I really want to SRU that though
[14:40] <seb128> let's go through ppa
[14:40] <Laney> yeah you can do that
[14:42] <larsu> desrt: so g_variant_check_format_string() spews a critical itself, but only for one case
[14:43] <larsu> (when the string contains a & and copy-only is TRUE)
[14:43] <desrt> larsu: sounds fine... critical is totally appropriate here
[14:43] <desrt> just don't bail out of g_settings_get() because of it
[14:43] <desrt> i'd watch for the check() function returning false, and in that case issue -another- critical about "tried to read key 'xyz' from schema 'abc'"
[14:43] <larsu> desrt: I'm okay with that. I just don't like that it does a critical for _one_ case
[14:44] <desrt> to make it very easy to find
[14:44] <desrt> larsu: that does seem odd.  let me look.
[14:44] <larsu> ya, that's what I'm doing
[14:44] <larsu> also, "for the love of all that is good, please don't mark this string for translation..."
[14:44] <desrt> :)
[14:44] <desrt> can you understand why?
[14:45] <larsu> because it's non-trivial to explain correctly?
[14:45] <mterry> desrt, yay!  glad DD worked.  all I ever see is the bugs when it doesn't  :)
[14:45] <desrt> because, as a new translator, i have new appreciation for the pain that translators feel when faced with these kinds of messages
[14:46] <desrt> mterry: the 'restore old version' item in the rightclick menu in nautilus is totally great
[14:46] <larsu> mterry: if that's the case let me add myself publically to the "happy users" list
[14:46] <mterry> desrt, you lost the files outright, eh?  Have you tried the 'restore missing files' option?  It's magic
[14:47] <desrt> mterry: i just noticed that this was added
[14:47] <desrt> was about to complain about how i have to touch the file back into existence
[14:47] <desrt> when did this show up?
[14:47] <mterry> desrt, it's been there a year+ at least
[14:47] <desrt> that's pretty great
[14:47] <mterry> desrt, was a summer of code thing from a 2 years ago maybe
[14:47] <desrt> this is massive win
[14:48] <mterry> larsu, awesome  :)
[14:48] <desrt> mterry: slightly annoying at the same time, though
[14:48] <desrt> mterry: i can't select a file from the list to restore until the scanning is done
[14:48] <desrt> even though the list populates itself as it goes
[14:49] <mterry> desrt, hmm, fair
[14:49] <mterry> it also needs a sweep with the pretty brush
[14:49] <desrt> larsu: so the reason it throws a critical there is because this case is a programmer error
[14:50] <desrt> larsu: the other cases (unexpected type of GVariant shows up) are errors that originate from outside of the program
[14:50] <larsu> desrt: good point. Thanks.
[14:50] <larsu> desrt: no g_settings_get_schema?
[14:50] <desrt> obviously that's not an issue for you with gsettings
[14:50] <desrt> larsu: g_settings_schema_source_lookup iirc
[14:51] <desrt> or do you mean for getting the schema on the settings object itself
[14:51] <larsu> the latter
[14:51] <larsu> g_object_get (settings, "settings-schema",..)
[14:51] <desrt> ya.... that's tricky because of the naming
[14:51] <desrt> i wonder what would happen if i removed the "schema" property
[14:51] <larsu> api break
[14:52] <desrt> it's been deprecated for a while
[14:52] <desrt> i don't know if anyone is actually using it
[14:52] <larsu> I only want the schema id and I've got to jump through hoops for that
[14:52] <desrt> are you inside of gsettings?
[14:52] <larsu> ya
[14:52] <larsu> settings->schema?
[14:52] <desrt> you have a pointer to the schema in your priv
[14:52] <desrt> g_settings_schema_get_id (settings->priv->schema)
[14:53] <Sweetshark> note to self: executing commands that rm -rf /dev is unhealthy. even if done indirectly. even if done from a chroot, if it bind-mounts /dev.
[14:53] <larsu> desrt: thanks
[14:53] <desrt> returns const char*, btw
[14:55] <larsu> g_settings_get should really return a boolean
[14:55] <attente> Laney, all of that language data on the device seems to be compiled into a single private header in qtbase-opensource-src
[14:55]  * desrt readies the cluebat
[14:55] <desrt> larsu: why would a function that is always successful return a boolean?
[14:55] <Laney> attente: o rly?
[14:56] <attente> Laney, yeah.. can't really think of a way to change it short of adding a patch there
[14:56] <larsu> desrt: I knew you'd say that. You want g_error for copying formats in the future?
[14:56] <desrt> larsu: no.  i want you to return.
[14:56] <attente> but it's basically a patch of a generated file on a generated file
[14:56] <attente> *it would be
[14:56] <desrt> larsu: the absolute last thing in the world i want is for people to be checking the return value of every g_settings_get() call
[14:57] <Laney> is english the only one where using the short code gives you the wrong thing?
[14:57] <larsu> desrt: okay, but then you really want g_error (once this critical has been in long enough)
[14:57] <desrt> larsu: ya.  that's fair.
[14:58] <desrt> what we _really_ want is to change all of these g_error() to g_critical() and make g_critical() fatal for developers
[14:58] <attente> Laney, well, it's hard to say, but that's a side-effect of QLocale("en_DK.utf8") being the same of QLocale("en")
[14:58] <desrt> ... if we ever discover a reasonable way to do that
[14:58] <Laney> oh I don't know about the en_DK problem
[14:58] <attente> it's a bit tricky and not obvious how to fix it
[14:59] <attente> the language names themselves, well. i can edit the CLDR and regenerate the header
[15:00] <attente> but in order to make sure a problem like en -> en_DK doesn't occur, i'd have to make sure that all locales possibly output by 'locale -a' have an entry in the CLDR :S
[15:00] <Laney> it's a fallback?
[15:02] <attente> yeah. to explain it a bit more clearly, in u-s-s, how we try to determine what 'en' maps to, is we look through all of the 'en_*' locales, create a QLocale for each, and test for equivalence between that and the QLocale for 'en'
[15:02] <attente> so if we find an 'en_*' that's the same as 'en', we say, "oh! en is en_BLAH!"
[15:03] <attente> but that doesn't work for en because en_DK falls back to en :(
[15:03] <attente> and that's because it's missing in the CLDR
[15:07] <Laney> hmm
[15:22] <Laney> attente: I wonder if we could use icu directly
[15:23]  * ogra_ wonders why locale name mapping is still such a pain ... i still remember when the hardcoded mapping list entered GDM years and years ago to work around this
[15:23] <Laney> attente: http://paste.ubuntu.com/6530205/
[15:24] <attente> Laney, that's icu output?
[15:24] <Laney> yeah
[15:26] <Laney> attente: http://paste.ubuntu.com/6530218/ give it a play
[15:26] <Laney> boo tab damage :P
[15:34] <attente> Laney, i must be doing something wrong, because i'm getting "en_US_POSIX - English (United States, Computer)" on the device
[15:35] <Laney> for what?
[15:35] <attente> when i run your test program
[15:35] <Laney> with no arguments?
[15:35] <Laney> I did for i in $(locale -i); ./a.out $i; done
[15:36] <Laney> s/-i/-a/
[15:36] <attente> oh ok
[15:36] <Laney> without it just uses your current locale
[15:36] <Laney> which I guess is POSIX for you there
[15:37] <attente> ok, thanks
[15:38] <attente> yeah, that works great!
[15:39] <Laney> exciting
[15:42] <Laney> did we have timeout problems with the libgdata tests before?
[15:47] <seb128> Laney, yes
[15:51] <happyaron> seb128: I'm a bit interest in XDG_CURRENT_SESSION, will there be any side effect if Kylin changes this to their own?
[15:51] <happyaron> bschaefer: hey
[15:51] <seb128> happyaron, yes, they need to patch all the .desktop to tweak their OnlyShowIn
[15:52] <bschaefer> happyaron, hello
[15:52] <happyaron> bschaefer: I want to know what's the status on the xim support?
[15:52] <happyaron> seb128: and including all the Ubuntu/Unity-specific stuff, to make them also show in Kylin sessions, am I right?
[15:53] <bschaefer> happyaron, right now, the bulk of it is done. There are a couple of problems, one being how to insert it into nux correctly
[15:53] <bschaefer> happyaron, hoping to have that in soon
[15:54] <happyaron> bschaefer: where is the branch? I lost the link (which I think you gave me before)
[15:54] <bschaefer> happyaron, hmm for my xim support, I don't think i've actually pushed a branch. As it wont compile with unity with out a little hack
[15:55] <happyaron> ok
[15:55] <bschaefer> i really should push it to a branch though :)
[15:55] <seb128> happyaron, right
[15:56] <happyaron> even if we are not very likely to use fcitx in this LTS, Kylin is very interested to get the fcitx support landed, I've looked at the branch from csslayer and there are quite some stuff changing XIM/related stuff, so I'd like to know your opinion.
[15:56] <happyaron> seb128: I see.
[15:56] <seb128> happyaron, it's doable, we did do it (added Unity where we were using GNOME before), but it's some work
[15:57] <bschaefer> happyaron, yup, the new changes that I will land will be support for preedit rendering
[15:57] <bschaefer> which is something that wasn't there before
[15:58] <happyaron> seb128: but I'd like to avoid that workload, so any other idea? do you think a gsettings key or something like that would work?
[15:58] <seb128> happyaron, what are you trying to do?
[15:58] <seb128> happyaron, is that still the branding stuff?
[15:59] <happyaron> seb128: I would like to find a proper place so that applications specificially support the Kylin flavor can identify it, and other applications do just the same like in Ubuntu.
[15:59] <seb128> happyaron, can't they just dpkg-divert the logos?
[15:59] <happyaron> seb128: it's a bit more than branding. dpkg-divert the logo is ok, but they want to change more.
[16:00] <seb128> happyaron, like?
[16:00] <happyaron> seb128: they'd like to change every "Ubuntu" to "Ubuntu Kylin" if possible, with a very very high priority.
[16:01] <seb128> do we have many "Ubuntu" mentions on our desktop?
[16:01] <happyaron> not many, but have some hard coded places.
[16:02] <happyaron> I'm waiting for a list from them to see how many places they would like to change.
[16:05] <happyaron> in short, we need to find a way to make applications that specifically add the support for Kylin able to identify it easily, and other applications just continue to see the system/desktop as "genuine" Ubuntu. So they can do whatever thing they'd like to with minimal affect on other stuff.
[16:10] <happyaron> seb128: any input?
[16:10] <seb128> happyaron, I don't really understand the problem so not really
[16:10] <xnox> happyaron: can you check what edubuntu does? i believe they customize the session name, while keeping it Ubuntu.
[16:11] <seb128> I was going to say, edubuntu seems like an example to look at
[16:11] <seb128> they do that sort of things
[16:11] <happyaron> ok
[16:11] <xnox> happyaron: alternatively you can add an upstart user session job to export a Kylin specific environment variable.
[16:11] <seb128> but I don't see that many cases where we have an "Ubuntu" specific behaviour
[16:12] <happyaron> seb128: there are quite some third-party software detects if it's running on "Ubuntu", and that's the question.
[16:12] <xnox> happyaron: e.g. it's best if you tell us _what_ you are planning to modify.
[16:12] <seb128> happyaron, is there?
[16:12] <seb128> happyaron, I don't know of any example
[16:12] <xnox> happyaron: becuase deciding on XDG_CURRENT_SESSION
[16:13] <xnox> happyaron: is most lickely the wrong decision for any customizations.
[16:13] <Laney> seb128: can we drop the goa dropping from libgdata?
[16:13] <Laney> it's why gnome-documents/armhf now fails to build
[16:13] <seb128> Laney, I know it's why
[16:13] <Laney> should be ok with the split now, no?
[16:13] <seb128> Laney, if the goa split making libgdata stop pulling in GTK?
[16:14] <Laney> what was the path before?
[16:14] <seb128> what patch?
[16:14] <Laney> path
[16:14] <happyaron> they told us they found several examples that relies on lsb-release's output, and never give an example, and ask to help change stuff for times, :(
[16:14] <Laney> to getting webkitgtk
[16:14] <seb128> oh
[16:14] <seb128> libgdata->libgoa->libwebkitgtk
[16:15] <Laney> I don't see it now
[16:15] <Laney> want to check?
[16:15] <seb128> ok, good
[16:15] <seb128> sure
[16:15] <seb128> is every in trusty-proposed?
[16:15] <seb128> everything
[16:15] <Laney> enough to check that
[16:15] <Laney> update an i386 chroot for example and install libgdata13
[16:16] <seb128> right, on it
[16:16] <Laney> you should see libgoa-1.0-0b
[16:19] <seb128> weird, "  Candidate: 0.14.0-1ubuntu1"
[16:19] <seb128> oh, fr mirror in there
[16:19]  * seb128 changes that
[16:22] <seb128> Laney, +1
[16:22] <seb128> # apt-get install libgdata13 libgtk-3-0-
[16:22] <seb128> 6 upgraded, 47 newly installed
[16:22] <Laney> ok, great, doing
[16:22] <seb128> that split is good news
[16:22] <Laney> yeah it's pretty nice
[16:22] <Laney> well done upstream for doing the library like that
[16:22] <seb128> the armhf hack I tried last cycle was just a hack
[16:23] <seb128> and I was not seeing a solution out of kicking goa out of build options for libgdata/e-d-s
[16:23] <seb128> yeah
[16:24] <Laney> damn, my latest rebuild of libgdata didn't hang
[16:27] <Laney> at least means I can kick builds of the other stuff
[16:47] <seb128> qengho, not there today?
[16:47] <qengho> seb128: there?
[16:47] <qengho> I'm here.
[16:48] <ogra_> where ?
[16:48] <seb128> qengho, I pinged you earlier to know the status of the autopkgtest test issues for chromium, not sure if you saw?
[16:49] <seb128> qengho, anyway if you didn't, what's the status of chromium-browser/trusty (it's still blocked in trust-proposed)
[16:49] <qengho> seb128: I don't see it.  I have #webapps testing a replacement. It should be today.
[16:49] <seb128> qengho, ok, great news, thanks ;-)
[16:49] <seb128> I hope we can get it unblocked next week
[16:50] <seb128> ogra_, if the ppas every clean their backlog and give us a build, https://launchpad.net/~ubuntu-desktop/+archive/ppa/+packages?field.name_filter=webkitgtk&field.status_filter=published&field.series_filter= ... that should fix the software-center issue, testing appreciated if you can give it a run before your holidays
[16:50] <seb128> ogra_, enjoy the holidays btw ;-)
[16:51] <ogra_> heh, i will ... but i'll likely be around at times too
[16:51] <ogra_> in public channels doing non work stuff
[16:51] <seb128> ogra_, like testing s-c (e.g buying games to play :p)
[16:51] <seb128> ?
[16:51] <seb128> ;-)
[16:51] <ogra_> yeah :)
[17:26] <Sweetshark> seb128: building LO4.1 with gcc-4.7 looks good so far. if it completes Ill hand you a pkg on Monday
[17:27] <seb128> Sweetshark, great, thanks!
[17:27] <Sweetshark> (on trusty)
[17:59] <Laney> alright, happy weekend desktoppers!
[18:05] <seb128> Laney, thanks, you too!