[03:26] <pitti> Good morning
[05:06] <jetsaredim> is there a documented way to get the ia32-libs functionality working on 13.10?
[05:06] <jetsaredim> seems to have broken a bunch of packages
[05:20] <RAOF> jetsaredim: Which packages in particular?
[07:53]  * didrocks reboots
[08:07] <Laney> morning
[08:08] <didrocks> hey Laney! how was your party?
[08:09] <Laney> we just went to the pub for dinner / beers
[08:09] <Laney> but it was nice!
[08:09] <Laney> how are you? looking forward to the weekend?
[08:14] <mlankhorst> it's weekend for me :D
[08:16] <didrocks> Laney: yeah, waiting for it, no party in my city though (for 2 cycles :( )
[08:17] <Laney> aww
[08:20] <didrocks> Laney: do you know where is the configuration used to make those kinds of mount? /var/lib/schroot/chroots/quantal-amd64 on /var/lib/schroot/union/underlay/quantal-amd64-7d9b8eb9-5432-41df-b0aa-62dbe9e76537 type none (rw,bind)
[08:20] <didrocks> I think it's sbuild, but not sure where the config file is
[08:20] <didrocks> (tried to grep -r in /etc, but no luck)
[08:20] <Laney> hmm?
[08:20] <Laney> What do you want to do?
[08:21] <Laney> The schroot configuration files are in /etc/schroot/
[08:21] <didrocks> hum grep -r quantal /etc/schroot/*
[08:21] <didrocks> Laney: I want to remove my quantal chroots (and mounts)
[08:22] <Laney> you have that even after a reboot?
[08:22] <didrocks> not sure why they are mounted at boot as well
[08:22] <didrocks> yeah
[08:22] <Laney> O_O
[08:23] <Laney> does schroot -l --all-sessions show anything?
[08:23] <didrocks> W: No chroots are defined in ‘/etc/schroot/schroot.conf’ or ‘/etc/schroot/chroot.d’
[08:23] <didrocks> session:quantal-amd64-7d9b8eb9-5432-41df-b0aa-62dbe9e76537
[08:24] <didrocks> so, not sure where this definition is
[08:24] <Laney> that's bizarre
[08:25] <Laney> anyway, you should be able to end it with schroot -e --all-sessions
[08:25] <didrocks> ok, the session ended
[08:25] <didrocks> let me reboot to see
[08:27] <didrocks> Laney: ok, at least, the session didn't autobindmount this time, thanks!
[08:28]  * didrocks is looking at how to remove it cleanly now
[08:40]  * Laney hugs attente 
[08:40] <Laney> that layout change bug is noisy
[10:45] <sil2100> didrocks: hi! Regarding updating of cu2d-config with the new saucy branches - what should we do with touch only projects? Should we enable them for daily release only in head? Or only in saucy and leave them disabled as 'to_transition' in head?
[10:45] <sil2100> (probably the latter?)
[10:46] <didrocks> sil2100: no, please put them in head
[10:46] <didrocks> I guess that's what makes more sense
[10:46] <didrocks> and disable in saucy
[10:46] <sil2100> didrocks: ok, so daily_release: False?
[10:47] <didrocks> sil2100: check with fghinther, maybe we need to direcly remove those so that there is no duplication in the upstream merger
[10:49] <sil2100> didrocks: ok, he's currently on holiday right now I guess, and he only did a desktop-only stack right now, but maybe I'll catch him for a moment ;)
[10:50] <didrocks> sil2100: yeah, let's see :)
[11:26] <sil2100> Hi! Does anyone know if indicator-network-prompt is touch only?
[11:26] <didrocks> $ seeded-in-ubuntu indicator-network-prompt
[11:26] <didrocks> indicator-network-prompt's binaries are not seeded.
[11:26] <didrocks> sil2100: so, not in any ubuntu image, should be touch only ^
[11:27] <sil2100> I didn't see it in the manifest as well, but been wondering if it's indeed used in touch as well, since the dependencies are not explicit
[11:27] <Laney> erm
[11:27] <Laney> seeded-in-ubuntu works for touch too
[11:28] <didrocks> $ seeded-in-ubuntu indicator-network
[11:28] <didrocks> indicator-network (from indicator-network) is seeded in:
[11:28] <didrocks>   ubuntu-touch: daily-preinstalled
[11:28] <didrocks> oh indeed :)
[11:28] <didrocks> sil2100: so it's used, nowhere ;)
[11:28] <sil2100> I wanted to catch Pete, but he's not around
[11:28] <sil2100> didrocks: I guess I'll split it then ;p ?
[11:28] <didrocks> sil2100: no, on the contrary, don't split it
[11:28] <didrocks> no maintenance to do on it :)
[11:28] <darkxst> Hey Laney
[11:29] <sil2100> Ah, so treat it as touch only and let it stay in head?
[11:29] <Laney> hey darkxst
[11:29] <Laney> how goes?
[11:29] <didrocks> sil2100: yeah, the question is in fact "do we maintain it for older release?"
[11:29] <darkxst> not great right now, car-less still
[11:29] <Laney> oh no
[11:30] <darkxst> yah, write-off, with complications
[11:30] <Laney> you crashed it?
[11:30] <Laney> :S!
[11:30] <darkxst> nope, it was just parked outside my house
[11:31] <sil2100> didrocks: it's only in saucy it seems!
[11:31] <didrocks> sil2100: yeah, so will be T only in term of support :)
[11:31] <didrocks> sil2100: but please, reach to Pete, not sure why it was developped if not installed
[11:32] <czajkowski> don't you guys ever rest, take the day off after a release ;)
[11:33] <darkxst> Laney, anyway, all that aside, do you think I would get PPU for ubuntu gnome package set if I applied?
[11:33] <Laney> darkxst: yeah, almost certainly
[11:33] <Laney> I saw jbicha left the team
[11:34] <darkxst> yeh jbicha is gone
[11:34] <didrocks> czajkowski: heh, I can see sun + week-end from my window, so week-end is near! ;)
[11:34] <Laney> :/
[11:34] <Laney> hope you guys find some more manpower
[11:34] <Laney> anyway, yeah, get it in
[11:34] <darkxst> ricotz is still there doing is own thing
[11:34] <darkxst> which helps a lot with the pre-packaging
[11:35]  * Laney nods
[11:35] <Laney> I'd +1 you for ubuntu-desktop too, FWIW
[11:38] <Laney> xnox: is ubuntu-installer@ ever used by humans?
[11:39] <xnox> Laney: as in the ubuntu-installer@lists.ubuntu.com mailing list? well ABI bumps are mailed by human, and occasionally installer help / debugging is done there (by human posts)
[11:40] <Laney> ok
[11:40] <xnox> but it is low traffic.
[11:40] <Laney> was going to suggest A lanBell forwards his ubuntu-desktop email there
[11:40] <Laney> still, known bug ...
[11:42] <darkxst> Laney, oh thanks! I suppose that would be handy, but means more seb
[11:42] <Laney> haha
[11:42] <xnox> Laney: I wish there was ATK api I could call into to suppress / add events. I re-arrange half of the screen widgets, or change them, and screen-reader doesn't say anything. Or vice-versa, "bling" is animated and is pointlessly announced.
[11:42] <Laney> yeah I don't know anything about that stuff
[11:43] <rickspencer3> hey desktoppers ...
[11:43] <Laney> maybe you want to work on it with TheMuso
[11:43] <rickspencer3> I'm hearing that this bug is a bit urgetnt ... https://bugs.launchpad.net/ubuntu/+source/indicator-keyboard/+bug/1218322
[11:43] <ubot2> Launchpad bug 1218322 in gnome-settings-daemon (Ubuntu) "Can't set keyboard layout change to alt+shift, ctrl+shift, etc." [High,In progress]
[11:43] <Laney> rickspencer3: attente is actively working on that one
[11:44] <rickspencer3> thanks Laney
[11:44] <Laney> he should be on in a little bit if you need more info
[12:08]  * Laney arghs at PNG optimisation
[12:08] <Laney> This should be able to be parallelised
[12:15] <didrocks> quite painful in some packages, isn't it? :)
[12:32] <xnox> What is / was: "indicator-session-devices" ?
[13:49] <xnox> tedg: larsu: please review/accept branches linked to bug 1241539, i'd like them merged to trunk. I know there is no t-series to release this stuff to.. but still.
[13:49] <ubot2> Launchpad bug 1241539 in indicator-sound (Ubuntu) "ubiquity-dm is missing keyboard, input, sound, system indicators" [High,Triaged] https://launchpad.net/bugs/1241539
[13:54] <tedg> xnox, K, trunk is 14.04.  Do you want them to hit 13.10 branch as well?
[13:55] <tedg> xnox, Also, have you guys discussed switching ubiquity over to being an upstart session for 14.04?
[13:56] <tedg> xnox, Is that on the table for work items?
[13:59] <xnox> tedg: no point for 13.10, cause we are not re-releasing .isos, but i guess at least people will see the fix / indicators in the oem config stage....
[13:59] <xnox> tedg: i think for 14.04 only.
[14:00] <xnox> tedg: i think investing to make ubiquity upstart session, only if when we switch to mir by default on desktop and start requiring ubiquity to run in mir.
[14:00] <tedg> xnox, I don't see how those are related?
[14:01]  * tedg assumes that xnox knows Mir and Upstart do different things
[14:01] <tedg> :-)
[14:01] <xnox> tedg: at the moment ubiquity-dm: bypasses lightdm, bypasses X, session upstart, gnome-session.
[14:02] <xnox> tedg: and I'd rather have same feature-parity, if ubiquity-dm becomes user-session and looses ability to spawn fallback X server and the like.
[14:04] <xnox> tedg: thus if i make it user-session, without mir and engineer replacements around X technology, it's a waste of time, cause i'll have to redo it under Mir not so long after.
[14:04] <tedg> xnox, My issue is that I want to move the indicators over to being Upstart jobs.  Would you consider running Upstart with no startup event, and then starting the ones you want?
[14:04] <xnox> tedg: yeah, i'd be fine with that.
[14:05] <xnox> tedg: ubiquity-dm already spawns it's own everything, so no reason it can't spawn a custom / small upstart to launch a couple of jobs. actually that might be unintrusive babysteps.
[14:06] <tedg> xnox, Okay, sounds good
[14:07] <tedg> mterry, Do you think that could work for unity-greeter as well?  ^
[14:07] <mterry> tedg, potentially
[14:07] <xnox> tedg: mterry: do note that even system-init has two distict startup events.
[14:08] <xnox> we complete sub-vert boot and do $ init --start-up-event recovery to start in recovery mode with menu-selection.
[14:08] <xnox> and once done we simply emit normal "startup" event to kick off / complete normal boot.
[14:09] <xnox> similarly there is no reason why indicators can't all start on "indicators" event
[14:09] <xnox> and then for normal login we have a dummy "emit indicators" upstart job.
[14:09] <xnox> and in case of ubiquity/unity-greeter, spawn init --start-up-event indicators.
[14:10] <tedg> All the indicators do start on an indicator event.
[14:10] <tedg> It's emitted by Unity 7/8
[14:10] <tedg> When they're ready to have indicators.
[14:17] <xnox> ooh, nice.
[14:17] <xnox> so i can start init, and emit indicators after panel is up.
[14:17] <xnox> but i guess my panel.c just force loads them...
[14:20] <tedg> Yeah, I think that makes sense.
[14:21] <tedg> Then effectively all the indicators are "one PID" from the greeter/ubiquity's perspective.
[14:21] <tedg> Means that we can easily reshuffle them without breaking.
[14:32] <seb128> happy friday desktopers!
[14:33] <Laney> someone please review my patch update in the g-c-c packaging branch
[14:33] <Laney> happy friday seb128!
[14:33] <seb128> Laney, hey, you yoo!
[14:33] <seb128> Laney, looking to g-c-c
[14:44] <larsu> xnox: sure
[14:57] <seb128> Laney, that seems a weird way to do it
[14:57] <Laney> what do you recommend?
[14:57] <seb128> Laney, what we have been doing in other places is what 51_unity_options_in_display_panel.patch do
[14:58] <seb128> +  schemas = g_settings_list_schemas ();
[14:58] <seb128> +  while (*schemas != NULL)
[14:58] <seb128> +    {
[14:58] <seb128> +      if (g_strcmp0 (*schemas, UNITY2D_GSETTINGS_LAUNCHER) == 0)
[14:58] <seb128> well, your way seems fine, it's just not what we are doing in other places
[14:58] <Laney> is that better?
[14:58] <Laney> I stole this idea from the 'gsettings' tool
[15:00] <seb128> Laney, desrt says your way is about the best we can do
[15:00] <seb128> Laney, so +1
[15:00] <desrt> Laney: seb lies
[15:00] <desrt> the best we can do is to have the panel in the indicator itself, as with datetime
[15:00] <desrt> that is the correct thing to do
[15:00] <desrt> since we diverge from gnome upstream on the panels anyway....
[15:01] <Laney> completely fork it?
[15:01] <desrt> that's what datetime did
[15:01] <Laney> Don't know how much that has in common with the upstream panel
[15:01] <Laney> this just adds one label/combo
[15:01] <desrt> the other alternative is to have gsettings-ubuntu-schemas and depend on that
[15:01] <desrt> that's why gnome does gsettings-desktop-schemas
[15:01] <Laney> it'd be a bit annoying to do a whole fork for that
[15:02] <desrt> well
[15:02] <desrt> we keep talking about wanting to do u-c-c anyway
[15:02] <Laney> yes, /that/ would be good
[15:02] <Laney> because then you get easy merging with upstream
[15:03] <seb128> Laney, desrt: well, that change is the easiest thing to do/right fix until we have a proper fork
[15:03] <Laney> ya
[15:04] <Laney> thanks for the review
[15:12] <Laney> https://errors.ubuntu.com/problem/a070e0e0f342f3d445cf13bf28f08d2868be0ba3
[15:12] <Laney> this seems noisy
[15:16] <seb128> Laney, I talked to robru about that one yesterday
[15:18] <Laney> yeah?
[15:18] <seb128> Laney, he said that it happens when running friends from raring with pygobject from saucy
[15:19] <seb128> Laney, it's likely it's happening during upgrades, pygobject gets upgraded first and during the time in between pygobject and friends are upgraded, the friend-dispatcher is started (its keeps going up and down)
[15:22] <Laney> okay, then a Breaks should fix it
[15:22] <Laney> or fixing the code in raring to work with both
[15:23] <walters> seb128: precisely the sort of thing ostree fixes, btw
[15:24] <seb128> walters, yeah...
[15:25] <walters> (and unlike Image Based Upgrades, it has a sane story for how it interoperates with packages)
[16:29] <seb128> rickspencer3, hey, I read the backlog and I saw you pinged about that keyboard/keybinding issue, do you have any specific on what bits are important?
[16:30] <seb128> rickspencer3, (it's being actively worked but it mixes several issues and some of those are non trivial to fix, just trying to figure out if there is a workaround we could use that would it less of an issue for users until it's properly resolved)
[16:31] <rickspencer3> seb128, I dunno, silbs mentioned that a lot of folks were pinging her about it
[16:31] <rickspencer3> Laney said it was being handled, so that was good enough for me :)
[16:31] <seb128> rickspencer3, can you get specifics about the ping/what is the main concern?
[16:32] <seb128> rickspencer3, well, "being handled", attente has been spending the last few days on it (as you can see from the bug comments/ppa roundtrips)
[16:32] <seb128> rickspencer3, so yeah, it's  actively worked, but we don't have a solution fixing all the problems yet
[16:33] <Laney> hmm, the latest LC_stuff change is a bit buggy
[16:34] <seb128> rickspencer3, though part of the issue is that users can't set the keybinding to some value (e.g l-shift+r-shift), I wonder how much of an issue that is
[16:34] <seb128> rickspencer3, or if changing the default to e.g ctrl-alt and having that working would be good enough for most users
[16:34] <seb128> Laney, in u-s-s?
[16:34] <seb128> Laney, how so?
[16:35] <Laney> hang on, trying to get the output
[16:35] <Laney> don't distract Will though; I'll look at it (maybe on Monday) :-)
[16:35] <seb128> Laney, right
[16:35] <seb128> no hurry for u-s-s
[16:35] <seb128> it's not like those changes would land on an image this week anyway
[16:36] <Laney> indeed
[16:36] <Laney> http://paste.ubuntu.com/6258334/
[16:37] <seb128> Laney, it's like the 2 calls were done using different locales
[16:40] <seb128> Laney,
[16:40] <seb128>  
[16:40] <seb128> 162
[16:40] <seb128>             act_user_set_language(user, qPrintable(languageCode.left(languageCode.indexOf('.'))));
[16:40] <seb128>  
[16:40] <seb128> 163
[16:40] <seb128>             act_user_set_formats_locale(user, qPrintable(languageCode));
[16:40] <seb128> shouldn't they both use "languageCode.left(languageCode.indexOf('.')"?
[16:40] <Laney> Dunno
[16:40] <Laney> I'm guessing it was deliberate
[16:41] <seb128> attente, ^
[16:43] <Laney> hmm
[16:44] <Laney> the dbus api documentation says they should be the same
[16:44] <seb128> Laney, he's doing the '.' stuff to filter the UTF-8 out
[16:48] <Laney> seb128: https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/accountsservice/saucy/view/head:/data/org.freedesktop.Accounts.User.xml#L153
[16:50] <seb128> Laney, ok, does dropping the ".indexOf('.')" resolve the issue?
[16:50] <Laney> let's see
[16:52] <Laney> hmm
[16:52] <seb128> sil2100, fginther: do we have mergers for 13.10 branches?
[16:52] <seb128> sil2100, fginther: https://code.launchpad.net/~larsu/libindicator/always-create-widgets/+merge/191701 is sitting there with no CI nor merge happening
[16:54] <sil2100> seb128: I doubt we have those yet - fginther is on holiday today, and the merge for updating cu2d-config for indicators is still awaiting review
[16:56] <sil2100> Laney, seb128: I tested if the locales were changing with that branch attente prepared and they were, didn't check the api docs though
[16:56] <sil2100> I was assuming those were deliberate as well
[16:57] <Laney> Well, AS actually rejects it if you pass e.g. de_DE on its own
[16:57] <Laney> so I don't really get what it set
[16:57] <Laney> the property was actually set to de_BE.UTF-8
[16:57] <Laney> needs more debugging
[16:58] <seb128> Laney, k
[16:58] <sil2100> Ok, so maybe I approved to hastily?
[16:58] <seb128> sil2100, should I just manually SRU that libindicator fix then?
[16:58] <Laney> it's still an improvement
[16:59] <Laney> we can fix in followups
[16:59] <seb128> cyphermox, ^ (the SRU question)
[16:59] <seb128> cyphermox, hey btw
[16:59] <seb128> Laney, yeah
[16:59] <sil2100> seb128: I would guess if it's important, let's do that - since today we won't get CI and mergers prepared for sure
[16:59] <sil2100> Since we need fginther to be around for that
[17:00] <cyphermox> sil2100: what>? why?
[17:00] <cyphermox> isn't that commit merged yet?
[17:00] <sil2100> Laney, seb128: right, sorry about that - I think I probably tested such a case where all locales got set to the same thing
[17:00] <sil2100> cyphermox: which one?
[17:00] <seb128> sil2100, ok, let's do that
[17:00] <seb128> tedg, ^ side effect of your early branching btw :/
[17:00] <cyphermox> seb128: yeah, upload directly
[17:01] <cyphermox> seb128: I don't think it's an issue with branching
[17:01] <seb128> cyphermox, sil2100: thanks
[17:01] <cyphermox> but I'll take a look at the config again to check what'sup
[17:01] <seb128> cyphermox, well, it's an issue of creating stable branches without making them be under CI
[17:02] <cyphermox> seb128: they should be under CI already
[17:02] <seb128> cyphermox, sil2100 says it's a fginther thing
[17:02] <sil2100> https://code.launchpad.net/~sil2100/cupstream2distro-config/apps_click_friends_hud_indicators_13.10/+merge/191788 <- this would have to be in, and fginther would have to set up the mergers/CI for those new branches
[17:02] <sil2100> cyphermox: they can't be in CI if they're not in cu2d-config
[17:02] <cyphermox> the config should be sufficient for the branch to be covered
[17:02] <seb128> cyphermox, https://code.launchpad.net/~larsu/libindicator/always-create-widgets/+merge/191701 didn't get CI review/comments nor merging though :/
[17:02] <seb128> k
[17:02] <sil2100> cyphermox: if cu2d-config doesn't have the /13.10 branches in it and fginther doesn't pull that in on the mergers side, there's no CI
[17:03] <Laney> Is anyone on devicekit-devel?
[17:03] <cyphermox> sil2100: I understand that but it should have been added as part of the procedure of branching, a few weeks ago
[17:03] <seb128> Laney, pitti maybe?
[17:03] <Laney> If so, please bounce me hadess' email
[17:03] <sil2100> cyphermox: sadly it was not
[17:04] <sil2100> cyphermox: me and fginther started doing that yesterday evening
[17:04] <Laney> Removed signals:
[17:04] <Laney> - changed (both UpClient and UpDevice), device-changed (connect to the
[17:04] <Laney> "notify" signal for the properties that interest you instead)
[17:04] <Laney> Changed
[17:04] <Laney> ignore "Changed"
[17:04] <cyphermox> sil2100: ping the ci team on #ubuntu-ci-eng, they can do it
[17:04] <cyphermox> it shouldn't ever have to be only fginther
[17:05] <seb128> Laney, is that going to create issues?
[17:05] <Laney> It's going to create porting
[17:06] <Laney> It now implements the proper PropertiesChanged signal which is great, but killing the old interface without any transition period is unfortunate IMO
[17:06] <seb128> yeah :/
[17:06] <Laney> (D-Bus and GLib API changes are pretty much the same)
[17:07] <Laney> ok, noted to follow that up on monday too
[17:07] <Laney> have a good weekend ;-)
[17:08] <seb128> Laney, thanks, you too
[17:08] <kenvandine> have a good weekend Laney!
[17:09] <Laney> yeah, we have http://gamecity.org/about in town which I'll check out :D
[17:09]  * Laney waves
[17:09] <seb128> nice
[17:09] <seb128> Laney, have fun!
[17:12] <tedg> seb128, To be fair, I asked the CI folks before doing it.  They told me it wasn't a big deal, and I should start branching.
[17:15] <seb128> tedg, sure, easy for them to tell, they don't have code to land
[18:00] <bcurtiswx> why would I still be receiving empathy messages even though i've quit empathy ?
[18:00] <bcurtiswx> how does one completely turn off empathy ?
[18:00] <bcurtiswx> is that more of a #ubuntu question tho, i'll head over there
[18:04] <bcurtiswx> hmm, i c.. it's directly integrated into the status set in messaging-menu. If you're not "offline" on there, you will still continue to receive messages
[18:24] <bcurtiswx> i take my previous statement back, im offline and still receiving messages
[18:31] <seb128> bcurtiswx, that seems buggy
[18:31] <seb128> bcurtiswx, the fact that closing the empathy UI doesn't send you offline is a known/normal
[18:32] <seb128> bcurtiswx, but setting the status offline should work
[18:40] <bcurtiswx> seb128, OK thanks, i'll get a bug report done soon :)
[18:40] <seb128> bcurtiswx, thanks
[20:06] <bcurtiswx> should the hud-service be taking up 15% of my 8GB of RAM ?
[20:57] <sarnold> bcurtiswx: discovering the amount of memory actually used is somewhat difficult. Or maybe, subtle. Check out the 'smem' tool, it tries to place blame on applications for memory usage in a different way that might be more instructive
[21:26] <filosofixit> Hi! I just upgraded to 13.10 amn everything work great, but I got two network-manager icons in my systray. One had all the functionality and the other just the possibillity two turn the NIC's on/off... I tried uninstalling and reinstalling network-manager but now  I only got one icon but its not working at all... Anyone got a clue?