[00:51] <robert_ancell> GunnarHj, is the chown you moved https://code.launchpad.net/~gunnarhj/lightdm/translate-guest-session-dialog/+merge/203091 related to the translations?
[00:51] <robert_ancell> if not, it should be in a different MP
[00:52] <GunnarHj> robert_ancell: No, it's not. I can split them, if you prefer so.
[00:52] <robert_ancell> please do
[02:02] <GunnarHj> robert_ancell: If I (now) understand it correctly, the lightdm trunk branch includes the upstream lightdm plus the Ubuntu debian/ folder. Is that correct?
[02:03] <robert_ancell> GunnarHj, correct
[02:03] <GunnarHj> robert_ancell: Good to know for next time... ;-)
[07:17] <pitti> Good morning
[07:19] <darkxst> hi pitti
[07:19] <pitti> hey darkxst, how are you? how did the DMB meeting go last night?
[07:19] <darkxst> good, just missed out on MOTU, but got ubuntu-GNMOE
[07:19] <darkxst> and desktop-extras
[07:27] <pitti> darkxst: ah, congrats
[07:27] <pitti> darkxst: (sorry, server reboot / fsck)
[07:27] <pitti> darkxst: that should hopefully reduce blocks on your side
[07:30] <darkxst> pitti, yes it will help, once ubuntu GNOME package set gets some packages in it!
[07:30] <darkxst> its currently empty
[07:30] <pitti> ah, heh
[07:31] <darkxst> apparently no one ever noticed
[07:32] <darkxst> pitti, anyway, any idea how I can inject code into gnome-shell to introspect the clutter stage?
[07:32] <darkxst> I think that is all below gtk, so a gtk module probably wont work
[07:32] <pitti> darkxst: I think it rather needs to go into libautopilot-gtk
[07:33] <darkxst> shell embeds gtk, I don't think it will have access to the clutter stage
[07:33] <pitti> darkxst: right, it needs to identify a widget base class (ClutterActor?) and then use its methods to iterate through its children
[07:33] <pitti> presuambly the property handling is identicall to Gtk, as they all (hopefully) just use GObject properties
[07:34] <pitti> darkxst: oh, you mean there is a big GtkWindow at the top, then some clutter widgets, and within those Gtk widgets again?
[07:34] <pitti> darkxst: I thougt the shell's .js only used clutter
[07:34] <darkxst> the shell uses clutter, then embeds gtk within that for some cases
[07:36] <darkxst> it doesnt like look I would get access to the global clutter stage from a gtk module (although I havent tried)
[07:38] <pitti> AP iterates "downwards", starting from gtk_window_list_toplevels()
[07:38] <pitti> so that wouldn't contain the clutter bits, supposedly
[07:38] <pitti> is there no such counterpart for clutter?
[07:39] <darkxst> pitti, iterating the widget tree seems easy
[07:39] <darkxst> but actually getting at it, not so
[07:39] <darkxst> ClutterStage is the toplevel wiget
[07:40] <darkxst> from there finding children is largely the same as gtk, just s/gtk/clutter/
[07:40] <mitya57> Hi desrt, any chance you can update your patch in gnome #708765? It is blocking my fix for bug 1189172 :)
[07:40] <ubot2`> Gnome bug 708765 in general "D-Bus-activated keyring-daemon remains even when its bus terminates" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=708765
[07:40] <ubot2`> Launchpad bug 1189172 in python-secretstorage (Ubuntu) "Should run tests during build" [Wishlist,Triaged] https://launchpad.net/bugs/1189172
[07:44] <darkxst> pitti, mutter does know about the clutter stuff, but I don't believe the plugins there work anymore
[07:49] <darkxst> pitti, I could in theory do it as a shell extension, but that would duplicate a lot of code
[07:50] <pitti> darkxst: you mean the whole bit of exporting the tree and its properties to D-BUS?
[07:50] <pitti> yeah, that woudl duplicate the entirety of the plugin, and be an one-project solution only (and the cost/benefit ratio is probably way too high)
[07:50] <darkxst> pitti, yes, but really it would be better to somehow inject a g_module or something
[07:51] <darkxst> pitti, I did not say I would actually do that!
[07:51] <pitti> (*phew* :) )
[07:51] <pitti> darkxst: what's the kind of things you would want to test for the shell?
[07:51] <pitti> i. e. would that be possible with image-based matching?
[07:52] <pitti> the shell is always full screen, so certain elements should be at fixed coordinates for a particular environment
[07:52] <pitti> like xvfb with a fixed screen size
[07:53] <darkxst> pitti, right now I just want to test that the shell loaded correctly, but it would also be nice to test things like overview search etc
[07:53] <pitti> right
[07:53] <pitti> the event injection probably works just fine
[07:54] <darkxst> gnome-shell steals the gdk input events, so thats probably identical?
[07:54] <pitti> checking "the overlay comes up" is probably feasible with testing the average color of a particular rectangle, or something like
[07:54] <pitti> but ensuring that individual icons appear there sounds less robust, as they tend to change
[07:55] <pitti> darkxst: yes, and it doesn't matter; events shoudl be injected with uinput, so at the evdev level
[07:55] <pitti> that'll work with X, wayland, and every toolkit
[07:55] <darkxst> ok
[07:58] <darkxst> pitti, I probably should chat with walters again, he might have some ideas at getting to the clutter tree
[07:59] <pitti> darkxst: oh, does walters do clutter?
[08:06] <darkxst> not specifically but he setup all the gnome c-i stuff
[08:07] <darkxst> pitti, and he is very interested in having a gnome-shell installed tests, that test functionality (although no idea if they would take an autopilot solution)
[08:30] <pitti> darkxst: so how do the current gnome-shell tests work then?
[08:31] <pitti> darkxst: or they don't exist yet, and you mean walters would just like to have some tests?
[08:50] <seb128> good morning desktopers
[09:03] <darkxst> pitti, right now, there tests are screenshots
[09:03] <Laney> morning!
[09:03] <darkxst> Hi Laney
[09:04] <Laney> hey darkxst
[09:05] <pitti> bonjour seb128
[09:05] <pitti> darkxst: ah, so they need to be updated with icon changes, etc.
[09:06] <darkxst> pitti, I don;t think they even check the screenshots in any useful way
[09:06] <Laney> darkxst: ah, you got some upload rights
[09:06] <Laney> are you happy with that?
[09:07] <darkxst> Laney, more or less, missed out on MOTU but probably Ubuntu GNOME + desktop-extras is enough. alteast once Ubuntu GNOME packageset has packages!
[09:07] <Laney> yeah I'm going to look at that stuff soon-ish
[09:07] <Laney> should be able to move it out of its silo
[09:08] <Laney> the code is quite jumbled atm so it's hard to make the change i mentioned
[09:08] <Laney> I think it'll come out mostly like desktop-extra, so that one probably will just go away
[09:08] <darkxst> Laney, edubuntu has a lot of stuff that is not even seeded in edubuntu
[09:08] <Laney> build-deps get things
[09:09] <Laney> if you poke around in http://people.canonical.com/~ubuntu-archive/germinate-output/ you should be able to see things like that
[09:09] <darkxst> Laney, really? things like gnome-shell and mozjs17
[09:10] <Laney> some things will be directly on their image
[09:10] <Laney> gnome-shell-common (from gnome-shell) is seeded in: edubuntu: dvd
[09:11] <seb128> hey Laney pitti darkxst
[09:11] <darkxst> hi seb128
[09:11] <Laney> http://people.canonical.com/~ubuntu-archive/germinate-output/edubuntu.trusty/rdepends/gnome-shell/gnome-shell-common
[09:11] <Laney> for example
[09:11] <Laney> my point is that there's usually an explanation
[09:11] <darkxst> Laney, oh I guess that is why they have mozjs17 then, although that will be gone with 24
[09:11] <Laney> hi seb128
[09:11] <Laney> how's it going?
[09:12] <seb128> good! you?
[09:12] <Laney> yeah pretty alright
[09:12] <Laney> went to a japanese restaurant and then a 'secret' (everyone knows about it really) cocktail bar for birthday celebrations
[09:13] <darkxst> Laney, oh that is my fault then for adding a gnome-shell frontend to ubiquity?
[09:13]  * seb128 was replying to Jim from yorba about http://blog.yorba.org/jim/2014/01/shotwell-elementary-and-pantheon-photos-what-it-all-means.html (and about him calling our uoa-integration patch a fork)
[09:13] <seb128> Laney, oh, nice!
[09:13] <darkxst> although tweak-tool is in there too
[09:13] <seb128> oh, nice, new gtk 3.10
[09:13]  * seb128 adds to his todolist for the day
[09:14] <Laney> darkxst: dunno, anyway I'll make it so that the overlap is allowed
[09:14] <darkxst> Laney, ok, thanks
[09:14] <darkxst> Laney, also new gnome apps currently dont have any packagesets
[09:15] <Laney> might be a reason for MOTU in future if you don't want them in your iso
[09:15] <Laney> or maybe desktop-extra, dunno
[09:15] <xnox> darkxst: Laney: ubiquity under gdm/gnome-shell looks hot.
[09:15] <Laney> can talk about it
[09:15] <Laney> heh
[09:15] <darkxst> Laney, gnome-maps and gnome-music so far
[09:16] <darkxst> hoping to get gnome-photos and gnome-weather in also before feature freeze though
[09:16] <seb128> you didn't get MOTU?
[09:16] <darkxst> seb128, not quite, apparently I haven't done enough non-GNOMEy packaging
[09:16] <seb128> k
[09:17] <darkxst> xnox, :)
[09:17] <Laney> does it have csd and all that fun?
[09:19] <darkxst> Laney, not in ubiquity, but it could!
[09:19] <Laney> totally
[09:19]  * darkxst not doing that though
[09:20] <darkxst> Laney, its basically a stripped down shell, implemented through session modes, rather than the usual ubiquity DM
[09:21] <Laney> interesting
[09:21]  * Laney doesn't know about session modes
[09:21] <xnox> Laney: in essence, unlike lightdm, gdm allows to execute apps =) upon quiting, autologin is completed into full session.
[09:21] <darkxst> Laney, thats gnome-shell specific
[09:22] <xnox> Laney: which looks like a full gnome-shell, but without e.g. launchers, multiple desktops, minimizing.
[09:22] <Laney> pix pls
[09:22] <Laney> also I'm jealous of your breakfast
[09:22] <darkxst> Laney, breakfast? it dinner time here ;)
[09:22] <xnox> Laney: i've been asking ted, if I could launch unity7 without global-menu, dash, launcher, and some indicators.
[09:23] <xnox> Laney: and launch all of those, when "try ubuntu" is clicked for example.
[09:23] <seb128> Laney, is bdrung still around (in DMB context)
[09:23] <Laney> I haven't seen him very m uch
[09:23] <Laney> tried email?
[09:23] <seb128> xnox, what's the point of launching unity without any unity UI?
[09:24] <seb128> Laney, no, I'm going to try, I wonder if this year is the year of the libreoffice upload rights for Sweetshark :p
[09:24] <xnox> seb128: such that i don't have to maintain lightdm, and "try ubuntu" -> unity transition doesn't involve tearing down X, starting X, starting lightdm, completing auto-login and reloading indicators/panel which look the same as 3 seconds ago.
[09:25] <xnox> * ubiquity-dm that is.
[09:25] <xnox> (maintain ubiquity-dm...)
[09:26] <seb128> xnox, well, if you were using compiz you could probably just start it without the unity plugin and load that one later
[09:27] <darkxst> gnome-shell has session modes, since gnome-shell draws the gdm greeter
[09:28] <darkxst> and also there is the gnome-initial-setup mode
[09:28] <darkxst> its very easy to define any random custom mode, including whatever components are required
[09:31] <seb128> you have 2 gnome-shell running then?
[09:32] <seb128> one for your user and one for the greeter?
[09:32] <seb128> or is the greeter screen part of the user session?
[09:33] <darkxst> seb128, lock screen is part of user session, but login greeter would be a seperate session
[09:33] <darkxst> or maybe it  all runs under a gdm session
[09:34] <seb128> the lock screen doesn't list other users then?
[09:34] <seb128> (e.g it bounce you to another screen to switch?)
[09:34] <darkxst> it has a "switch user" link, which I believe would redirect to the login greeter
[09:36] <seb128> ok, similar to the "old way" then
[09:36] <seb128> I was wondering because we have been talking about using the greeter as lock screen with lightdm
[09:37] <seb128> but it creates issues when the greeter is running with another user/on another vt
[09:37] <seb128> you get your seat becoming unactive, which e.g stops audio playing for the user
[09:38] <darkxst> seb128, not exactly, gnome-shell always renders the greeter
[09:39] <darkxst> and I don't know exactly how it works, but there is no VT switch happening in there, so you don't get big glitches
[09:42] <seb128> so the greeter is on the same VT as the user but running as another user?
[09:42] <seb128> interesting
[09:47] <desrt> mitya57: i won't likely get much time to work on this soon
[09:50] <darkxst> seb128, I believe there is a privileged auth channel between gnome-shell and gdm
[09:51] <darkxst> seb128, halfline and/or robert_ancell probably know more of the gory details though
[09:52] <seb128> right
[09:52] <mitya57> desrt: OK, I will try to look myself then
[09:54] <seb128> pitti, hey, do you have any idea what component is the right one for https://bugs.launchpad.net/ubuntu/+source/pygtk/+bug/1273380 ?
[09:54] <ubot2`> Launchpad bug 1273380 in pygtk (Ubuntu) "gtk.gdk.Window.get_origin() returns 3 values instead of the documented 2-tuple" [Undecided,New]
[09:54] <seb128> pitti, gtk itself?
[09:57] <xnox> seb128: yeah, tried that, was not reliable - compiz crashing or gtk-decorat
[09:57] <seb128> xnox, I doubt that's something we are going to fix/change for unity7
[09:59] <darkxst> xnox, right, despite your dire warnings, I haven't seen a single crash under gnome-shell ubiquity ;)
[10:01] <xnox> seb128: yeah.
[10:04] <darkxst> seb128, what do you think of gnome-desktop transition?
[10:04] <darkxst> (assuming g-s-d fork goes ahead)
[10:07] <pitti> seb128: yes, but it's not a bug; I'll follow up
[10:09] <seb128> pitti, danke
[10:09] <pitti> seb128: oh sorry, the way he wrote it it's indeed pygtk, not GI
[10:09] <desrt> seb128: *dankon ;)
[10:09] <pitti> nope, I think it's him being confused
[10:09] <seb128> pitti, oh, the example in there is pygi so I was wondering
[10:09] <seb128> desrt, good "night"?
[10:09] <desrt> seb128: dankon = thank you
[10:10] <seb128> desrt, yeah, I got that, it's not far from "danke", thanks :p
[10:10] <seb128> desrt, I'm just surprised to see you up at 5am
[10:11] <pitti> seb128: done
[10:11] <seb128> pitti, dankon ;-)
[10:11] <desrt> seb128: i'm in GMT
[10:11] <Laney> norwich, right?
[10:11] <desrt> yup
[10:11] <Laney> neat
[10:11] <Laney> I quite like it there
[10:11] <pitti> seb128: neniu problemo
[10:11] <seb128> desrt, oh ok, had a good flight?
[10:11] <seb128> pitti, ;-)
[10:11] <desrt> pitti: ;)
[10:12] <desrt> seb128: yes.  very nice.
[10:12] <seb128> desrt, did you get promoted again? ;-)
[10:12] <desrt> 'no comment'
[10:12] <seb128> lol
[10:12] <desrt> but...
[10:12] <Laney> man, that's never happened to me
[10:12] <desrt> i went through halifax
[10:12] <desrt> which was awesome
[10:12] <desrt> because it means that the longest leg of the flight was 4h45
[10:15] <larsu> hm, my train to Brussels will take longer than that :-/
[10:15] <larsu> maybe I should ask them to go through Halifax!
[10:15]  * larsu heard everything's faster going through there
[10:16] <desrt> larsu: that may be longer for you :)
[10:16] <larsu> I'm not sure where the flaw in my logic would be...
[10:16] <Laney> there's a halifax in england
[10:16] <desrt> still took 2hr of flying to get to halifax from toronto
[10:17] <desrt> so the overall trip was much longer
[10:17] <Laney> try that one out
[10:17] <desrt> but being able to get out and stretch your legs is very nice
[10:17] <desrt> Laney: what's with your english guys?
[10:17] <desrt> naming all of your cities after ones in canada
[10:17] <Laney> can't improve on perfection
[10:17] <larsu> Laney: Berlin -> Halifax (England) -> Brussels still sounds like a detour to me :P
[10:17] <Laney> :P
[10:18] <desrt> i just don't understand why you picked London, Ontario (of all cities) to name your capital after
[10:18] <Laney> also it's a medium-sized West Yorkshire town
[10:18] <Laney> not exactly a bustling transport hub
[10:19] <darkxst> seb128, my standalone display config daemon is working well, apart from one munched 'monitors-changed' signal, but I can fix that
[10:19] <Laney> https://en.wikipedia.org/wiki/File:London,_Ontario,_Canada-_The_Forest_City_from_above.jpg
[10:19] <Laney> inspirational
[10:20] <seb128> darkxst, oh, sorry, forgot to reply earlier ... that gnome-desktop transition makes me quite nervous
[10:20] <seb128> it's a non trivial change for mid-cycle in a LTS cycle
[10:21] <darkxst> seb128, its a pretty big diff, but its really just code moving places
[10:21] <seb128> well, it's new code as well no?
[10:21] <seb128> and a new architecture
[10:21] <seb128> moving code from a library to a dbus service
[10:22] <seb128> is the new service using the exact same logic as the old gnome-desktop code?
[10:22] <seb128> or is that a new implementation?
[10:22] <darkxst> its obviously not exactly the same, but it more or less similar
[10:23] <seb128> right "more and less" is the issue ;-)
[10:24] <darkxst> probably the biggest change is the way monitor configs are stored
[10:24] <seb128> screen configs are non trivial, we had bugs during cycles about multimonitor and configs
[10:24] <seb128> like what config is applied when plugging a new monitor
[10:24] <seb128> what's the default for projectors, etc
[10:25] <seb128> oh, they changed the config format
[10:25] <seb128> is there a migration path ?
[10:26] <darkxst> hmm possibly not
[10:28] <seb128> :-(
[10:29] <darkxst> monitors.xml no longer exists, it is instead stored within the dameon somewhere
[10:30] <seb128> what do you mean? that config is supposed to persist between sessions/reboots/etc
[10:31] <darkxst> seb128, it would be backed by g_settings or something, it does persist
[10:32] <seb128> ok, so it's stored in gsettings rather than in a .xml
[10:32] <seb128> well, one step at the time
[10:32] <darkxst> it just wont migrate from the old .xml file
[10:32] <seb128> we are finishing the u-c-c transition, then g-s-d -> u-s-d should be next
[10:32] <seb128> then we can test the gnome-desktop transition in a ppa
[10:32] <seb128> but having config migration is going to be needed
[10:33] <seb128> we can't have people upgrading their LTS and having their screen config wrong on next reboot
[10:33] <Laney> tight
[10:33] <Laney> feature freeze is 02/20
[10:33] <Laney> wtf, I did an American date
[10:34] <seb128> boooo
[10:34] <darkxst> seb128, Laney, right if this is going to happen, probably needs to go in parallel
[10:35] <Laney> bah
[10:36] <Laney> QDBus and 'complicated' return types is hard
[10:41] <desrt> stop using qdbus :)
[10:41] <Laney> that'd be nice
[10:41] <desrt> it is by far the worst of the dbus bindings
[10:41] <desrt> and there is absolutely no reason it should ever be used.....
[10:41] <desrt> if we're exposing it as some app-facing API then we've deeply failed somewhere along the way
[10:41] <desrt> we ought to be using gdbus to create higher-level qml-based wrappers...
[10:42] <desrt> because if we're wrapping, then there is no reason to want to use it
[10:42] <Laney> I'd like it if that existed
[10:42] <desrt> if what existed?
[10:43] <Laney> qml dbus bindings in the distro
[10:43] <desrt> but why?
[10:43] <seb128> Laney, I think he's saying "use gdbus in your cpp backend code"
[10:43] <desrt> precisely.
[10:43] <desrt> dbus (in any form) has no business appearing at the application api level
[10:44] <desrt> therefore the precise flavour that dbus has is not important -- and you should use the best-featured and most convenient dbus implementation
[10:49] <Laney> I'd like if where it would avoid me having to write any C++ at all
[10:49] <Laney> that's not to say that exposing proper high-level QMLish interfaces isn't the best way
[10:49] <Laney> and yes, we should have chosen gdbus back at the start
[10:49] <desrt> ah... you hope to use pure qml to write the bindings?
[10:51] <seb128> that's an UI, not binding
[10:51] <seb128> that's the thing we discussed with larsu some time ago
[10:51] <seb128> it would be nice if you could binding e.g a checkbox in a qml to a dbus bool
[10:52] <desrt> seb128: no.  that would be awful.
[10:52] <desrt> this is _exactly_ how you do not want to use dbus
[10:52] <Laney> at that level, it would
[10:52] <Laney> DBus shouldn't be exposed at that level, I agree
[10:52] <seb128> well, as a qml writer it would be nice, one like "checkbox.enabled: pulseaudio.muted"
[10:52] <Laney> it should be pushed down one more
[10:53] <seb128> Laney, well, then you force people to add cpp code and the build system glue, etc
[10:53] <seb128> that's lot of non obvious work to get one boolean value
[10:53] <Laney> I am saying that there ought to be an easier way to write bindings to QML
[10:54] <desrt> seb128: for all but the most trivial cases, writing a meaningful API around a dbus backend is going to be more complicated than binding up some properties
[10:54] <seb128> desrt, yeah, I was speaking about the trivial cases there
[10:54] <seb128> which is frankly what we have most atm
[10:55] <seb128> we want checkboxes to reflect on/off status of system components which export their status on dbus
[10:56] <desrt> and nothing complicated about that at all like policykit to change the value or anything?
[10:57] <seb128> yeah, writing is less easy
[10:57] <Laney> We don't have PK prompting for anything at the moment
[10:57] <Laney> ah
[10:58] <Laney> I just found my problem - I forgot to call qDBusRegisterMetaType ...
[11:00] <larsu> desrt: seb128 is talking about the DBusObject thing I wanted to write last year
[11:00] <larsu> they had the problem that they wanted to read a single property from some service and bind it to a checkbox
[11:00] <larsu> it was only ever intended for that trivial case
[11:01] <larsu> so that they wouldn't need to write wrappers around every service just to access one thing (this was about system settings iirc)
[11:01] <seb128> (correct)
[11:01] <larsu> I still think it's a great idea. It fell short because qml made it so hard that it stopped being worth it
[11:01] <larsu> the qml/cpp bridge is pretty bad
[11:02] <larsu> seb128: thanks :)
[11:02] <Laney> Would a code generation approach be better?
[11:03]  * larsu runs
[11:03] <Laney> From a feasibility standpoint ...
[11:03] <larsu> Laney: ya, probably (I forgot what the actual issues where tbh)
[11:03] <Laney> Something to do with QQMLPropertyMap iirc
[11:04] <larsu> ah right, signals wouldn't have worked
[11:04] <larsu> also, the hole asnyc fiasco
[11:04] <larsu> you can't instantiate qml object asnchronously
[11:04] <larsu> which is understandable, but annoying
[11:05] <seb128> well, at the end most app writers are not going to have to deal with that
[11:06] <seb128> and we can write the cpp code for u-s-s
[11:06] <seb128> it's a bit more work but we have things in place and are used to it by now
[11:07] <Laney> this seems to work now
[11:07]  * Laney MPs
[11:36] <Sweetshark> our builders are too slow. The last rc is still building and I already have the next ready.
[11:37] <ogra_> dont blame the builders for your lack of slack !
[11:44] <Sweetshark> ogra_: faster, ^&**^cat! kill, kill!
[11:49] <popey> didrocks: c'mere when you're not busy
[11:53] <Laney> bah
[11:53] <Laney> seb128: can we do a gsettings-u-t-schemas release with the AS MPs from u-s-s?
[11:53] <Laney> you don't need to take the ringtone one yet
[11:53] <Laney> should be ok without that afaik
[11:54] <Laney> need to check the versions
[11:54] <Laney> on the Breaks/Depends
[12:01] <seb128> Laney, yeah, it's on my list for today, in fact I was just waiting for the landing from yesterday/this morning to be merged back it to queue that one next
[12:04] <Laney> okay, so it's just releasing g-ut-s trunk with https://code.launchpad.net/~laney/gsettings-ubuntu-touch-schemas/auto-brightness/+merge/203302 and another MP to fix the Breaks version to the current u-s-s one
[12:04] <Laney> and then u-s-s with https://code.launchpad.net/~laney/ubuntu-system-settings/as-schemas-package/+merge/201470
[12:05] <seb128> didrocks, sil2100, Mirv: is gsettings-ubuntu-touch-schemas still under autolanding or is it under CI train?
[12:05] <Sweetshark> hmm, there is some obscure missing dependency in the LibreOffice buildsystem. Builds fine on a quad-core with hyperthreading but stumbles on 32 cores now and then.
[12:06] <Laney> what's "* None" in the u-s-s changelog?
[12:07] <seb128> Laney, a but in didrocks' CI script I guess
[12:07] <Laney> didrocks: ^
[12:07] <Laney> ya
[12:07] <seb128> didrocks, https://launchpad.net/ubuntu/trusty/+source/ubuntu-system-settings/0.1+14.04.20140127-0ubuntu1
[12:08] <Laney> also can we start running AP? sil2100?
[12:11] <Sweetshark> Build needed 09:55:57, 27306784k disk space <- \o/
[12:11] <Laney> O_O
[12:12] <Sweetshark> Laney: its that awesome how small the LibreOffice build is once l10n is build in a separate package?
[12:12] <Laney> so tiny I can almost fit the bits in one hand
[12:13] <seb128> Sweetshark, how much was it before? (what arch is that)
[12:14] <Sweetshark> seb128: that number is not really relevant as its the amd64 arch (PPA build). But good point, lemme check.
[12:22] <sil2100> seb128, Laney: let me check
[12:23] <Sweetshark> seb128: i386 on trusty -- 4.1.3-0ubuntu3 Build needed 07:24:00, 24700736k disk space -- 4.2.0~rc2-0ubuntu2 Build needed 04:37:34, 21572744k disk space
[12:23] <sil2100> seb128, Laney: ok, so it seems I moved it out of cu2d today in the morning during the big batch of changes - so I guess it's ready for CITrain
[12:23] <sil2100> (no more cu2d)
[12:24] <xnox> larsu: dbarth_: i want to join https://launchpad.net/~indicator-applet-developers to perform code reviews. I'm versed in C/GTK+ and some C++/Qt.
[12:24] <Laney> k
[12:24] <Laney> sil2100: what about the AP question?
[12:24] <Sweetshark> seb128: so it safed some 3GB of discspace (plus probably another or two as 4.2 like grew itself some new code over 4.1)
[12:25] <seb128> sil2100, great
[12:25] <sil2100> Laney: what do you mean exactly by running AP tests?
[12:25] <seb128> Sweetshark, nice ;-)
[12:26] <Mirv> seb128: that should be in CI Train
[12:26] <Mirv> (documented in the CITrain rampup doc)
[12:26] <Laney> sil2100: http://ci.ubuntu.com/smokeng/trusty/touch/mako/150:20140128:20140115.1/6308/
[12:26] <seb128> Mirv, right, sil2100 just said so
[12:26] <Laney> in that list
[12:26] <Mirv> yep, read that too now
[12:27] <Sweetshark> seb128: ah wait, the 4.1 number is unreliable/likely too low as we deleted the objects files we build after linking and before installing in the mother-of-all-hack.
[12:27] <Sweetshark> s/hack/hacks/
[12:27] <Sweetshark> seb128: so we likely benefit some more ...
[12:30] <seb128> Sweetshark, in any case it's a clear win ;-)
[12:30] <Sweetshark> seb128: yep.
[12:31] <seb128> Sweetshark, btw, do you have another upload queued for the base fix?
[12:34] <sil2100> Laney: ah, you mean, some specific new AP tests you want to be ran during smoketesting
[12:34] <sil2100> ?
[12:34] <Laney> We have ubuntu-system-settings-autopilot these days
[12:35] <Laney> which should work (but please check it does before enabling it)
[12:37]  * didrocks looks for u-s-s MP
[12:38]  * didrocks bets on no commit messages
[12:38] <Sweetshark> seb128: I have a hotfix queued up (this is this one I just for the ppa). And now that I found the rootcause, I fixed it properly.
[12:39] <didrocks> actually not
[12:39] <Sweetshark> seb128: (the lib was accidentally changed to a different library group, when debian moved it to another package in vendor patching. Thus the name changed and doesnt match with the expected one for dynloading from Java).
[12:40] <larsu> xnox: sure, done.
[12:40] <didrocks> No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
[12:40] <didrocks> it was
[12:40] <didrocks> the commit message was added after I think build was pressed
[12:40] <didrocks> on https://code.launchpad.net/~seb128/ubuntu-system-settings/sound-match-design/+merge/203304
[12:41] <Laney> shouldn't this check be enforced?
[12:41] <Sweetshark> seb128: when do you want to upload (is this still timelocked with a poppler transisition?)
[12:41] <seb128> didrocks, right ... and what laney said, should a CI fail leads to a stop somewhee?
[12:42] <seb128> Sweetshark, the current proposed version is already build with the new poppler, if you are fine having that one moving to trusty proper no need of a rebuild/upload soon
[12:42] <seb128> Sweetshark, if you would like to fix base before libreoffice moves to release, it would be nice to do another upload soon to not block the poppler transitin
[12:43] <didrocks> seb128: see on the code, I was wondering if I should fail or not
[12:43] <Laney> did you see why libreoffice is blocked?
[12:43] <didrocks> there is             # TODO: find a fallback or warn if no commit message attached to the MP
[12:43] <didrocks> :)
[12:43] <didrocks> funny, it's just the line before the one that failed on the unicode issue
[12:43] <dbarth_> xnox: ah, i see you've been added now
[12:43] <didrocks> so maybe I'll fix both at the same time :)
[12:44] <Laney> dbarth_: I wouldn't mind joining too if you're adding people
[12:44] <didrocks> Laney: seb128: do you mind if it failed and don't check the next ones?
[12:44] <seb128> Laney, one binary to promote to main, failing autopkgtest, some poppler rdepends still not rebuilt (last I checked)
[12:44] <didrocks> because for all the rest, I tried to continue
[12:44] <Laney> dbarth_: We talked about adding ~ubuntu-core-dev in #ubuntu-devel a little while ago
[12:44] <didrocks> check everything
[12:44] <Laney> what do you think about that?
[12:44] <didrocks> and in the end failed
[12:45] <didrocks> but it's a little bit more complex in that area of code
[12:45] <seb128> didrocks, ok, I've no strong opinion either way on the commit message thing, would still be nice to take the description as fallback :p
[12:45] <didrocks> seb128: pffff, feature request, I was sure of this!
[12:45] <Laney> What if the CI review fails for a different reason?
[12:45] <didrocks> Laney: yeah, let's align with the CI review
[12:46] <didrocks> meaning, forcing having a commit message?
[12:46] <Laney> yes
[12:46] <didrocks> (no strong opinion either, I was in favor of the description beforehand)
[12:46]  * didrocks adds a if(Laney)
[12:46] <Laney> alternatively: stop enforcing that change there and take the description
[12:46] <Laney> but still require the CI review to pass
[12:46] <didrocks> Laney: I'm not in control of the CI part :p
[12:46] <Laney> :-)
[12:47] <didrocks> but the first version I wrote for that fallbacked
[12:47] <didrocks> anyway, I was thinking this case will come like in a month
[12:47] <didrocks> hence the TODO
[12:47] <didrocks> you're bad people
[12:47]  * didrocks is going to cry in the corner
[12:47] <Laney> seb128: libreoffice-l10n-ku/i386 unsatisfiable Depends: libreoffice-l10n-kmr  seems genuine
[12:47] <Laney> didrocks: DAMN USERS!
[12:47] <didrocks> Laney: isn't it? ;)
[12:48] <seb128> Laney, yeah, it's a new binary that go NEWed to universe
[12:48] <seb128> Laney, let me promote it
[12:48] <Laney> my schroot doesn't know about it
[12:49] <dbarth_> Laney: i'd rather let didrocks add full teams to it
[12:49] <Laney> seb128: seems to be kmr-latn
[12:50] <seb128> Laney, right, libreoffice-l10n-kmr needs to be promoted if I read that right
[12:50] <Laney> there is no kmr
[12:50] <seb128> oh
[12:50]  * didrocks grabs some chips and look at seb128's i18n bug
[12:50] <Laney> also britney doesn't know about components
[12:50] <seb128> Laney, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
[12:51] <seb128> Laney, why is it not on there?
[12:51] <Laney> because it's not a component-mismatch
[12:51] <Laney> the package doesn't exist :p
[12:51] <Sweetsha1k> seb128: yep. The hotfix just finished on https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-staging (based on upstream rc3).
[12:53] <Sweetsha1k> seb128: Im just building with the proper fix locally (and with upstream rc4). My proposal would be: Lets see if the proper fix looks ok tomorrow, otherwise we use the hotfix?
[12:55] <seb128> Sweetsha1k, wfm
[12:57] <seb128> Sweetsha1k, hum, Laney is right, libreoffice-l10n-ku depends on libreoffice-l10n-kmr which doesn't exists?
[12:57] <seb128> Sweetsha1k, what's the deal with that?
[12:58] <Sweetsha1k> seb128: there was a whole flamefest going on about kurdish l10n ...
[12:59] <Sweetsha1k> upstream renamed, rene named back etc.. There are some transitionals around for that.
[12:59] <seb128> Sweetsha1k, well, britney is unhappy, so we need to resolve that by adding the package or dropping the depends
[12:59] <seb128> Sweetsha1k, the transitional is missing?
[12:59] <seb128> The following packages have unmet dependencies:
[12:59] <seb128>  libreoffice-l10n-ku : Depends: libreoffice-l10n-kmr but it is not installable
[12:59] <seb128> E: Unable to correct problems, you have held broken packages.
[12:59] <seb128> # apt-cache show libreoffice-l10n-kmr
[12:59] <seb128> N: Can't select versions from package 'libreoffice-l10n-kmr' as it is purely virtual
[13:00] <Sweetsha1k> seb128: I always want to make britney happy. Well, back then. Scrap that. This was off the record.
[13:01] <seb128> lol
[13:01] <seb128> Sweetsha1k, meet ubuntulog_, google, the internet ... that's on record FOREVER
[13:03] <Sweetsha1k> seb128: likely it libreoffice-l10n-ki should depend on libreoffice-l10n-kmr-latn instead. But I gotta read up the details on that. Its a bit mindboggling.
[13:04] <Sweetsha1k> (we now can name dialects properly, so lets rename lots of stuff!)
[13:04] <Sweetsha1k> s/l10n-ki/l10n-ku/
[13:15] <seb128> dobey, hey, do you know if there is an upload of ubuntuone-control-panel planned? I would like to see https://code.launchpad.net/~robert-ancell/ubuntuone-control-panel/unity-control-center2/+merge/203434 merged/landed (it's needed to finish the gnome-control-center -> unity-control-center transition)
[13:18] <Sweetsha1k> nooOOOOooo!
[13:19] <Sweetsha1k> the amd64 PPA build ran out of discspace on the last breath.
[13:19] <Sweetsha1k> time to bring the mother-of-all-hacks back. Will be the zombie-mother-of-all-hacks then.
[13:40] <Laney> tube strike next week
[13:46] <seb128> Laney, "fun"
[13:47] <seb128> Laney, do we have any details on the inpact/what lines are going to have issues?
[13:47] <seb128> when is "next week" btw, does that includes friday? ;-)
[13:47] <seb128> ups
[13:47] <seb128> sunday
[13:48] <seb128> I don't think we really need the tube during the week, there are plenty of places at walking distances
[14:24] <dobey> seb128: don't have any releases/uploads planned for that, at the moment. feel free to upload it as a distro patch for now
[14:26] <seb128> dobey, great, thanks
[14:46] <seb128> grrr, I'm never going to understand http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[14:46] <seb128> why are so many stuff listed for poppler?
[14:47] <seb128> e.g tilelite
[14:47] <seb128> # apt-get install tilelite libpoppler43-
[14:47] <seb128> in a pbuilder works fine
[14:47] <seb128> calligra is not rebuilt yet ok, but why everything else on that list?
[14:52] <Laney> seb128: nah, think it's tuesday
[14:52] <Laney> bus should be ok anyway
[14:53] <seb128> ok
[15:01] <seb128> Laney, any idea about my britney question?
[15:04] <seb128> dobey, why is the u1 bot not liking robert_ancell?
[15:05] <dobey> seb128: because launchpad team permissions
[15:06] <seb128> dobey, can you get fixed or is robert_ancell missing in a team and that should be sorted out?
[15:07] <dobey> i'll fix it.
[15:07] <seb128> thanks
[15:09] <Laney> I think that poppler is entangled with armadillo via gdal
[15:10] <seb128> shrug
[15:14] <Laney> I'd do the rebuilds for poppler and see what comes out at the end
[15:15] <seb128> Laney, what rebuilds are missing?
[15:15] <seb128> Laney, libreoffice needs to be sorted out but I think otherwise we were done (calligra is building)
[15:18] <Laney> so when those are done we can see what it says
[15:18] <Laney> it might need hinting to transition together
[15:18] <Laney> looks like gdal is the only reverse dependency of armadillo so that one is okay too
[15:23] <seb128> Laney, how are the other ones ending up on that line then?
[15:23] <seb128> e.g tilelite
[15:25] <Laney> the set of packages it's trying to migrate does not include armadillo
[15:26] <Laney> so add "libarmadillo4-" and you'll see it
[15:30] <seb128> let's see
[15:30] <seb128> qengho, Sweetsha1k, mlankhorst, Laney, tkamppeter, desrt, attente, larsu: hey, it's meeting time!
[15:30] <Laney> you need to combine both the hints
[15:30] <Laney> but there's no point trying that until all of the rdeps we know of are done
[15:30] <Laney> oh hi!
[15:31]  * Laney got distracted by something... speed summary time
[15:31] <mlankhorst> already? :o
[15:31] <seb128> yeah, same here
[15:31] <seb128> I'm in the middle of like 5 things
[15:31] <seb128> let's get started anyway ;-)
[15:31] <seb128> qengho, hey
[15:31] <qengho> Hey hey.
[15:31] <qengho> * Tested 32.0.1700.77.  Releasing today.
[15:31] <qengho> * More Cr high-DPI work.
[15:31] <qengho> * Worked on renaming "chromium-browser" to "chromium".
[15:31] <qengho> * Preparing 32.0.1700.102 for builds. No raring, yay!
[15:31] <qengho> EOF
[15:32] <seb128> qengho, why was it called chromium-browser?
[15:33] <qengho> seb128: long long ago, there was a "chromium" game.
[15:33] <seb128> I see
[15:33] <seb128> same as epiphany then
[15:33] <qengho> It's been out of the archive for a while. Time to update to the expected name.
[15:33] <seb128> is debian renaming as well?
[15:33] <qengho> seb128: debian already changed.
[15:34] <seb128> nice
[15:34] <seb128> qengho, thanks
[15:34] <qengho> :)
[15:34] <seb128> Sweetsha1k, hey
[15:35] <Sweetsha1k> - found LibreOffice 4.2.0rc2 not building as is on ppc
[15:35] <Sweetsha1k> - triaging a bit difficult without a porterbox, but build.log suggested a byte-order issue in file serialization combined with deep C++-template cascades
[15:35] <Sweetsha1k> - found fixes for this on LibreOffice master for OS X ppc and commited them into the blind -- seemed to have worked
[15:35] <Sweetsha1k> - found the proposed build not able to create a database
[15:35] <Sweetsha1k> - however the build done outside of packaging does this just fine
[15:35] <Sweetsha1k> - turns out debians make-package-modules-not-suck.diff vendor moving libs around between packages also accidentally moved the base libs to another libgroup -- which caused it to be named differently (libhsqldblo.so instead of libhsqldb.so)
[15:35] <Sweetsha1k> - then when libreoffice (from C++) tried to load the java hsqldb driver, that driver would again load native code via JNI and at that point the libname was hardcoded
[15:35] <Sweetsha1k> - TIL: debugging C++ code that loads Java code, which in turn tries to load native code via JNI is much fun
[15:35] <Sweetsha1k> - updated to rc3, updated to upstream rc4, updated patch queues
[15:35] <ritz> qengho, has the game been renamed to chromium-bsu ?
[15:35] <qengho> ritz: I think that's it.
[15:35] <Sweetsha1k> - took part in the great biannual should-we-have-another-rc flamefest
[15:35] <Sweetsha1k> (upstream)
[15:36] <Sweetsha1k> EOF
[15:36] <seb128> Sweetsha1k, working on the uninstallable l10n next? we are going to need an upload to fix that one (can fix base in the same one)
[15:37] <Sweetsha1k> seb128: oh yeah, I fixed the -l10n-ku issue too, I think
[15:38] <seb128> great
[15:38] <seb128> Sweetsha1k, thanks
[15:38] <seb128> mlankhorst, hey
[15:38] <Sweetsha1k> seb128: ... and did bring back the delete-objects-before-install-on-buildd hack to save discspace as amd64 PPA builders sometimes still seem unhappy about discspace
[15:39] <mlankhorst> well that game's chromium-bsu in precise.. :P figuring out a llvm failure (building with qemu-user-static seems to be fastest), adding support for gpu's to 'perf timechart ', lots of madness in getting things ready for upstream kernel, new glamor-egl + xxv-ati
[15:39] <seb128> Sweetsha1k, k
[15:39] <mlankhorst> and some triaging general
[15:39] <mlankhorst> sorry, was on the phone
[15:39] <seb128> mlankhorst, no worry, thanks
[15:40] <seb128> mlankhorst, what's the status of fglrx/xorg 1.15? still no driver for the new ABI?
[15:40] <mlankhorst> no, slightly delayed from chinese newyear
[15:40] <seb128> ok
[15:40] <seb128> mlankhorst, thanks
[15:41] <seb128> Laney, hey
[15:41] <Laney> hai
[15:41] <Laney> • Get webkitgtk built everywhere & transitioned along with webp
[15:41] <Laney> • Debug image build failure related to u-c-c and dependency resolution
[15:41] <Laney> • DMB: start taking over packageset management for all 'flavour' sets - have a look at setting up ubuntu GNOME's, vote on email applications, prepare for elections starting any day now (today?)
[15:42] <Laney> • u-s-s: Spend much time getting the AP tests to pass on the phone. Got there in the end with thanks to elopio & other autopiloters; do some reviews; write brightness panel, discuss powerd API for changing the settings; create new key to store it.
[15:42] <Laney> • gtk3: Default file chooser to the cwd instead of recent files
[15:42] <Laney> • alpha 2 release engineering: blocks, unblocks, respins & publishing
[15:42] <Laney> ▄︻̷̿┻̿═━一
[15:42] <kgunn> mlankhorst: ping
[15:42] <seb128> hum, are you pointing a gun on us?
[15:42] <seb128> ;-)
[15:42] <mlankhorst> pong
[15:42] <kgunn> mlankhorst: hey, hope you're well...
[15:42] <seb128> kgunn, mlankhorst: we are in the middle of a meeting, please use another channel if you can ;-)
[15:43] <kgunn> mlankhorst: can you join #ubuntu-ci-eng ?
[15:43] <seb128> Laney, gtk3 cwd \o/ (that makes gedit much nicer to use again for me)
[15:43] <Laney> it's the surgical precise elimination of bugs
[15:43] <seb128> lol
[15:43] <Laney> yeah we should do that with gtk2
[15:43] <Laney> but code patch blurg
[15:43] <seb128> indeed
[15:44] <seb128> Laney, thanks
[15:44] <seb128> tkamppeter, hey
[15:44] <tkamppeter> - cups-filters: Let pdftops filter log renderer command lines (Ghostscript, Poppler' pdftops, ...).
[15:44] <tkamppeter> - Investigations on running printing-related daemons on-demand.
[15:44] <tkamppeter> - Reported Ghostscript bug about rotating EPS files upstream.
[15:44] <tkamppeter> - Bugs.
[15:45] <seb128> tkamppeter, thanks (good working on tracking down that evince/gs/rotation issue)
[15:46] <seb128> desrt, hey
[15:47] <seb128> no desrt I guess
[15:47] <seb128> attente, hey
[15:47] <attente> seb128, hey
[15:47] <attente> compiz changes merged
[15:47] <attente> alt-grabbing for showing the menu bar, added to PPA
[15:47] <attente> proposed all of the gnome-key-grabber unity changes, but clean up is in progress...
[15:48] <attente> changes to u-s-s language panel for spell-checking and active keyboard layout
[15:48] <attente> dynamic translation fix is in ubuntu-ui-toolkit, experimented with dynamic translation on accountsservice language changes, but doesn't work unfortunately
[15:48] <attente> eof
[15:48] <Laney> doesn't work how?
[15:48] <attente> Laney, seems to be some sort of permissions problem
[15:48] <seb128> attente, doesn't work = bug, or is there an issue which makes it can't work?
[15:48] <Laney> you mean you're listening to a dbus signal?
[15:49] <attente> accountsservice makes a call to get the current session id when trying to load the list of users
[15:49] <attente> but for some reason, apps in general don't seem to have the permissions for that (u-s-s being the exception)
[15:49] <attente> Laney, yes
[15:50] <seb128> oh
[15:50] <seb128> that's likely the apparmor isolation
[15:50] <seb128> click packages don't have access to dbus by default
[15:50] <Laney> what do click packages have to do with it
[15:51] <seb128> they are the one where apparmor is enforced (u-s-s is not)
[15:51] <seb128> well, that's a loud/random guess
[15:52] <seb128> well, anyway, we can discuss that after the meeting
[15:52] <attente> sure
[15:52] <seb128> attente, thanks (your keyboard changes for u-s-s are on my todo for today)
[15:52] <attente> seb128, thanks
[15:53] <seb128> larsu, hey
[15:54] <seb128> no larsu either today? :-(
[15:54] <seb128> ok, my turn
[15:54] <seb128> • some desktop merges and updates (tomboy, librsvg, gtk+3)
[15:54] <seb128> • usual bugs triage and some fixing
[15:54] <seb128> • looked at unity-control-center, tried to help moving the transition forward by testing/reviewing some of the merges, fixed some u-c-c bugs on the way
[15:54] <seb128> • uploaded new poppler and rebuilds needed for the transition
[15:54] <seb128> • some sponsoring (libreoffice, precise SRUs for the oem team)
[15:54] <seb128> • ubuntu-system-settings
[15:54] <seb128> ∘ lot of code review/testing of changes, especially for the system-update refactoring (that got split in smaller parts now, the image update should be ready to land, click are going to be added then)
[15:54] <seb128> ∘ some small bug fixes and design tweaks
[15:54] <seb128> ∘ several rounds of CI train landing
[15:54] <seb128> ∘ discussed with other team the status of backends/features we need (ofono/call waiting (is available) and forward (not yet), silent mode and vibrating for phone app (not yet))

[15:54] <seb128> Laney, you are also on my next-items-of-todolist
[15:54] <seb128> the u-s-s/a-s changes
[15:55] <seb128> that and reviewing your new mrs
[15:55] <Laney> merci
[15:56] <Laney> Did you see the bug about the list of networks not showing up?
[15:56] <Laney> I can confirm that one
[15:56] <seb128> yeah
[15:56] <seb128> but kenvandine said on irc that the ofono script was not working for him
[15:56] <seb128> but the bug says it does
[15:56] <seb128> so I'm a bit perplex
[15:56] <seb128> I don't have a SIM to test
[15:56]  * Laney runs it
[15:57] <seb128> ok, that's it for status update
[15:57] <seb128> other questions/comments?
[15:57] <Laney> yep, it works
[15:57] <seb128> weird
[15:57] <seb128> the panel didn't change
[15:57] <seb128> maybe an issue in the dbus method from ofono?
[15:58] <Laney> dunno
[15:58] <Laney> was hoping ken would look into it :P
[15:59] <seb128> keeeeennnnnn
[16:01] <Laney> #endmeeting!
[16:01] <seb128> yes!
[16:02] <seb128> that's a wrap, thanks everyone
[16:02] <seb128> and see you next week
[16:02] <Laney> oh yeah, fun
[16:02] <qengho> o/
[16:02] <Laney> all the cool kids will be at fosdem this weekend though
[16:02] <Laney> so, see those *this* week
[16:03] <seb128> Laney,
[16:03] <seb128> # apt-get install tilelite libarmadillo4- libpoppler43- python-mapnik2 python-mapnik libmapnik2.2 libgdal1h libarmadillo4
[16:03] <Sweetsha1k> London calling!
[16:03] <seb128> Laney, that works (the line is the one I had to add to get to a working upgrade)
[16:03] <Laney> libarmadillo4- and libarmadillo4 doesn't make sense
[16:03] <seb128> shrug
[16:03] <seb128> # apt-get install tilelite libarmadillo3- libpoppler43- python-mapnik2 python-mapnik libmapnik2.2 libgdal1h libarmadillo4 libpoppler44
[16:04] <seb128> I meant (works as well)
[16:04] <Laney> yep
[16:04] <Laney> that says 'take new armadillo and new poppler'
[16:04] <Laney> which is the situation we want to end up with
[16:04] <seb128> I'm unsure how to find what britney doesn't like from there
[16:04] <seb128> since pbuilder happily install both
[16:04] <Laney> but you can't take new armadillo without new poppler and vice versa and you can't take new poppler until LO and calligra are done
[16:05] <seb128> oh, so we just get the armadillo list in poppler as a transient thing
[16:05] <seb128> e.g that should autoclear once poppler is ready to migrate?
[16:05] <Laney> it says 'migrating those packages makes these ones uninstallable'
[16:05] <Laney> which is true, because armadillo isn't in that list
[16:06] <seb128> can we get britney to try both sets together and tell us what's the output then?
[16:06] <Laney> I hope it will once the two we know about are done
[16:06] <seb128> ok, let's see
[16:06] <Laney> but otherwise we have the facility to add manual hints
[16:06] <Laney> which will be necessary if it doesn't do that
[16:06] <seb128> right
[16:06]  * seb128 feeds more hamsters to Sweetshark
[16:07] <Laney> maybe cherry-pick just that fix if you want the migration done now
[16:07] <Laney> he said it was there already
[16:09] <seb128> well, I'm waiting for him to put a sponsoring request up
[16:09] <seb128> ;-)
[16:09]  * seb128 lazy
[16:09]  * Sweetshark is wearing a hamster hat and a hamster coat now.
[16:10] <Sweetshark> but somehow my ccache doesnt do cache misses anymore. My pbuilder is on drugs and chugging away nicely.
[16:11] <qengho> "doesn't do misses"?
[16:11] <qengho> Sweetshark: what filesystem do you use, btw?
[16:11] <Sweetshark> qengho: well. doesnt do misses _only_ (as it did before for unspecified reasons)
[16:12] <Sweetshark> qengho: boring ext4 for the release builds. tmpfs for the development builds.
[16:12] <Sweetshark> whops, phone.
[16:13] <seb128> kenvandine, hey!
[16:14] <qengho> Ah. I hacked a feature into ccache to use btrfs' copy-on-write fake copy kind-of-hard-link, expecting massive cache-hit wins, and got zero improvement over normal ccache file copy. I want a second opinion.
[16:14] <qengho> Sweetshark: ^
[16:15] <kenvandine> hey seb128
[16:15] <seb128> kenvandine, do you know what's the status of supporting unity-control-center in gnome-control-center-signon?
[16:19] <kenvandine> seb128, no clue... sorry
[16:20] <seb128> no worry
[16:20] <seb128> I should ask mardy
[16:20] <seb128> kenvandine, btw u-s-s not listing carriers, we got a bug report that says the ofono script works (Laney seems to confirm), do you have any idea about the issue?
[16:21] <kenvandine> no... when i tried the other day the script gave me a dbus error
[16:21]  * kenvandine tries again
[16:22] <Laney> unless ofono got updated really recently
[16:22] <kenvandine> still fails
[16:22] <kenvandine> which script?
[16:22] <Laney> nah, I have 6853
[16:22] <kenvandine> should be scan-for-operators
[16:22] <Laney> /usr/share/ofono/scripts/scan-for-operators
[16:23] <kenvandine> dbus.exceptions.DBusException: org.ofono.Error.Failed: Operation failed
[16:23] <kenvandine> i still get that
[16:23] <kenvandine> so maybe that isn't the same issue
[16:23] <Laney> creepy
[16:23] <Laney> are you on the latest ofono?
[16:24] <Laney> http://paste.ubuntu.com/6832826/
[16:34] <desrt> seb128: sorry.  i was hackfesting :(
[16:35] <seb128> desrt, oh, at a hackfest this week? what are you guys hacking on?
[16:35] <desrt> docs
[16:35] <seb128> cool
[16:40] <seb128> Laney, so the landing you needed was https://code.launchpad.net/~laney/ubuntu-system-settings/as-schemas-package/+merge/201470 and gsettings-ubuntu-touch-schemas trunk, right?
[16:40] <Laney> I think so
[16:40] <Laney> need to fix the Breaks/Replaces in the schemas first though
[16:40] <seb128> Laney, did you want to do the landing request yourself to go through CI train landing/see how it works?
[16:40] <Laney> can I do anything meaningful there?
[16:41] <seb128> well, you can "drive" the landing
[16:41] <Laney> I didn't get given any permissions
[16:41] <Laney> or training
[16:41] <seb128> coredevs have access to the build/publish
[16:41] <seb128> I can drive you through if you want
[16:41] <Laney> oh okay
[16:41] <seb128> we just need the CI guys to approve the request/assign the slot
[16:41] <kenvandine> seb128, mind reviewing my ubuntu-wallpapers fix?
[16:41] <kenvandine> https://code.launchpad.net/~ken-vandine/ubuntu-wallpapers/escape-quotes/+merge/203586
[16:42] <seb128> kenvandine, no, cf #ubuntu-devel backlog with infinity
[16:42] <seb128> kenvandine, half an hour ago
[16:43] <kenvandine> oh... i worked around it :)
[16:43] <seb128> kenvandine, I see that :p
[16:43] <kenvandine> but was in a meeting so missed the chatter
[16:43] <seb128> kenvandine, let me comment on the mp, we can keep it around/land it if wanted, I would just prefer for somebody to track the dh_install regression
[16:43] <kenvandine> indeed
[16:43] <seb128> Laney, so, do you have access to https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc#gid=0 in edit mode?
[16:44] <Laney> no
[16:44] <Laney> is this the new version of landing asks then
[16:45] <seb128> Laney, sort of, the difference is that you can drive the landing yourself there
[16:45] <seb128> e.g you get a slot assigned
[16:45] <Laney> but you still have a team of gatekeepers
[16:46] <seb128> then you do the build, publish and merge back
[16:46] <seb128> right
[16:46] <seb128> asac would change his mind on that it seems
[16:46] <seb128> they want to have a control of what is landing to be able to avoid crazyness
[16:47] <seb128> didrocks, sil2100, Mirv:  who is supposed to have edit right to the CI train?
[16:47] <seb128> Laney, I guess it makes more sense to wait next week and do a session there with didrocks
[16:48] <seb128> Laney, I'm going to do that landing request then
[16:48] <Laney> sure, there will be more stuff then
[16:48] <Laney> like the telephony bits
[16:52] <sil2100> Laney, seb128: I guess the ultimate goal is so that as many upstream devs as possible will be able to fill in their own landings, but the landing team will still have to assign silos
[17:00] <didrocks> seb128: yeah, there will be a session next week
[17:01] <seb128> didrocks, should Laney have access to the CI train gdoc since he has upload right or is the acl set different?
[17:01] <didrocks> seb128: well, I know asac wants a first set of people having access to the CI train while we are piloting
[17:01] <didrocks> and then broading up
[17:02] <didrocks> so, it's something to discuss with him I guess
[17:02] <seb128> ok, let's discuss adding Laney next week then
[17:03] <didrocks> seb128: you need alexander I guess
[17:03] <seb128> didrocks, ok
[17:04] <seb128> didrocks, sil2100: can I get a slot for l17?
[17:10] <seb128> didrocks, sil2100?
[17:11] <seb128> hum, I guess I'm not going to have that slot before going for exercice, shame I would have liked to be able to start the build so it's done when I'm back
[17:11] <Sweetshark> seb128: btw, I know now why there likely was so little feedback from rene wrt l10n -- he just moved, so had other stuff to take care of.
[17:11] <seb128> one reason why having CI to approve is an issue btw :/
[17:11] <seb128> Sweetshark, k
[17:12] <sil2100> seb128: meeting, one moment
[17:13] <seb128> sil2100, thanks
[17:16] <seb128> sil2100, can you do it or not? I'm waiting to go for exercice :/
[17:17] <sil2100> seb128: ok, let me do it then! Still in a meeting but will do it inbetween
[17:17] <seb128> sil2100, ok, I though you could click a few things while listening ;-)
[17:20] <sil2100> seb128: done!
[17:20] <sil2100> seb128: yes ;) But there's so much happening here! Oh noes!
[17:22] <seb128> sil2100, thanks!
[17:23] <sil2100> seb128: yw
[17:25] <Sweetshark> btw are there any plans for meeting up at FOSDEM for those attending? Friday Cafe Delirium as usual or something?
[17:32] <attente> seb128, is there a way to disable apparmor on the device?
[17:56] <asac> seb128: can you help training laney?
[17:57] <asac> didrocks: you think seb128 can help traning? the idea was really to go a bit viral here ... especially if we start expand before the last wave has been introduced
[17:57] <asac> but in general its something you have to say didrocks
[17:57] <asac> e.g. can you train more, etc.
[18:01] <didrocks> asac: hum, I thought as we were ramping up, you wanted to have fewer people
[18:01] <didrocks> I'm sure seb128 is more than competent to help training :)
[18:03] <seb128> didrocks, asac: I'm happy to help Laney to get started if somebody gives him edit rights to the table
[18:04] <didrocks> can give that if everyone agrees now, so lets do that
[18:04] <Laney> muhahaha
[18:04] <asac> seb128: laney has all devices that need for landing?
[18:05] <Laney> what are they?
[18:05] <seb128> asac, is n4 = all?
[18:05] <seb128> for the record that's the only supported device I have
[18:05] <Laney> anyway, I'm off
[18:05] <Laney> doing this in person would probably be easiest IMO
[18:06] <seb128> Laney, yeah, let's do that next week
[18:06] <Laney> nod
[18:06] <seb128> Laney, have a nice evening
[18:06] <Laney> will do, climbs to be climbed and pubs to be quizzed
[18:06] <Laney> you too!
[18:08] <seb128> thanks
[18:10] <didrocks> laney should have the creds now
[18:10] <seb128> didrocks, thanks
[18:10] <didrocks> yw
[18:17] <Sweetshark> seb128: 4.2.0~rc4 finished locally. building -l10n locally just to be sure. Waiting to build in both in ppa too at: https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-nattytest2
[18:17] <seb128> Sweetshark, ok, let me know when it's ready for sponsoring
[18:17] <Sweetshark> seb128: ay
[18:17] <seb128> the ppa are starting in some minutes
[18:17] <seb128> so I guess tomorrow morning
[18:20] <Sweetshark> seb128: yep, I will finalize and upload the source pkg to p.c.c now, so that it is ready to go.
[19:04] <Sweetshark> seb128: any idea what could have happened to this build? https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-staging-main/+build/5530498 it has no buildlog (or am I blind?) and builds happily locally ....
[19:08]  * Sweetshark did more than 1GB of uploads today.
[19:09] <Sweetshark> I should consider volume pricing ...
[19:09] <seb128> Sweetshark, no, seems like a launchpad issue, you are good to retry the build I guess
[19:10] <Sweetshark> seb128: nah, forget that one then. there is a newer one already building.
[19:11] <Sweetshark> seb128: _If_ it was broken somehow by me, I would be worried. Looked like a lp issue to be, but just wanted to make sure.
[19:11]  * Sweetshark mumbles: LibreOffice -- based on technology breaking your toolchain since 1985 ...
[19:12] <sarnold> is star office really that old? o_O
[19:12] <sarnold> wow, so says wikipedia. cool :)
[19:15] <Sweetshark> sarnold: ;)
[19:16] <Sweetshark> sarnold: source code comments like "//JP 27.04.95: Why ?" sometimes bring you back to that. http://opengrok.libreoffice.org/xref/core/sw/source/ui/uiview/viewsrch.cxx#257
[19:16] <sarnold> Sweetshark: haha, nice
[19:17] <sarnold> I can't recall if I first tried staroffice back in 95 or 96, the years kind of run together at this point, but it's fun to think it was a decade old even then :)
[19:18] <Sweetshark> sarnold: I never met that JP guy, but experience taught me to fasten my seatbelt when I ran debugging into an area of code with "//JP ..." comments.
[19:19] <sarnold> Sweetshark: no wonder you've never met him, he goes out of his way to be unmeetable I presume :D
[19:21] <Sweetshark> sarnold: there used to be "//JP xx.02.92: Muss noch optimiert werden!" comments around when LibreOffice took over from OOo. But we figured the "optimization" that was postponed for after Cebit'92 and then never was done for 20 year couldnt be that important.
[19:21] <sarnold> Sweetshark: lol
[19:22] <sarnold> time to break out the profiler and see if he was right? :)
[19:23] <Sweetshark> that particular area of code was a hack that survived way to long. And "optimization" in the early days often ment things like "lets use 16-bit ints, there are faster!".
[19:26]  * Sweetshark also remember being a bit scared coming from university and seeing "#define FASTBOOL int" in the legacy code ...
[19:27] <Sweetshark> sarnold: still around in AOO it seems: svn.apache.org/viewvc/openoffice/trunk/main/tools/inc/tools/solar.h?view=markup (LibreOffice killed that crap long ago).
[19:29] <Sweetshark> ah, seeing the good old #define HACK() is still alive over there too. ;)
[19:35] <Sweetshark> lol, they also still have "//Messehack (MA,MBA)" => "trade fair hack"
[19:35] <sarnold> Sweetshark: oooh, __FAR_DATA, how futuristic sounding! hehe
[19:36] <Sweetshark> https://svn.apache.org/repos/asf/incubator/ooo/symphony/trunk/main/sw/source/ui/inc/view.hxx <- theres the "trade fair hack" comment
[19:36] <sarnold> Sweetshark: well, all things considered, that solar.h isn't the worst code I've seen ;)
[19:37] <sarnold> Sweetshark: is that for cebit 92? :)
[19:37] <sarnold> .. and wow. nice to see that no two contributors had the same whitespace settings in their editors. cripes this is right up there with openjpeg. (sorry.)
[19:40] <Sweetshark> sarnold: the problem with solar.h is that it is defining the "old" canonical set of types, while there is a "new" set of canonical types ... which is around since the "initial import" to open source in 2000. So somewhere along that decade the 'old' types should have died.
[19:41] <Sweetshark> sarnold: LibreOffice is mostly clean now.
[19:41] <sarnold> Sweetshark: nice work :)
[19:42] <Sweetshark> sarnold: as for whitespace: Thankfully we did a huge git filter-history in libreoffice giving us consistent whitespace in one of the early repo reorgs.
[19:43] <sarnold> Sweetshark: no wonder ooo hasn't imported your cleanups, they'd have to import the whitespace cleanups too and then stick with it :)
[19:43] <Sweetshark> sarnold: so if you want to see a sane openoffice source indent, look at the libreoffice history, its cleaner.
[19:44] <Sweetshark> sarnold: well, they use SVN officially still. so any kind of merging is a pain anyway.
[19:47] <sarnold> Sweetshark: ow, they just can't win :) hehe