[00:33] <Sweetshark> http://lists.debian.org/debian-devel/2013/06/msg00720.html scary. 1200 exploitable bugs in wheezy.
[00:36] <lifeless> well
[00:36] <lifeless> its not clear that there are 1200 bugs
[00:36] <lifeless> they're reporting the same library crash in every consuming application.
[00:36] <lifeless> It might be 5 bugs.
[00:36] <lifeless> dunno yet.
[00:43] <Sweetshark> lifeless: given the number of different packages, that would have to be 5 glibc bugs then though, which would hardly make it any better.
[00:48] <lifeless> sure
[01:01] <sarnold> they aren't all in libraries, here's one that was well and truly our fault: https://lists.ubuntu.com/archives/apparmor/2013-June/003927.html
[04:36] <pitti> Good morning
[04:37] <pitti> attente: I noticed missing menus in gtimelog and my pygtk test application
[04:45] <RAOF> pitti: Good morning.
[04:55] <RAOF> pitti: I presume the reason umockdev doesn't have a testbed_add_from_file because no-one's wanted it yet? :)
[04:56] <pitti> RAOF: by and large, yes; I was using add_from_string()
[05:05] <RAOF> That's what I'll do. But I'll probably read it from a file, because it's quite big :)
[05:09] <pitti> RAOF: yeah, and umockdev-run does just that
[05:10] <pitti> RAOF: if it's more convenient, I'm happy to add an add_from_file, which will then just pass along any errors as GError
[05:10] <RAOF> Yeah, it'd be more convenient.
[05:11] <RAOF> We're highly likely to be adding significant numbers of significantly-attributed mock udev devices.
[05:28] <pitti> RAOF: mostly for input, I presume? or do you mock anything else?
[05:29] <RAOF> drm, too.
[05:30] <RAOF> Device detection, monitor hotplug.
[05:30] <RAOF> Although the tense is wrong; *currently* we don't mock anything :)
[05:49] <pitti> RAOF: I filed https://github.com/martinpitt/umockdev/issues/15 as a reminder
[05:50] <RAOF> Awesomesauce.
[06:27] <RAOF> pitti: Hm. There's no way to destroy a umockdev object from C?
[06:27] <RAOF> The Vala class has a destructor; I'm surprised that doesn't get translated to something C-callable.
[06:30] <pitti> RAOF: it's a normal GObject, so you just g_object_unref() it
[06:30] <pitti> RAOF: the destructor gets translated into a normal GObject _dispose() (or maybe _finalize())
[06:30] <RAOF> Ah, that makes sense.
[06:31] <pitti> but one usually doesn't call those directly
[07:13] <darkxst> RAOF, will gdm work under XMir?
[07:16] <RAOF> darkxst: Not without patches, but that's because gdm isn't really under X now.
[07:17] <darkxst> RAOF, well the rendering side of things is...
[07:17] <RAOF> But XMir *is* X, so gdm will happily start X as normal.
[07:17] <RAOF> darkxst: Oh, yeah.
[07:18] <RAOF> So, the answer to ‘will my $X11 client work under XMir’ is “yes”.
[07:18] <didrocks> RAOF: btw, do you think that we can expect this patched Xorg going quickly to saucy once we resolved the minor issues around Mir to enter distro?
[07:18] <mlankhorst> RAOF: if you can nuke the separate mir thread xmir would  become a lot more acceptable :-)
[07:18] <RAOF> mlankhorst: Oh, I'd *love* libmirclient to give me an fd. I think we might be doing that, too.
[07:18] <darkxst> RAOF, so when gdm tries to launch a new X server, is it launching X or Xmir
[07:19] <darkxst> I assume the latter would require patches?
[07:19] <RAOF> darkxst: If it doesn't pass -mir $SESSION_ID to /usr/bin/Xorg, it's starting X.
[07:19] <RAOF> Technically, even if it *does* pass
[07:19] <RAOF> Technically, even if it *does* pass -mir $SESSION_ID to /usr/bin/Xorg it's starting X :)
[07:20] <mlankhorst> RAOF: I don't think it does atm, though
[07:21] <RAOF> mlankhorst: Right. At the moment we're all threads, all the time. I think tvoss_ is amenable to also exporting an eventfd, which should get rid of the annoying thread-to-eventloop hack.
[07:22] <mlankhorst> \o/
[07:22] <mlankhorst> RAOF: I was thinking something like pulse mainloop
[07:22] <mlankhorst> it may not be perfect, but it's understood
[07:22] <RAOF> darkxst: Correct. If you wanted to use XMir+unity-system-compositor from gdm you'd need to patch gdm to (a) start unity-system-compositor, (b) pass the appropriate arguments to X, and (c) send session-switching commands to unity-system-compositor.
[07:22] <mlankhorst> and if you don't want a separate thread you don't need to, afaik
[07:22] <tvoss_> RAOF, yup, but it will take until next week, my plate is kinda full at this point
[07:23] <mlankhorst> it was awesome for wine, where I do need a separate thread, but I need to create the thread in wine itself
[07:24] <tvoss_> mlankhorst, the idea is to expose run, run_one, poll, poll_one and have an fd that signals when there is work to do
[07:25] <mlankhorst> tvoss_: yeah pulseaudio does something like that
[07:25] <tvoss_> mlankhorst, ack, will look into it beginning of next week
[07:32] <didrocks> RAOF: ignoring me? :p
[07:32] <darkxst> RAOF, ok, that doesnt seem really bad.... but I also guess it wouldnt actually end up being that straight forward
[07:32] <RAOF> didrocks: ?
[07:32] <didrocks> 09:18:18      didrocks | RAOF: btw, do you think that we can expect this patched Xorg going quickly to saucy once we resolved the minor issues around Mir to enter distro?
[07:33] <RAOF> Oh! Yes
[07:33] <RAOF> baby
[07:33] <darkxst> RAOF, what about further down the track though, when gnome moves to wayland. Would it be possible to have Mir system compositor and Wayland Session Compositor in harmony?
[07:39] <RAOF> didrocks: Yes. You don't need anything from me for that to happen except an upload of a patched xserver to the archive, right?
[07:39] <RAOF> darkxst: That's less clear; basically what it requires is for GNOME's compositor to have a Mir backend.
[07:40] <darkxst> RAOF, that won't happen
[07:40] <seb128> good morning desktopers
[07:40] <darkxst> hi seb128
[07:40] <seb128> I like how opensource dev keep stating that things won't happen
[07:40] <didrocks> RAOF: that's my understanding for now. I do expect surprises of course, but I trust at least your side ;)
[07:40] <seb128> when anyone can come and make them happen
[07:40] <didrocks> salut seb128
[07:40] <tvoss> RAOF, or to be more clear, a wayland backend rendering to Mir
[07:40] <RAOF> darkxst: No. I don't mean for GNOME's compositor to be built on Mir; I mean for GNOME's compositor to be able to run under Mir. Like how Weston can currently run under Weston.
[07:41] <seb128> hey didrocks, tvoss, RAOF, darkxst
[07:41] <tvoss> seb128, hey
[07:41] <RAOF> tvoss: Except of course that's a misunderstanding of what Wayland *is*
[07:41] <tvoss> RAOF, exactly ;)
[07:41] <RAOF> There are no ‘Wayland backends’, because Wayland is not a display server.
[07:41] <tvoss> RAOF, for sure
[07:42] <tvoss> darkxst, I'm curious, do you see any technical issue preventing the GNOME compositor from talking to Mir?
[07:43]  * RAOF wonders if we could come up with a nomenclature that accurately described the state of things
[07:43] <darkxst> tvoss, I don't know a whole lot about the deeper workings of mutter
[07:43] <tvoss> darkxst, ah, okay, I thought you were referring to a technical issue when saying that it won't happen
[07:43] <RAOF> darkxst: AIUI mutter builds on clutter, which already has a perfectly servicable pluggable backend system.
[07:44] <darkxst> but as I understand it, Wayland+X is enough of a pain, that its really unlikely they would add Mir into the mix
[07:44] <seb128> so much of those comments a just direct reaction against change/something different that some people planned...
[07:44] <RAOF> Eh. Almost all the pain is in having the abstraction in the first place. Adding an extra target, while certainly annoying, is only incrementally annoying.
[07:45] <tvoss> RAOF, +1, and the exercise of adding another target helps in shaping the abstraction layer
[07:45] <tvoss> I think the pain in switching away from X is that everything is entangled there for historic reasons
[07:45] <seb128> not sure how realistic it will get to run GNOME on !GNOME-OS over time anyway
[07:45] <didrocks> RAOF: diagrams generally help by experience, people can dive to the level they want
[07:45] <seb128> they hard depends on their login manager, they increasingly depends on systemd, they are going to depends on wayland
[07:46] <tvoss> didrocks, but RAOF is right, the nomenclature is emphasiizing misunderstandings
[07:46] <seb128> swapping desktops easily is becoming a thing of the past
[07:46] <didrocks> tvoss: not disagreeing with this :)
[07:46] <seb128> when your desktop is tied to an init system, a login manager, a display server, etc ... and different desktops pick different techs for all of those you actually end up have distro specific desktops
[07:47] <didrocks> ok, just one MIR remaining (liborcus) for Sweetshark, that will wait some hours :p
[07:47]  * didrocks adds to the confusion on purpose, it's Friday! ;)
[07:49] <darkxst> seb128, it actually sounded like they weren't entirely against getting lightdm working with gnome-shell
[07:50]  * tvoss wonders why a session has to make assumptions from where it was started
[07:50] <seb128> tvoss, it doesn't, until it uses the greeter from the login manager as lock screen...
[07:50] <darkxst> tvoss, under gnome, authentication for lock screens etc, is piped to gdm
[07:51] <tvoss> darkxst, seb128 wouldn't that be solved more elegantly with a common interface implemented by both gdm and lightdm?
[07:51] <seb128> it would, robert_ancell tried to add a gdm compatible greeter to lightdm
[07:51] <seb128> but I'm not sure he finished, he got busy with Mir :p
[07:52] <tvoss> seb128, where is the interface defined?
[07:55] <seb128> tvoss, I'm not sure, the GNOME guys didn't really spec it or made it public/documented ... robert_ancell would know better, I think he just looked a the gdm
[07:55] <tvoss> seb128, interesting
[07:57] <seb128> tvoss, https://github.com/robert-ancell/gnome-shell-lightdm
[07:57] <tvoss> seb128, okay
[07:57] <tvoss> seb128, thx
[07:57] <seb128> yw
[07:58] <tvoss> seb128, are you aware of any attempts to standardize the dbus interfaces here?
[07:58] <seb128> no
[07:58] <seb128> I think everyone has been focussing on making their desktop work with the components they picked
[07:58] <seb128> and nobody went out of the way to spend time trying to standardize things or making them swappable
[07:59] <darkxst> sure, but the main issue is the authentication channel, gnome-shell renders the lock screen
[08:01] <Laney> hey, happy friday
[08:01] <darkxst> in fact gnome-shell also renders the gdm login screen, but that is largely irrelavant for the lightdm use case.
[08:02] <seb128> Laney, hey, happy friday to you too!
[08:02] <darkxst> Laney, hi, I am up to happy weekend here :)
[08:02] <Laney> :P
[08:03] <Laney> but you have unhappy monday before me so ;-)
[08:04] <darkxst> Laney, usually that is tired monday.... but oh well!
[08:05] <Laney> btw I finally fell off my bike the other day :(
[08:05] <Laney> while trying to look at the map I forgot I was clipped in and tried to put my foot on the floor
[08:05] <Laney> bad idea
[08:06] <darkxst> Laney, I fell too, in the dark..... huge bruised and a bit of lost skin... but ready for another weekend!
[08:07] <darkxst> MTB in the dark is probably a little dangerous ;(
[08:07] <Laney> yes, yes indeed
[08:08] <darkxst> although we don't have much choice, its getting dark by about 5.30pm now
[10:05] <seb128> oh
[10:07] <seb128> since when does launchpad automatically adds packages/lines to bugs when you use "lp: #nnn" to an upload?
[10:07] <seb128> e.g https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1194844
[10:07] <ubot2`> Ubuntu bug 1194844 in Ubuntu UI Toolkit "[ListItem.SingleControl] Does not respect the default inner margins" [Medium,Confirmed]
[10:07] <seb128> didrocks, is that launchpad or your daily release magic?
[10:07] <seb128> comment #4 and #5
[10:08] <seb128> it's a bit funny, that's a toolkit bug
[10:08] <seb128> I just add "  *until bug ... is fixed in the ui toolkit" for reference to my comment
[10:08] <seb128> the daily magic added the lp # reference for that bug
[10:09] <seb128> then something added the sources to the bug
[10:09] <seb128> too much magic ;-)
[10:10] <didrocks> seb128: that's launchpad :)
[10:10] <didrocks> hum
[10:10] <didrocks> ubuntu-system-settings-online-accounts and ubuntu-system-settings
[10:10] <seb128> it's quite nice, we got bitten quite often by bugs don't getting closed because of component mismatches between source uploaded and bug
[10:10] <didrocks> 2 different packages?
[10:10] <seb128> yes
[10:11] <seb128> online-account is a standalone source
[10:11] <didrocks> ah
[10:11] <didrocks> you wrote:
[10:11] <didrocks> (until bug
[10:11] <didrocks>     #1194844 is fixed in the ui toolkit)
[10:11] <didrocks> so it's been detected as a bug
[10:11] <didrocks> and added LP: …
[10:11] <seb128> right
[10:11] <didrocks> see the FAQ ;)
[10:11] <seb128> yeah, I got that part
[10:11] <seb128> what confuses me is that something did "also affect ubuntu-system-settings-online-accounts" on the bug
[10:12] <seb128> and set that to fix released on upload
[10:12] <seb128> where in the past uploads on the wrong source would just go to /dev/null
[10:12] <didrocks> ah, the also affect is daily release :p
[10:12] <didrocks> if it detects bugs to close
[10:12] <didrocks> it's opened the components
[10:12] <seb128> ok, so not launchpad
[10:12] <didrocks> opening*
[10:12] <seb128> I see ;-)
[10:12] <didrocks> yep
[10:12] <seb128> didrocks, thanks
[10:12] <didrocks> as a lot of upstreams just opens the upstream bugs
[10:12] <didrocks> makes things easier to track
[10:12] <seb128> that makes sense
[11:54] <Laney> http://forums.mozillazine.org/viewtopic.php?f=23&t=2722493
[11:54]  * Laney sniggers
[11:59] <seb128> Laney, O_o
[12:02]  * xnox likes the 2015 design a lot
[12:02] <Laney> let's vendor patch it in now to be ahead of the curve
[12:03] <Laney> chrisccoulson: ^ make it so
[12:03] <ogra_> ubuntu - flatter than apple !
[12:20] <jbicha> does 'signon' need to do an automatic snapshot every day?
[12:21] <seb128> nothing needs to
[12:21] <seb128> but that's the purpose of daily releases
[12:21] <seb128> if there is a commit it's released
[12:21] <seb128> that's try for the whole unity stack
[12:21] <seb128> why?
[12:21] <jbicha> but there aren't commits AFAIK https://code.launchpad.net/~online-accounts/signon/trunk
[12:22] <jbicha> I don't mind daily releases when minor things change
[12:22] <seb128> seems like a bug
[12:22] <seb128> didrocks, ^
[12:22] <seb128> oh
[12:23] <seb128> ignore the "oh"
[12:23] <xnox> seems like it think it's own changes are the changes to release again.
[12:23] <Laney> looks like that has been happening a lot!
[12:24] <attente> pitti, hi
[12:24] <attente> pitti, which menus are missing from gtimelog?
[12:24] <seb128> yeah, there is a bug somewhere which leads it to think there is a new change to land when there is none
[12:25] <pitti> attente: there is no global menu for it, it has an integrated menu
[12:25] <pitti> attente: hey, how are you?
[12:26] <Laney> I get a global menu for it here but it suffers from the same bug as virt-manager
[12:26] <attente> pitti, i'm good, and you?
[12:26] <attente> pitti, my experience is the same as Laney
[12:26] <pitti> attente: I'm well, thanks
[12:27] <pitti> attente: I don't think it's just me, fginther noticed the same
[12:27] <seb128> pitti, do you have integrated menus for any gtk2 app? e.g inkscape or xchat?
[12:27] <pitti> attente: or rather, autopilot-gtk has a test which assumes that the GtkMenuItems are visible
[12:27] <seb128> pitti, you guys maybe don't have the -gtk2 installed?
[12:27] <Laney> yeah maybe you miss unity-gtk2-module
[12:27] <pitti> attente: and it succeeds on saucy, but fails on raring because global menu was working there
[12:28] <pitti> attente, seb128: gtimelog and my test program are both gtk3 and GI
[12:28] <pitti> let's not worry about old gtk2 stuff
[12:28] <seb128> oh, I though that was still gtk2
[12:28] <seb128> pitti, do you test on raring?
[12:28] <seb128> (don't do that)
[12:28] <pitti> seb128: test what?
[12:28] <pitti> seb128: global menus were working fine on raring, yes
[12:28] <seb128> "it succeeds on saucy, but fails on raring b"
[12:28] <seb128> saucy works?
[12:29] <pitti> seb128: that was my ap-gtk test case which assumed builtin menus
[12:29] <pitti> I fixed the test now to use UBUNTU_MENUPROXY=0
[12:29] <seb128> can you summarize what work where?
[12:29] <pitti> but that's just how I noticed it, and that it's not just me
[12:29] <pitti> so the summary is:
[12:29] <pitti> - gtimelog had a global menu until raring
[12:29] <pitti> - gtimelog has an integrated (non-global) menu in saucy
[12:29] <pitti> and that looks like a regression to me
[12:29] <pitti> unless there was some policy change or so
[12:30] <seb128> should not
[12:30] <seb128> it works for me (but with the quit item labeled "gtk-quit")
[12:30] <attente> is u-g-m even available under raring?
[12:30] <seb128> no, ignore raring, I think he's saying that it was working with dbusmenu there
[12:31] <pitti> yes, it was
[12:31] <seb128> the issue is that saucy doesn't work for him
[12:31] <attente> ah, sorry
[12:31] <seb128> which I can't confirm (out of the "quit" item being wrong labelled)
[12:31] <pitti> the regression in saucy is that some programs don't have a global menu any more, with gtimelog being one example
[12:31] <desrt> good morn, pitti, seb128
[12:31] <pitti> hey desrt
[12:31] <seb128> desrt, hey, happy friday to you!
[12:31] <desrt> friday :D
[12:32] <desrt> that calls for a coffee to celebrate
[12:32] <pitti> attente, seb128: so maybe fginther and I both have some new package not installed?
[12:32] <seb128> pitti, could be, but it wouldn't be working for any gtk3 app if that was the case
[12:32] <pitti> I guess the underlying mechanics have changed for the global menu?
[12:32] <seb128> right, it's a .so loaded by gtk
[12:32] <seb128> which relies on the env to list it
[12:33] <seb128> but that's true for any app
[12:33] <seb128> that wouldn't explain some apps working and some not
[12:33] <desrt> maybe someone is scrubbing the env?
[12:33] <desrt> chpe tried to do this....
[12:33] <seb128> well, the same software works for Laney or I
[12:33] <desrt> huh
[12:33] <attente> i've got the global menu as well..
[12:34] <seb128> debugging required I guess...
[12:34] <desrt> maybe they got crafty and added exceptions for the usernames who were likely to be packaging it :)
[12:34] <attente> haha
[12:34] <seb128> pitti, you have the issue on your box, where other gtk3 apps work fine and starting apps the same way?
[12:34] <pitti> seb128: yes
[12:34] <pitti> actually, no
[12:34] <desrt> pitti: does it hide the local menu bar, or is it still shown?
[12:34] <pitti> if I launch gedit from a termina, it also has a builtin menu
[12:35] <seb128> pitti, env | grep GTK
[12:35] <pitti> $ env|grep GTK
[12:35] <pitti> GTK_MODULES=overlay-scrollbar
[12:35] <seb128> buggy
[12:35] <desrt> pitti never logs out/in :)
[12:35] <desrt> so he misses the new envvar :p
[12:35] <attente> ah...
[12:35] <pitti> seb128: but when I launch gedit from dash, I also get a builtin menu
[12:35] <desrt> OH
[12:35] <pitti> so gedit and gtimelog both have the bug, regardless of whether I launch from dash or terminal
[12:35] <desrt> this _is_ chpe's fault
[12:35] <seb128> pitti, see /etc/X11/Xsession.d/80...
[12:35] <pitti> desrt: I boot my machine every day
[12:36] <desrt> gnome-terminal at some point was scrubbing those environment variables
[12:36] <pitti> it's not related to g-t
[12:36] <desrt> and of course anything you launch from the terminal is a subprocess of the terminal
[12:36] <pitti> for i in /usr/lib/*/gtk-2.0/2.10.0/menuproxies/libappmenu.so
[12:36] <pitti> seb128: ^ that looks gtk2 specific
[12:36] <seb128> pitti, that's deprecated
[12:36] <desrt> pitti: ah sorry.  i misread your previous statement about the dash
[12:37] <Laney> pitti: what's $UBUNTU_MENUPROXY?
[12:37] <pitti> $ echo $UBUNTU_MENUPROXY
[12:37] <pitti> libappmenu.so
[12:37] <seb128> that's wrong
[12:37] <seb128> you seems to be missing the conffile for the new unity menus
[12:37] <pitti> grep -r UBUNTU_MENUPROXY /etc/
[12:37] <pitti> /etc/X11/Xsession.d/80appmenu-gtk3:export UBUNTU_MENUPROXY="libappmenu.so"
[12:37] <Laney> I think maybe 80unity-gtk-module is wrong
[12:37] <Laney> it should just overwrite it
[12:38] <seb128> it seems like he doesn't have it installed...
[12:38] <pitti> $ dpkg -S /etc/X11/Xsession.d/80appmenu-gtk3
[12:38] <pitti> appmenu-gtk3:amd64: /etc/X11/Xsession.d/80appmenu-gtk3
[12:38] <seb128> pitti, that's the old stuff, that's deprecated
[12:38] <Laney> did it depend on some unity/gtk thing which got removed?
[12:38] <seb128> pitti, do you have the file Laney just mentioned?
[12:38] <Laney> look /in/ the file
[12:39] <Laney> ah, wait, it should do that right
[12:39] <seb128> Laney, it seems like he's missing the conffile
[12:39] <seb128> or the -common package that includes it
[12:39] <Laney> yeah
[12:39] <seb128> but that's weird, why would menu work from unity then?
[12:39] <pitti> no, I don't have that
[12:40] <seb128> pitti, dpkg -l | grep unity-gtk
[12:40] <pitti> seb128: perhaps that's still using the old dbusmenu stuff?
[12:40] <pitti> which package ships that file?
[12:40] <seb128> pitti, I made gtk2/3 conflict on the old stuff
[12:40] <seb128> pitti, dpkg -l | grep unity-gtk
[12:40] <Laney> indicator-appmenu Recommends them
[12:40] <attente> unity-gtk-module-common
[12:40] <Laney> so ... you could easily not have gotten it
[12:40] <pitti> seb128: nothing
[12:41] <seb128> pitti, that's your issue, recommends didn't get installed
[12:41] <seb128> pitti, does apt-get --fix-recommends (or whatever that option is called) try to install them?
[12:41]  * seb128 googles
[12:41] <Laney> --fix-policy --install-recommends
[12:41] <seb128> pitti, ^
[12:42] <pitti> that wants to remove appmenu-gtk appmenu-gtk3 and install a gazillion packages
[12:42] <seb128> great
[12:42] <attente> i thought we had a hard Depends on unity-gtk-module-common?
[12:42] <seb128> "we"?
[12:42] <seb128> no, unity recommends the menu stuff
[12:42] <seb128> because some people want to opt out
[12:43] <pitti> seb128: installing unity-gtk-module-common doesn't remove the appmenu stuff, though
[12:43] <seb128> so we let them uninstall those without removing unity
[12:43] <seb128> pitti, that's ok, it has a conffile that override the appmenu one
[12:43] <Laney> I don't think it matters if it's not removed as u-g-m will take over
[12:43] <attente> but shouldn't installing unity-gtk23-module force the installation of the -common?
[12:43] <seb128> pitti, we needed that anyway because uninstall != purge
[12:43] <Laney> attente: he didn't have any of it
[12:43] <jbicha> if there was an easier way for users to opt out of the global menu then you could make it a depends
[12:44] <seb128> there is an easy way
[12:44] <seb128> change the env variable
[12:44] <pitti> done
[12:44] <Laney> does gtk ignore not found GTK_MODULES?
[12:44] <seb128> not sure, it might throw warning at those
[12:44] <Laney> seems you get a warning ... that file ought to check if the libraries exist then
[12:44] <pitti> Laney: yes, you only get a warning
[12:45] <jbicha> well I think dconf is more user-friendly (because it can be a GUI) than messing with environment variables
[12:45] <seb128> right, we should probably add that
[12:45] <Laney> yeah, doesn't seem like u-g-m has any bad dependencies
[12:45] <Laney> file a bug? :)
[12:46] <jbicha> like overlay scrollbars have a dconf key :)
[12:46] <seb128> gsettings
[12:46] <seb128> but yeah
[12:47] <seb128> we can maybe add it to gsettings-desktop-schemas :p
[12:47]  * seb128 hides
[12:47] <attente> lol
[12:47] <jbicha> lol
[12:48]  * jbicha adds goa dependencies everywhere
[12:49] <ogra_> dont forget ubuntu touch !
[12:49] <ogra_> :P
[12:50] <seb128> ogra_, oh, he started there, don't worry
[12:50] <ogra_> ah, phew
[12:50] <ogra_> :)
[12:50] <seb128> ogra_, GNOMers are eager to get GTK on the device ;-)
[12:50] <ogra_> hehe
[12:50] <seb128> (even if it can't get to the screen (yet))
[12:50] <ogra_> XMir might help
[12:50] <seb128> yep
[12:51] <ogra_> and who wouldnt want to run evolution on a 4" screen !
[12:52] <ogra_> (in desktop mode at 1080p resolution indeed(
[12:52] <Laney> sounds like the converged way
[12:53] <jbicha> needs more whitespace padding :)
[12:55] <desrt> seb128: you said that debian has super-up-to-date gnome these days....
[12:55] <desrt> i'm seeing only 3.4?
[12:56] <seb128> desrt, http://www.0d.be/debian/debian-gnome-3.8-status.html
[12:56] <seb128> desrt, do you run debian stable? ;-)
[12:56] <desrt> is that sid?
[12:56] <desrt> seb128: i don't run debian anything... was just looking into your claims the other day
[12:57] <seb128> desrt, http://packages.qa.debian.org/nautilus
[12:57] <jbicha> technically saucy has more GNOME 3.8 than sid because Debian has transitions that take weeks
[12:57] <didrocks> seb128: jbicha: I would say there is a diff between trunk and the source package, ken should investigate I guess (and looking at those :p)
[12:57] <seb128> desrt, experimental for 3.8 atm, though they are moving pieces to unstable
[12:58] <seb128> didrocks, is that flagged somewhere? shouldn't the stack be blocked with manual approval required for those?
[12:58]  * desrt always gets confused with stable kinda-stable (next), unstable (sid), super-unstable (experimental?), ultra-mega-unstable (testing?)
[12:58] <Laney> what's next?
[12:58] <seb128> desrt, well, experimental was used as an unstable because debian was frozen for 6 months for their release
[12:58] <seb128> desrt, they are getting stuff back to unstable but didn't go too crazy, they do transition decoupled and in order
[12:58] <didrocks> seb128: hum, why? the diff means "something changed", it's how it detects there is something to release
[12:58] <seb128> desrt, so it takes a bit of time
[12:59] <didrocks> but in that case, it seems that the source package produced by bzr bd -S and trunk is different
[12:59] <desrt> seb128: and where does testing fit in?
[12:59] <seb128> didrocks, I though "packaging changes" would block the publishing for review?
[12:59] <didrocks> and that's a packaging bug
[12:59] <didrocks> seb128: there is no packaging change, right?
[12:59] <Laney> I thought you diffed the to-be-uploaded source package and the archive
[12:59] <seb128> didrocks, sorry, I misread your "diff between trunk and the source package"
[12:59] <didrocks> Laney: no, we diff trunk with the archive
[13:00] <didrocks> Laney: I thought this week we can do a 2 stage thing, but we'll have in that case bugs like this spawning
[13:00] <Laney> mmm
[13:00] <seb128> desrt, testing is a transitionnal pocket ... but before release they freeze unstable mostly and transition bits ready from that small set
[13:01] <desrt> seb128: so experimental is the most-unstable one
[13:01] <desrt> thanks :)
[13:01] <Laney> experimental is optional
[13:01] <seb128> desrt, yes stable < testing < unstable < experimental
[13:01] <Laney> for both developers and users
[13:01] <Laney> you don't even get packages from it automatically if you enable it
[13:01] <didrocks> Laney: creating the source package needs a pbuilder chroot to be cleaned, it's not something we can do for the 233 components right now without killing the machine
[13:02] <didrocks> hence the diff between trunk (ignoring .bzr*/ + diff we ignore) and the archive source
[13:02] <seb128> desrt, stable is like ubuntu stable, testing is like the unstable release nowadays (with extra delay), unstable is like unstable-proposed (where stuff get uploaded, they migrate to testing if they are not breaking the world), experimental is sort of ppa land
[13:02]  * desrt really likes the ppa model
[13:03] <Laney> debian's getting something like that
[13:03] <desrt> lovely!
[13:03] <Laney> even with 'official' PPAs
[13:03] <Laney> which will be cool
[13:03] <desrt> PPAs are perhaps the coolest of the canonical inventions
[13:03] <Laney> and I think semi-automatic migration from them to the archive
[13:03] <seb128> I wish debian would get ddebs :p
[13:03] <desrt> in terms of launchpad features....
[13:03] <Laney> i'm sure it can if someone does the work :P
[13:03]  * seb128 is tired of all those -dbg flowing in through debian
[13:04] <desrt> speaking of which
[13:04] <desrt> pitti: did you do any looking at that minidebug stuff?
[13:13] <didrocks> Laney: I have an idea (while having my shower)!
[13:13] <didrocks> so, still having this diff between trunk and the archive source
[13:13] <Laney> gosh!
[13:13] <didrocks> if diff -> use cowbuilder to build the source package
[13:13] <seb128> kenvandine, starting your day with reviews?
[13:13] <didrocks> then, rediffing against between the 2 sources
[13:13] <Laney> I've never built source packages in a clean environment
[13:13]  * seb128 was just looking at Laney's work and noticed the comments flowing
[13:13] <Laney> has it been a problem for you?
[13:14] <didrocks> Laney: force with python2, all the dh_* things called on debian/rules clean
[13:14] <didrocks> that I don't want to install on the machine :)
[13:14] <didrocks> if the second diff has:
[13:14] <didrocks> - only changes in debian/changelog
[13:14] <didrocks> - less or equals than 6 new lines in it
[13:14] <kenvandine> seb128, yup :)
[13:14] <Laney> build with -nc; there shouldn't be stuff to clean up in a fresh checkout
[13:14] <didrocks> -> no upload
[13:15] <didrocks> but put the job in warning
[13:15] <seb128> kenvandine, I see how your ignored the harder one with signals though :p
[13:15] <didrocks> Laney: doesn't work even with -nc, some rules includes some .mk files
[13:15] <Laney> ah well I have things like that installed
[13:15] <didrocks> and it failed :p
[13:15] <didrocks> yep, not on the host
[13:15] <kenvandine> seb128, still reviewing :)
[13:15] <didrocks> knowing that we always have some of those helpers evolving
[13:15] <kenvandine> i got side tracked by fixing things that didn't match the design :)
[13:16] <didrocks> and just one machine on an old release that is shared with other stuff :p
[13:16] <didrocks> kenvandine: hey! before that, there are some stuff to fix on online-accounts :)
[13:16] <Laney> get yourself a nice container or do it in ... the ... cloud!
[13:16] <Laney> anyway, the 'if diff' wouldn't have triggered in this case would it?
[13:16] <didrocks> Laney: the container is cowbuilder :p
[13:17] <kenvandine> didrocks, i'll look at those in a few
[13:17] <Laney> I mean one you can reuse
[13:17] <Laney> if the expense is reconstructing everything all the time
[13:17] <didrocks> kenvandine: like another source you had, there are a diff between the packaging and archive (so generated source) isn't empty
[13:17] <didrocks> kenvandine: so it triggers dailies… daily :p
[13:17] <didrocks> Laney: well, cowbuilder is something like that
[13:17] <didrocks> Laney: but when you build webapps, you have 30 sources at the same time
[13:17] <didrocks> and installing all the build-deps/refreshing them takes time
[13:18] <didrocks> so better to ensure we do it as clean as possible
[13:18] <Laney> you can have one with the 'clean' build-deps installed
[13:18] <didrocks> Laney: you still have to update them
[13:18] <Laney> yeah, but not every time you build a package
[13:18] <didrocks> I think the current system at least doesn't need "setup"
[13:18] <Laney> I don't think most developers do that
[13:18] <didrocks> yep, but we raise the quality bar :p
[13:18] <Laney> a *source* package
[13:19] <didrocks> Laney: so, the double diffing can works and prevent that
[13:19] <didrocks> turning the job in a warning
[13:19] <Laney> I don't think I understand the part where you decide whether to do the second diff
[13:20] <didrocks> if the diff shows there is something to build
[13:20] <didrocks> (between trunk and the archive source)
[13:20] <didrocks> so, we fire up our cowbuilder
[13:20] <didrocks> collect commits, and so on…
[13:20] <didrocks> then build our source package
[13:21] <didrocks> and do that second diff between archive and source package
[13:21] <Laney> ah
[13:21] <Laney> so why the line count thing?
[13:21] <didrocks> if we just have changes in debian/changelog (and less or equals than 6 lines), it means that the diff is useless
[13:21] <Laney> Can't you just say "only changes in debian/changelog -> ignore"
[13:21] <didrocks> Laney: because maybe you want to force a rebuild?
[13:21] <didrocks> like bumping the version
[13:21] <Laney> I thought that was done in the machinery
[13:21] <Laney> with some force flag that would bypass such checks anyway
[13:22] <didrocks> Laney: that's planned, not the case yet, but in that case, it will add some line
[13:22] <didrocks> Laney: but sometimes, upstream just want to bump the version
[13:22] <didrocks> in that case, the contract is bump the version + a line like "* bump version" (or whatever)
[13:23] <didrocks> so, we'll have 7 lines with the "automatic snapshot from rev…"
[13:23] <didrocks> kenvandine: http://bazaar.launchpad.net/~online-accounts/signon/trunk/revision/591 FYI
[13:23] <didrocks> Laney: would you be that kind to open a bug? :)
[13:23] <didrocks> I'll deal with this on Monday I guess
[13:24] <didrocks> (finishing building Mir on the nexus 4)
[13:24] <Laney> didrocks: OK, what's the component
[13:24] <didrocks> Laney: cupstream2distro
[13:25] <didrocks> jbicha: btw, just ping me once both cheese and gnome-video-effects are fixed, I'll then promote them
[13:25] <jbicha> didrocks: thanks, will do :)
[13:25] <didrocks> yw :)
[13:26] <Laney> doing
[13:29] <sil2100> eh
[13:29] <sil2100> hm
[13:29] <sil2100> didrocks: does jenkins work for you?
[13:29] <didrocks> oh a sil2100!
[13:30]  * didrocks looks
[13:30] <didrocks> sil2100: seems so :)
[13:30] <didrocks> sil2100: try disconnect/reconnect to the VPN
[13:30] <sil2100> didrocks: ok, worked
[13:31] <sil2100> didrocks: uhoh, the unity check job is running since 4 hours
[13:31] <didrocks> sil2100: yep, see #ubuntu-unity, just pinged mhr3
[13:31] <didrocks> sil2100: ati results are quite high?
[13:32] <sil2100> didrocks: yes, much higher then what we got in the morning ;/ In the morning we had 19/19 failures
[13:32] <didrocks> sil2100: still higher than the threshold though
[13:33] <sil2100> Not sure if we can release just the indicator stack though
[13:33] <didrocks> sil2100: maybe check with upstream & cyphermox?
[13:52] <kenvandine> didrocks, what's up with the webcred stack?  it's all green
[13:52] <kenvandine> although it was published 5 hours after the build
[13:52] <kenvandine> so maybe someone manually did that while i was sleeping :)
[14:00] <didrocks> kenvandine: look at the uploads for signon :p
[14:01] <didrocks> empty uploads
[14:01] <didrocks> that's because trunk is different than bzr bd -S
[14:01] <didrocks> (the source package created)
[14:01] <didrocks> as for another one you fixed
[14:03] <kenvandine> shouldn't prepare had failed?
[14:04] <kenvandine> seb128, can you give me an uoa settings review?
[14:04] <kenvandine> https://code.launchpad.net/~ken-vandine/ubuntu-system-settings-online-accounts/category/+merge/172039
[14:04] <seb128> kenvandine, looking
[14:04] <kenvandine> easy one :)
[14:04] <kenvandine> there is nobody else from ~online-accounts for the next week
[14:05]  * kenvandine will be lonely
[14:05] <kenvandine> :)
[14:05] <seb128> kenvandine, great, approved (but you need to change the mr status, I don't have access)
[14:05] <kenvandine> sure
[14:05] <kenvandine> thx
[14:14] <jbicha> attente: hey, maybe we should just talk here instead of on the MP :)
[14:16] <jbicha> attente: I think it's acceptable for Unity to depend on indicator-keyboard instead of gnome-control-center if the indicator-keyboard specific code only runs in Unity
[14:17] <didrocks> kenvandine: why? there is a diff for it, it's how it detects it :)
[14:18] <didrocks> kenvandine: I have an idea on how to show the triggering diff automatically in the future, but I would appreciate if you can fix it meanwhile :)
[14:20] <Sweetshark> didrocks: do we really need the MIR redtape to get libzip-dev into main? We can carefully examine if the source package is suitable for main, but in the end I would guess it is ... as the _source_ package is already in main.
[14:20] <sil2100> didrocks: can you ACK some packaging diffs ;) ?
[14:22] <kenvandine> didrocks, will do
[14:22] <didrocks> sil2100: can you get ken or cyphermox acking them? I have one request every 20s here :p
[14:22] <sil2100> ;) If their ACKs count as archive admin's ACK, then no problem!
[14:22]  * sil2100 wants to publish indicators
[14:23] <sil2100> They're mostly symbol cleanups and dependencies removals
[14:24] <didrocks>     libzip | 0.10.1-1.1 | saucy/universe | source
[14:24] <didrocks> Sweetshark: the source is in universe, not main
[14:24] <didrocks> did you check? ;)
[14:24] <didrocks> sil2100: it's not an archive admin ack you need, just someone with upload rights for those :)
[14:25] <Sweetshark> didrocks: well, I did check, but in the maze of lp I didnt notice I was on precise ...
[14:26] <attente> jbicha, sure
[14:27] <attente> seb128, you're ok with jbicha's solution?
[14:28] <seb128> attente, what solution is that?
[14:28] <attente> to have unity depend on i-keyboard
[14:28] <seb128> sure
[14:28] <cyphermox> sil2100: ack for ido
[14:28] <seb128> but the reason why I suggested to move the schemas is that you said gnome-settings-daemon needed it IIRC
[14:30] <cyphermox> sil2100: ack for indicator-datetime
[14:31] <sil2100> \o/
[14:31] <sil2100> cyphermox: thanks!
[14:31]  * sil2100 readies his cu2d-run
[14:31] <Sweetshark> didrocks: bug 1195761
[14:31] <ubot2`> Launchpad bug 1195761 in libzip (Ubuntu) "[MIR] libzip" [Undecided,New] https://launchpad.net/bugs/1195761
[14:31] <cyphermox> ack for indicator-power
[14:31] <attente> seb128, sorry if i did, that was a mistake
[14:31] <didrocks> Sweetshark: you did check that all build-deps and deps are in main for that one? :)
[14:31] <cyphermox> I'm concerned that all those might not show up in the panel though
[14:32] <seb128> attente, ok, no worry, so yeah, unity depending on indicator-keyboard works for me (or Recommends as we do for other indicators)
[14:35] <cyphermox> sil2100: yeah, all ack; but I'd install them locally first to make sure they really show... some indicators were converted to indicator-ng and I'm doubtful :)
[14:35] <Sweetshark> didrocks: its the same upstream release that was in main in precise. If it needs additional deps, I will club the one who did bring them in with a trout ...
[14:36] <didrocks> Sweetshark: well, opening a MIR bug is not asking someone else checking the MIR criterias
[14:36] <didrocks> Sweetshark: it's you doing the check, then someone else acking
[14:38] <xnox> Sweetshark: talk to infinity, i wouldn't have thought package requires mir at all, since it's same as in precise and still supported in precise and hasn't been changed.
[14:39] <xnox> used to be a build-dep of kdeutils.
[14:59] <didrocks> have a good week-end everyone!
[14:59] <didrocks> sil2100: enjoy your holidays :)
[15:00] <pitti> desrt: minidebug> no, not since we talked; I tracked down the missing ELF headers in coredumps for build IDs, which can help us to improve our debug symbols, but not minimizing existing symbols
[15:00] <pitti> desrt: I thought that wasn't necessary any more with your assertion msg changes in glib?
[15:01] <sil2100> \o/
[15:02] <sil2100> cyphermox: testing and publishing if all ok
[15:03] <sil2100> Seems ok, publishiiing!
[15:06] <seb128> pitti, did you get your menus to work?
[15:07] <pitti> seb128: I haven't rebooted since then, but I guess that was the problem
[15:07] <seb128> pitti, ok
[15:08] <seb128> sil2100, no no no
[15:08] <seb128> sil2100, did you publish indicators?
[15:24] <sil2100> seb128: yes...
[15:24] <sil2100> ...regression?
[15:25] <sil2100> (Friday releases are really a bad idea
[15:26] <sil2100> )
[15:27] <seb128> sil2100, I guess so, did you try those
[15:27] <seb128> sil2100, I was just talking to charles and larsu an hour ago because I tried indicator-datetime trunk, custom items don't work in saucy
[15:27] <seb128> sil2100, e.g no calendar widget in the menu, no timezone, no color for appointements
[15:27] <sil2100> seb128: are there no integration tests for those?
[15:28] <seb128> I guess not
[15:28] <seb128> the items are there
[15:28] <seb128> just the calendar is a text line "[Calendar]"
[15:28] <seb128> rather than a calendar widget
[15:39] <charles> seb128: I think all that's missing is a one-liner call to ido_init() so u-p-s will know to look for the custom widgets in IDO
[15:40] <charles> seb128: so even though it looks terrible now, it should look less terrible RSN
[15:40] <seb128> charles, hum ok, do you know why that wasn't tested/added before those got merged in trunk?
[15:40] <seb128> charles, we just regressed saucy with that landing, going to be an issue and late friday work now for some of us to sort it out :-(
[15:43] <charles> seb128: no I don't, I wasn't the one on that integration
[15:44] <sil2100> ;/
[15:45] <sil2100> I think we need an integration test for that, at least a simple 'click the calendar indicator and check if it's visible'
[15:45] <seb128> sil2100, right, ordering of indicator is broken as well with those updates...
[15:52] <sil2100> charles, seb128: can we have someone fixing that? We might re-run the stack with the fix and release it today
[15:52] <seb128> sil2100, larsu is working on it
[15:55] <desrt> seb128: any progress on that gcc issue?
[15:57] <Laney> desrt: doko says it's fixed
[15:57] <desrt> nice!
[15:57] <Laney> https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1194123
[15:57] <ubot2`> Ubuntu bug 1194123 in gcc-4.8 (Ubuntu) "[gcc-linaro wrong-code regression] gcc 4.8.1-2ubuntu1 to 4.8.1-3ubuntu1 breaks gtk on armhf" [High,New]
[15:57] <seb128> desrt, what Laney said
[15:57] <Laney> actually maybe not, and it wasn't doko, but they think they know :P
[15:58] <seb128> well the flag they suggested fix it
[15:58] <seb128> doko said he was doing a build with the patch included
[15:58] <seb128> but he's off today
[15:58] <seb128> so we will see on monday
[16:04] <Laney> today is the day for system-settings MPs
[16:08] <seb128> Laney, seems so
[16:17] <thotz> Hello Desktop-Team!  I would need help with this bug: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1153934 . I have spoken to the Bugsquad team, but they told me to go here... About 90 people are affected by this bug.
[16:17] <ubot2`> Ubuntu bug 1153934 in gvfs "Some radio streams which used to play OK don't play after updating to rhythmbox 2.98 or higher due a gvfs bug" [Medium,Confirmed]
[16:43] <desrt> seb128: do you want a new systemd-shim release to deal with that suspend-during-shutdown issue?
[16:43] <desrt> or are you OK to pick the change off master?
[16:44] <seb128> desrt, I'm ok picking the change, and thanks for reminding me
[16:44] <seb128> I did suspend my laptop in middle of shutdown again yesterday :p
[16:44] <desrt> sounds like an easy-to-reproduce test
[16:44] <desrt> :)
[16:45] <seb128> yeah, for me it's "shutdown, wait for the session to close, close the lid"
[16:45] <seb128> it shutdowns on the plymouth logo almost every time when I do that
[16:45] <seb128> it suspends*
[16:47]  * desrt boggles at the fact that people use shutdown on their laptops
[16:49] <desrt> seb128: you could quickly confirm my theory about the bug by seeing if closing the lid immediately after shutting down causes a suspend or not
[16:49] <desrt> or if it open happens after 10 seconds (or not at all)
[17:07] <seb128> desrt, well, I close the lid when the user session close, that's a timeframe of 5-10s
[17:07] <seb128> would be easier to say with a 30s timeout :p
[17:07] <seb128> I might try to tweak that
[17:07] <desrt> seb128: i was wondering what happens if you click shutdown and then immediately close the lid
[17:07] <desrt> if you'd get an immediate suspend or not
[17:07] <desrt> i suspect not
[17:07] <desrt> and if you do, there is some other problem here, probably not related to systemd-shim
[17:08] <seb128> ok, will try in a bit (doing upgrades and restarting session)
[17:11]  * desrt goes to lunch
[17:11] <sil2100> larsu: ping
[17:11] <sil2100> larsu: any luck with fixing those indicator regressions?
[17:12] <larsu> sil2100: yes
[17:12] <larsu> fixing the ordering right
[17:12] <larsu> now
[17:12] <larsu> oh, your day is ending, eh?
[17:12] <seb128> desrt, enjoy!
[17:21] <Laney> have a nice weekend!
[17:21]  * Laney is off to climb
[17:21] <Laney> czajkowski: see you tomorrow!
[17:22] <seb128> Laney, thanks, you too!
[17:22] <mlankhorst> Laney: hah I did my horseback riding today already
[17:22] <mlankhorst> :>
[17:23] <sil2100> larsu: slowly, yes, but I can do the publishing tomorrow in the morning I guess
[17:23] <larsu> sil2100: I'm stuck on unity's cmake right now
[17:23] <sil2100> larsu: could you send me an e-mail when it's done, informing which branches have those fixes?
[17:24]  * ogra_ wonders if there are other places on a horse to ride on than the back
[17:24] <sil2100> larsu: so that I can re-run those
[17:24] <seb128> sil2100, larsu: I wouldn't bother about the order fix for today
[17:24] <sil2100> larsu: lukasz.zemczak@ubuntu.com
[17:24] <larsu> seb128: hm, okay.
[17:24] <sil2100> seb128: what about date-time? Is that done already?
[17:24] <seb128> sil2100, larsu: maybe just get the ido_init in it
[17:24] <larsu> sil2100: I'll upload my patch for ido_init right now
[17:24] <sil2100> larsu: \o/ awesome
[17:24] <seb128> larsu, sil2100: what matters is that the stuff work, if the order changed that's an ok issue to have until next week
[17:25] <sil2100> Right
[17:25] <seb128> sil2100, the fix is in unity(-panel-service)
[17:25] <larsu> sil2100: lp:~larsu/unity/call-ido-init
[17:27] <sil2100> hm
[17:27] <sil2100> That's troublesome then
[17:27] <larsu> how so?
[17:27] <sil2100> Since we didn't release unity, as the integration tests aren't passing well enough ;/
[17:27] <sil2100> So I guess we won't be able to release that anyway today
[17:27] <sil2100> I only released indicators, as those were passing
[17:27] <larsu> sil2100: the patch is trivial, it most likely apply on the latest released version
[17:28] <seb128> it does
[17:28] <seb128> I just applied it locally
[17:28] <sil2100> So maybe hm, maybe a manual upload with a quilt patch?
[17:28] <seb128> inline patch
[17:28] <seb128> but yeah
[17:29] <sil2100> Let's just merge the changelog entry into lp:unity when doing the manual upload
[17:34] <seb128> sil2100, do you want me to do the manual upload?
[17:36] <seb128> sil2100, hey?
[17:36] <sil2100> seb128: yes, since I have no permissions to do that
[17:36] <sil2100> I still don't have any upload rights ;/
[17:36] <sil2100> I can only operate scripts
[17:36] <sil2100> (jenkins-based)
[17:38] <kenvandine> seb128, i think those empty uploads of signon is because of the patch we are applying so we don't use the keyring on armhf
[17:38] <seb128> cd ..
[17:38] <seb128> ups
[17:38] <kenvandine> hehe
[17:38] <seb128> kenvandine, merge the patch in trunk?
[17:38] <kenvandine> no... that'll break the desktop
[17:39]  * kenvandine has no idea how to deal with this...
[17:40] <seb128> kenvandine, I guess I don't understand the issue, the source is the same for all archs in the package for sure?
[17:40] <seb128> why would it be different in trunk?
[17:40] <kenvandine> because we apply a patch to use the keyring on both i386 and amd64
[17:40] <kenvandine> but we use the default on armhf
[17:40] <kenvandine> we could flip it
[17:40] <kenvandine> merge the patch into trunk
[17:41] <seb128> oh, I see, yeah...
[17:41] <seb128> larsu, sil2100: https://launchpad.net/ubuntu/+source/unity/7.0.0daily13.06.24-0ubuntu2
[17:41] <kenvandine> then patch on armhf to disable the keyring
[17:41] <seb128> right
[17:41] <larsu> seb128: thanks!
[17:41] <kenvandine> but that'll complicate maintaining trunk...
[17:41] <seb128> larsu, thank you for the fix!
[17:41] <kenvandine> since LP's trunk for signon isn't upstream
[17:41]  * kenvandine hates that this stuff is on google code
[17:41] <seb128> kenvandine, oh, right... wait monday and see with Didier I guess
[17:42] <kenvandine> and upstream doesn't want to change the default to keyring
[17:42] <kenvandine> yeah...
[17:50] <sil2100> seb128: thanks! :)
[17:50] <seb128> sil2100, can you take care of merging the diff back in trunk?
[17:51] <seb128> sil2100, http://launchpadlibrarian.net/143672596/unity_7.0.0daily13.06.24-0ubuntu1_7.0.0daily13.06.24-0ubuntu2.diff.gz
[17:51] <seb128> sil2100, one larsu's merge is approved/in that should be only the changelog entry to merge
[18:13] <sil2100> seb128: ok
[18:13] <sil2100> Will merge that in
[18:20] <larsu> seb128: ordering patch is done, but needs a new libindicator. I guess it's not very urgen, I'll go through the usual MR channels
[18:20] <larsu> *urgent
[18:24] <sil2100> larsu: did you MR the unity fix?
[18:25] <larsu> sil2100: I'm doing a last test of everything, will MR in the next 5 minutes
[18:26] <sil2100> larsu: ok ;) If anything, my MR question was for the calendar fix (ido one)
[18:27] <larsu> sil2100: I'll put them both in the same MR, they're small enough
[18:35] <sil2100> ok
[18:40] <larsu> sil2100: https://code.launchpad.net/~larsu/unity/call-ido-init/+merge/172127
[18:41] <larsu> sil2100: don't merge yet though, it depends on a libindicator change (I'll try to get that in asap)
[18:42] <sil2100> If this depends on the indicator change, might be good that we change the debian/control dependency too
[18:42] <larsu> I did
[18:42] <sil2100> Awesome
[18:42] <larsu> ;)
[18:42] <sil2100> I need to pop out now, but I'll be back later and try dealing with that
[18:42] <sil2100> Thanks :)!
[18:42] <larsu> sil2100: enjoy your evening, thanks for sticking around
[19:22] <seb128> qengho, there?
[19:23] <qengho> seb128: indeed.
[19:23] <seb128> qengho, hey
[19:23] <seb128> qengho, I just got the new chromium in saucy today, is it supposed to prompt about webapp on every single website I browse?
[19:24] <seb128> (beause it does)
[19:24] <jbicha> seb128: bug 1194986
[19:24] <ubot2`> Launchpad bug 1194986 in chromium-browser (Ubuntu) "Chromium 28.0.1500.52 doesn't auth webapps. "Unity WebApps plugin needs your permission to run"" [Undecided,Confirmed] https://launchpad.net/bugs/1194986
[19:24] <mdeslaur> seb128: it's to annoy you into switching back to firefox :P
[19:25] <seb128> mdeslaur, ;-)
[19:25] <seb128> mdeslaur, that has another advantage, I can nag chrisccoulson about my bugs then :p
[19:25] <sarnold> mdeslaur: hunh, and I thought the firefox door-hanger flash annoy-o-tron was to annoy us into switching to chromium...
[19:25] <seb128> jbicha, thanks
[19:26] <mdeslaur> sarnold: hah! the _what_?
[19:26] <qengho> seb128: yes. That is, webapps patches haven't applied lately, and #security wanted to close a bunch of CVEs even if it shows an ugly bar. I am right now working on updates to hide the question bar.
[19:26] <seb128> oh, I guess qengho is going to join chrisccoulson on the "hate webapps" line ;-)
[19:26] <chrisccoulson> lol
[19:26] <chrisccoulson> hi ;)
[19:26] <seb128> chrisccoulson, hey! how are you?
[19:27] <seb128> qengho, oh, also still not menus in chromium in saucy :/
[19:27] <seb128> qengho, weren't you supposed to include that tiny patch to unbreak those?
[19:27]  * seb128 does need the menus a lot but they can be handy sometime
[19:28] <seb128> doesn't*
[19:28] <sarnold> mdeslaur: visit this: http://git.io/D9wjFQ
[19:28] <sarnold> mdeslaur: note the hateful little doorhanger asking if you want to run flash
[19:29] <mdeslaur> hrm, nope
[19:29] <jbicha> sarnold: what version of Firefox are you on?
[19:29] <chrisccoulson> seb128, yeah, i'm good thanks. how are you?
[19:29] <sarnold> jbicha: 22.0
[19:29] <seb128> chrisccoulson, tired, it's friday evening, I need a beer! but good otherwise ;-)
[19:29] <qengho> seb128: Yeah, I was.  Let me talk to attente about it.
[19:29] <sarnold> 22.0+build2-0ubuntu0.13.04.1
[19:29] <mdeslaur> sarnold: I think you have a security issue there...I don't have any flash on that page
[19:29] <jbicha> sarnold: are you going to install flash then? ;)
[19:30] <sarnold> jbicha: I've been thinking of uninstalling flash, that doorhanger is fscking annoying
[19:30] <chrisccoulson> mdeslaur, i do
[19:30] <attente> qengho, hey, how's it going?
[19:30] <chrisccoulson> (note, i'm running nightly, and it tells you when there's flash on a page now, even when you haven't blocked it)
[19:31] <mdeslaur> ah
[19:31] <chrisccoulson> mdeslaur, https://twitter.com/chrisccoulson/status/350291914022588421
[19:31] <seb128> jbicha, read your comment on eds/goa issue ... can you at least upstream a bug report?
[19:31] <sarnold> mdeslaur: do you have click-to-play turned on? I think I read somewhere that it might only show if click-to-play is there...
[19:31] <mdeslaur> sarnold: since I have no idea what that is, I'm guessing 'no'
[19:31] <qengho> attente: Hey.  Remember the menu-bar patches for chromium.  I'm not sure I can wait any more on The Right Way.
[19:32] <sarnold> mdeslaur: hah. about:config -- plugins.click_to_play
[19:32] <seb128> qengho, didn't you guys agree shipping the non-right-way temporary in saucy?
[19:32] <mdeslaur> sarnold: well, there you go! now you know how to fix your issue :)
[19:32] <jbicha> seb128: you want upstream to split the goa part of libgdata into a separate .so right?
[19:33] <sarnold> mdeslaur: before firefox 21 or something click_to_play made the web a far less sucky place. but then around firefox 21 they added the "firefox doorhanger" modal dialog box to piss me off.
[19:33] <seb128> jbicha, if that's what we need to make e-d-s+uoa not pull in goa, yes
[19:33] <attente> qengho, i thought we agreed to use that patch until i have time to do The Right Way?
[19:33] <seb128> jbicha, what I want is no goa when uoa is used
[19:33] <qengho> seb128: Maybe we did. :\  I'll see what I can do now.
[19:33] <seb128> jbicha, you probably want the reverse ... so what we want is a runtime choice between those
[19:33] <jbicha> seb128: yeah now you have the opposite of my problem :)
[19:34] <seb128> qengho, the patch is trivial, just sneak it into the next saucy upload (only in saucy)
[19:34] <sarnold> mdeslaur: I'm just afraid that I'll just as annoyed once I uninstall flash and all these annoying websites want me to load their plugin for the best browsing experience
[19:34] <chrisccoulson> sarnold, yeah, the idea of click-to-play is that it's only meant to appear for blacklisted plugins
[19:34] <chrisccoulson> (ie, everything that isn't the latest version of java or flash)
[19:34] <qengho> attente, seb128, okay, I'm going with what I have.  Thanks.
[19:34] <attente> qengho, thanks
[19:34] <seb128> qengho, thanks
[19:34] <AlanBell> balloons: I am completely confused by the QA test tracker tool, are there some instructions on how to submit testing results?
[19:35] <jbicha> chrisccoulson: clicktoplay for even the latest flash was a pretty cool feature though
[19:35] <balloons> AlanBell, yes there's some lovely links in the notice board now for help
[19:35] <balloons> http://packages.qa.ubuntu.com/
[19:35] <chrisccoulson> sarnold, but there is a new UI in the current nightly to allow you to disable plugins per-page, via an icon that appears on the navigation bar
[19:35] <sarnold> chrisccoulson: WANT!
[19:35] <balloons> AlanBell, specifically it points here: https://wiki.ubuntu.com/Testing/Cadence/Walkthrough
[19:36] <sarnold> chrisccoulson: don't get me wrong, click to play was great, I often knew which of the ten flash things I wanted to run :)
[19:36] <chrisccoulson> sarnold, did you see the twitter link i posted a few minutes ago?
[19:36] <sarnold> chrisccoulson: yeah
[19:36] <chrisccoulson> (although, it looks unfinished atm)
[19:36] <sarnold> chrisccoulson: but it was confusing.
[19:36] <balloons> AlanBell, there's video too if you'd like; http://www.youtube.com/watch?v=fw7SrLUzW6U
[19:36] <chrisccoulson> heh
[19:36] <AlanBell> balloons: so from this page, http://packages.qa.ubuntu.com/qatracker/milestones/298/builds/47541/testcases/1572/results where do I go? that doesn't look like the stuff in the documentation
[19:38] <balloons> AlanBell, ahh.. you need to login..
[19:38] <balloons> also it appears that link is linking to the archived result, not the active one; http://packages.qa.ubuntu.com/qatracker/milestones/298/builds/47622/testcases
[19:38] <AlanBell> hmm, I am, it says Hello alanbell in the title bar
[19:38] <AlanBell> ooh, that link has actions :)
[19:39] <balloons> yea, I'm sorry about that. bad link on my part
[19:39] <balloons> where did you find it.. let me make sure it's fixed :-)
[19:39] <AlanBell> but only passed with no bugs, subscribe and unsubscribe
[19:39] <balloons> well those are quick buttons you can use.. you see Mir has 1 testcase called xMir
[19:40] <balloons> in the future we'll add more
[19:40] <balloons> so more now, click xMir and run through that test
[19:40] <AlanBell> http://www.theorangenotebook.com/2013/06/mir-joins-cadence-testing.html run through the test cases link
[19:40] <balloons> AlanBell, great ty
[19:40] <AlanBell> got it, thanks
[19:42] <balloons> AlanBell, I updated that hotlink from the blog to take your straight ito the xMir tests so hopefully people aren't as confused :-)
[19:42] <AlanBell> great
[19:42] <AlanBell> how does one file a bug against it?
[19:42] <AlanBell> ubuntu-bug xmir won't work as it is in a ppa
[19:43] <balloons> http://packages.qa.ubuntu.com/qatracker/milestones/298/builds/47622/buginstructions, which appears blank.. let me fix that too :-)
[19:43] <AlanBell> yeah, I did look there first ;)
[19:43] <balloons> you'd think it was friday or something :-)
[19:44] <AlanBell> on the plus side I am using xmir right now
[19:44] <AlanBell> multimonitor doesn't work and there are a few input problems
[19:46] <balloons> mind filing a bug for multimonitor?
[19:47] <balloons> that way others will know it's broken as well and you can link it into the result :-)
[19:47] <AlanBell> yeah, will do when I know how :)
[19:47] <balloons> AlanBell, bugs are here: https://bugs.launchpad.net/mir/+bugs
[19:47] <balloons> lol, I'm working on that part
[19:47] <balloons> https://bugs.launchpad.net/mir/+filebug
[19:48] <balloons> ok, page is updated.. Many thanks AlanBell for doing a QA on the test itself, haha!
[19:49] <balloons> AlanBell, this might be interesting to you also: https://blueprints.launchpad.net/ubuntu/+spec/client-1310-mir-multimonitor
[19:49] <AlanBell> hmm, might be mostly hotplugging monitors that is broken
[19:49] <jbicha> chrisccoulson: if I enable clicktoplay in about:config, I get an extra Activate Plugins entry in Page Info>Permissions; it shows the GNOME Shell plugin but not Flash; why does Flash get special treatment there?
[19:56] <balloons> AlanBell, thank you for the report and feedback ;-)
[19:56] <balloons> armed with your knowledge starting at the homepage, http://packages.qa.ubuntu.com/, do you see how to test and report for the other packages we're tracking?
[20:10] <AlanBell> balloons: yeah, it makes sense starting from there, just that archive link was kinda confusing
[20:10] <balloons> I wonder if we do more harm than good starting people directly at the test
[20:12] <AlanBell> balloons: one thing that is a pain is you can't get from here http://packages.qa.ubuntu.com/qatracker/testcases/1572/info to the form to fill out your results
[20:13] <AlanBell> ooh, alt-left is bad with xmir
[20:13] <AlanBell> which doesn't help with the qa tracker as you have to go back from the test details to get to the reporting form :)
[20:16] <balloons> AlanBell, see the toggle where it says testcase?
[20:16] <balloons> click that.. that's the actual testcase your intended to see
[20:20] <AlanBell> not seeing a toggle
[20:20] <AlanBell> ah, that bit :)
[20:22] <AlanBell> balloons: you might want to add the instructions on how to disable xmir somewhere
[20:22] <balloons> AlanBell, found that bit eh?
[20:22] <balloons> install/uninstall should be covered by the link
[20:22] <balloons> that's straight from the team
[20:23] <balloons> hmm.. they don;'t have uninstall up
[20:23] <balloons> Ok I'll manually write instructions
[20:30] <balloons> AlanBell, done http://packages.qa.ubuntu.com/qatracker/milestones/298/builds/47541/downloads
[21:10] <AlanBell> balloons: I was actually thinking of commenting out type=unity in /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf
[21:10] <AlanBell> rather than completely uninstalling it
[21:10] <balloons> AlanBell, ahh.. well heh, that's interesting but more complex
[21:10] <AlanBell> see Turning Mir on & off temporarily http://www.olli-ries.com/running-mir/
[21:11] <balloons> Ok, hmm.. I'll add that as an option
[21:11] <balloons> ty!
[21:30] <olli> mhall119, AlanBell https://blueprints.launchpad.net/ubuntu/+spec/client-1310-mir-multimonitor
[21:33] <mhall119> thanks olli
[22:31] <AlanBell> thanks olli I look forward to further multi monitor testing :)