[04:25] <pitti> Good morning
[05:08] <didrocks> good morning
[05:08] <larsu> bonjour
[05:18] <didrocks> hey larsu! up early? ;)
[05:19] <larsu> didrocks: yep. I feel much more productive in the mornings. Let's see how long I can keep it up ;)
[05:19] <didrocks> heh :)
[05:19] <larsu> didrocks: happy Friday!
[05:20] <didrocks> happy Friday larsu!
[06:05] <didrocks> jibel: FYI, autopilot in the release pocket
[06:07] <Mirv> didrocks: webkit compiled successfully in the https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+packages during the night
[06:07] <Mirv> (https://code.launchpad.net/~timo-jyrinki/ubuntu/saucy/qtwebkit-opensource-src/arm-fix-and-docs-packages/+merge/174184)
[06:08] <didrocks> Mirv: ah, excellent! having a look at the MP then :)
[06:10] <didrocks> Mirv: we are not using the private headers in any of our projects?
[06:12] <Mirv> didrocks: we shouldn't, at least the webbrowser-app isn't. if we are, they should be split into a -private-dev package.
[06:13] <didrocks> Mirv: ok, just ensuring that we didn't break anybody :)
[06:13] <didrocks> diff looks good, sponsoring :)
[06:13] <Mirv> if we'd have a global code search, it'd be easier to say for sure. but it seems we are largely using QML anyway.
[06:14] <Mirv> didrocks: thanks!
[06:14] <didrocks> thanks to you!
[06:42] <darkxst> pitti, hi
[06:43] <pitti> hey darkxst
[06:45] <darkxst> pitti, do you have any ideas how the lid close actions would work in an inhibitor world? I don;t think I can just override the lid action without inhibitors since that will break gnome-shell (and maybe gnome-screensaver)
[06:46] <pitti> darkxst: I think the intention is that g-s-d sets a lid close inhibitor, and releases it only when it wants the suspend to happen (i. e. when it is active and gets a lid switch event)
[06:47] <darkxst> pitti, yes, but how to configure the action that happens on lid close
[06:47] <pitti> darkxst: if you disable suspend on lid close in the config, it would just never release the inhibitor
[06:48] <darkxst> pitti, it needs to be configurable from g-c-c, i.e. disable, suspend and hibernate
[06:49] <pitti> darkxst: it would need to actively call hibernate from logind, as the default logind config is to suspend
[06:49] <pitti> darkxst: so option one is to always hold the inhibitor lock and do all actions (suspend) by itself, option 2 (which is in g-s-d 3.8 AFAIK) is above strategy to drop the inhibitor if you want to suspend
[06:51] <jibel> didrocks, bonjour, thanks. I'll update the tests this morning
[06:51] <darkxst> Pici, right. but really I need option 3: configure lid close action (suspend,hibernate etc) while still using inhibors
[06:52] <darkxst> otherwise gnome-shell won't lock on lid close for example
[06:52] <didrocks> jibel: de rien ;) salut!
[06:52] <pitti> darkxst: you can't do hibernate with just inhibitors, you'd need to configure logind to hibernate on lid
[06:53] <darkxst> pitti, but logind does not have user settings?
[06:53] <pitti> exactly
[06:53] <pitti> and we are not going to change the default ocnfig
[06:53] <pitti> hibernate on lid close is just evil
[06:54] <pitti> (i. e. it's okay to offer it for configuring, but it's a really bad default)
[06:54] <pitti> darkxst: so if you want to hibernate, g-s-d always needs to keep the inhibitor and call hibernate() itself
[06:54] <darkxst> I'm not talking about default, just adding support to g-s-d to bring back the configurability
[06:55] <pitti> right, so that would be "option one" above
[06:56] <darkxst> except I don't want to break screen locking
[06:56] <darkxst> which as I understand, currently (in 3.8) gnome-shell gets the preparetosleep signal, locks the screen and then releases the inhibitor
[06:57] <pitti> but that's the suspend inhibitor, not the lid inhibitor
[07:00] <darkxst> so what does the lid inhibitor do then?
[07:00] <pitti> it prevents logind from suspending when closing the lid
[07:01] <pitti> or, I should say, from doing the configured action
[07:01] <pitti> i. e. ey=hibernate
[07:01] <pitti> ouch
[07:01] <pitti> i. e. HandleLidSwitch= in /etc/systemd/logind.conf
[07:02] <darkxst> can we just drop the hibernate on lid close action then?
[07:02] <pitti> darkxst: you mean the configuration option?
[07:02] <darkxst> yes
[07:02] <pitti> sure
[07:02] <pitti> we disable hibernate anyway by default in polkit
[07:03] <pitti> so it wouldn't work right now anyway
[07:03] <darkxst> ok cool
[07:04] <darkxst> that simplifies things somewhat! I see what to do now ;)
[07:04] <pitti> darkxst: it seems if you configure "no action", then all that g-s-d needs to do is to skip the piece of code that drops the lid inhibitor
[07:05] <pitti> and for "suspend on lid close" it should just work with what 3.8 does
[07:11] <darkxst> yeh
[08:05] <Laney> morning
[08:05] <didrocks> hey Laney, how are you?
[08:05] <Laney> pretty good thanks didrocks
[08:05] <Laney> been making some bread this morning ;-)
[08:05] <Laney> you?
[08:06] <didrocks> Laney: I'm fine, thanks! Sunny week-end (with national day on Sunday)
[08:06] <Laney> \o/
[08:06] <Laney> some kind of party?
[08:07] <didrocks> fireworks in most cities
[08:07] <didrocks> ah, also, the Tour de France is going through Lyon on saturday
[08:08] <didrocks> 3kms from my home, I think I'll have a look :)
[08:08] <Laney> oh wow
[08:08] <Laney> go ride the stage :P
[08:09] <didrocks> ahah, sure, that's totally me! :)
[08:16] <didrocks> hey sil2100, how are you?
[08:19] <sil2100> didrocks: hello! Continuuing my cleanup work
[08:20] <sil2100> didrocks: can you ACK? http://10.97.0.1:8080/view/cu2d/view/Head/view/Media/job/cu2d-media-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_qtvideo-node_0.2.1+13.10.20130712-0ubuntu1.diff
[08:20] <sil2100> (me and ken made those changes, so they're oook!)
[08:20] <didrocks> sil2100: sweet! you've found the right parameters for media then? :)
[08:21] <didrocks> sil2100: +1 on qtvideo-node
[08:35] <seb128> happy friday desktopers
[08:36] <seb128> (yeah, I'm late this morning, went for some errands before starting the day, I decided it was better early than at lunch time;-)
[08:36] <didrocks> Happy Friday seb128!
[08:36] <seb128> didrocks, thanks, you too ;-)
[08:36] <seb128> how is friday looking? not too much crazyness?
[08:38] <didrocks> seb128: looking good until now, going through the sdk tutorial and seeing where it's deprecated and so on :)
[08:38] <seb128> did they fix to have instructions/code actually working? ;-)
[08:40] <Laney> morning seb128!
[08:41]  * Laney was supposed to write a gsettings-qt example for d.u.c
[08:41] <seb128> Laney, hey
[08:41] <seb128> Laney, "was" supposed... did somebody beat you at it? ;-)
[08:42] <Laney> no I just forgot :(
[08:42] <seb128> do it today, seems like a good friday thing
[08:42] <Laney> yeah, after poking mlankhorst about...
[08:42] <Laney> ...
[08:42] <Laney> The following packages have unmet dependencies:
[08:42] <Laney>  pvr-omap4 : Depends: xorg-video-abi-13
[08:42] <Laney>              Depends: xserver-xorg-core-omap-revert but it is not going to be installed
[08:43] <darkxst> lucky you guys that still have a whole friday left ;)
[08:44] <mlankhorst> Laney: yeah I was afraid of that, if you're lucky manually adding xserver-xorg-video-omap-revert xserver-xorg-input-evdev-omap-revert might help..
[08:45] <Laney> ...
[08:45] <Laney> can you try it out on the porterbox? :(
[08:45] <mlankhorst> I don't have access?
[08:45] <Laney> why not?
[08:45] <mlankhorst> no idea what it is or where it's hosted
[08:45] <Laney> ssh porter-armhf.canonical.com
[08:47] <mlankhorst> hm times out
[08:47] <Laney> guessing you don't have sshebang configured?
[08:47] <seb128> you need to ssh through chinstrap
[08:48] <didrocks> seb128: I asked for it, they are sending MP as we speak
[08:49] <seb128> didrocks, sorry, lost context ... "it" being a working tutorial for the sdk?
[08:49] <didrocks> seb128: yep, that's the "it" :)
[08:49] <seb128> k ;-)
[08:49] <ogra_> Laney, can you make sure xserver-xorg-video-omap-revert land in main ?
[08:49] <Laney> it did
[08:49] <ogra_> *lands
[08:50] <Laney> I can install --dry-run it in a chroot with only main/restricted
[08:50] <ogra_> before the failed image build ?
[08:50] <Laney> don't know about that
[08:50] <Laney> but i didn't see a component-mismatches mail about it
[08:50] <ogra_> true
[08:51] <mlankhorst> ok my sshebang was out of date, it seems
[08:52] <ogra_> Laney, i'll start another build and if that fails too i can force it into omap4 images via livecd-rootfs
[08:53] <Laney> ogra_: I'd be interested to understand why it doesn't work
[08:53] <Laney> Is there some manual package addition going on?
[08:53] <ogra_> yeah, same here ... but it probably was just a timing issue
[08:53] <Laney> like instalilng ubuntu-desktop doesn't pull pvr
[08:54] <ogra_> you can add subarch specific packages (bootloader, specific driver packages etc) via livecd-rootfs if needed
[08:54] <Laney> ah
[08:54] <ogra_> it shouldnt
[08:54] <ogra_> if ubuntu-desktop would pull pvr it would do it on all arm devices
[08:54] <Laney> so ubuntu-desktop will pull the non-reverted xorg
[08:54] <mlankhorst> yeah
[08:55] <Laney> I guess that makes the other one be uninstallable
[08:55] <ogra_> hrm
[08:55] <mlankhorst> well if you install omap-revert before installing ubuntu-desktop, it would work
[08:55] <Laney> i'll do apt-get install pvr-omap4 and then see what ubuntu-desktop brings in
[08:56] <mlankhorst> it might need an explicit depends on xserver-xorg-input-evdev-omap-revert and xserver-xorg-video-omap-revert if it fails, but I don't think it should
[08:59] <Laney> update-alternatives: error: error creating symbolic link `/usr/lib/xorg/modules/drivers/omap_pvr_drv.so.dpkg-tmp': No such file or directory
[08:59] <Laney> :(
[08:59] <mlankhorst> hmz
[08:59] <mlankhorst> you've hit a packaging bug! :O
[08:59] <Laney> what joy
[09:00] <ogra_> didnt it run dkms ?
[09:01] <mlankhorst> ogra_: /usr/lib/xorg/modules/drivers doesn't exist yet..
[09:01] <mlankhorst> because no video driver is unpacked at that point
[09:02]  * Laney mkdir -p and carry on
[09:03] <seb128> waouh
[09:03] <seb128> on try <lost the count> chromium built on saucy/armhf, yeah
[09:03] <Laney> haha
[09:04] <Laney> I made a note yesterday to tell people to stop wasting time retrying that :P
[09:04] <seb128> ;-)
[09:04] <Laney> not sure that's a sustainable way for it to be ..
[09:04] <seb128> no it's not
[09:04] <seb128> but I'm still happy that it built
[09:05] <Laney> yeah, good news
[09:05] <seb128> the saucy version was quite outdated
[09:05] <Laney> will it migrate now?
[09:05] <seb128> it did
[09:05] <seb128> it's in my update-manager
[09:05] <seb128> that's how I noticed :p
[09:05] <Laney> sweet
[09:05] <Laney> mlankhorst: ok, so it still wants to remove the stuff
[09:05] <mlankhorst> odd.. what if you add those other depends?
[09:05]  * Laney installs the things you suggested
[09:06] <Laney> ah, that might be ok
[09:06] <mlankhorst> adding xserver-xorg-video-omap-revert would probably be good enough to ensure that directory exists, too
[09:07] <mlankhorst> but yeah you'd need both
[09:07] <Laney> building a package
[09:30] <Laney> ogra_: mlankhorst: ok then, uploading this ...
[09:31] <Laney> let's try respinning after it's published in release
[09:31] <ogra_> k, i added them to livecd-rootfs anyway though
[09:31] <Laney> i don't see how that will help
[09:31] <Laney> it's already a dependency of pvr-omap4 which should have done the trick surely
[09:31] <ogra_> they will be forcefully installed in any case that way
[09:32] <Laney> unless you mean the extra packages?
[09:32] <ogra_> i just mean the revert packages
[09:32] <Laney> the -video and -whatevertheotehroneis
[09:32] <ogra_> yes
[09:33] <ogra_> xserver-xorg-input-evdev-omap-revert and xserver-xorg-video-omap-revert
[09:33] <Laney> ok, well that's the same as adding the dep
[09:33] <Laney> so just respin when that his release if you would
[11:04] <mlankhorst> ok good so armhf works again then? :)
[11:24] <ogra_> mlankhorst, i havent triggered a new buiold yet, but the fix looks promising :)
[11:24] <mlankhorst> good, that will probably be the last panda related upload from xorg, ever :P
[11:25] <ogra_> (we're also wotking on a fix for touch, i want to keep the livefs builder free for a respin)
[11:25] <ogra_> hopefully the last panda related upload for everything actually :)
[11:25] <popey> I get GPU lockups on intel 13.04 - is 13.10 any better? (please say yes)
[11:25] <ogra_> that already caused lots more work than originally planned
[11:30] <mlankhorst> yeah xorg won't break on panda any more, unless going crazy with xmir stuff, which could not be enabled on panda anyway
[11:37] <seb128> Mirv, thanks for uploading that qtsystems patch to your ppa for testing ;-)
[11:42] <Mirv> seb128: you're welcome
[11:42] <Mirv> oh, it's compiled now, nice
[11:51] <Mirv> seb128: confirming that the crash is gone (no IMEI though either)
[11:52] <seb128> still not IMEI? :-(
[11:52] <seb128> Mirv, on what device do you try?
[11:53] <Mirv> seb128: Nexus 4
[11:53] <Mirv> seb128: nope, at least the field in Pat's test program is empty
[11:53] <seb128> Mirv, hum, ok, that one is supposed to have one :/
[11:53] <Mirv> seb128: SIM: yes, I wonder if that was before
[11:54] <seb128> Mirv, can you run "dbus-send --system --print-reply --dest=org.ofono / org.ofono.Manager.GetModems" and pastebin that?
[11:54] <seb128> Mirv, on the device
[11:55] <Mirv> seb128: http://pastebin.ubuntu.com/5867899/
[11:56] <Mirv> note that I don't actually have SIM in there, but IMEI should be readable nevertheless
[11:56] <Mirv> but it might be also ofono feature that it doesn't report it if it's not online
[11:56] <Mirv> I could grab some SIM card from my tablet
[11:56] <seb128> Mirv, that seems a bug in ofono
[11:56] <seb128> Mirv, if you could try with a sim that would be useful
[11:56] <seb128> but that seems a bug for rsalveti/awe
[12:01] <darkxst> seb128, hey
[12:02] <darkxst> so I am going to patch g-s-d to handle "no action" or "suspend" on lid close
[12:03] <darkxst> hope that is ok, but really providing a hibernate option is a PITA
[12:08] <seb128> darkxst, thanks for working on that
[12:09] <seb128> darkxst, what's the issue with hibernate?
[12:09] <seb128> I don't feel strongly about it, I think 95% of users want either to suspend or not
[12:09] <Laney> I guess that it's not handled by logind
[12:09] <darkxst> it would really need to logind to have support for user settings
[12:10] <Laney> If users want to do it they can presumably set HandleLidSwitch in /etc/systemd/logind.conf
[12:10] <seb128> right, let's not go this way
[12:10] <darkxst> short of breaking gnome-shell (and perhaps now gnome-screensaver)
[12:10] <darkxst> Laney, yep basically
[12:10] <Laney> if gsd just gets logind to do it
[12:10] <seb128> right, basically what we need is g-s-d to be able to put an inhibitor for those who don't want to suspend on lid clode
[12:11] <seb128> I think
[12:11] <Laney> seems fine to me
[12:11] <darkxst> seb128, yes that is what I am planning and should be easy enough
[12:11] <seb128> excellent
[12:11] <Laney> thanks for working on it
[12:12] <darkxst> Laney, seb128 np
[12:12] <darkxst> I'm off on mad mtb adventures tomorrows
[12:12] <Laney> oh wow, s-c autopkgtests passed
[12:12] <darkxst> but will sort it sunday sometime
[12:12] <Laney> pitti: I approve of run-adt-test!
[12:13] <Laney> I can imagine prepare-testbed doing its thing in /tmp might be annoying if you can't download at speed from cloud-images though :P
[12:14] <Laney> One feature request is a config file / flag to add custom apt sources (local reprepro archive) - had to hack the script to do that AFAICS
[12:44] <pitti> Laney: well, you only need to do prepare-testbed every couple of days (when the dist-upgrade time becomes too annoying or -U doesn't cut it any more)
[12:47] <Laney> pitti: If you reboot it'll be gone though
[12:48] <pitti> Laney: aah
[12:48] <pitti> Laney: I set BASEDIR=/home/martin-scratch/images/adt in ~/.adtrc
[12:48] <pitti> that, and APTPROXY=http://10.0.2.2:3142 (to use apt-cacher-ng)
[12:48] <Laney> ah
[12:48] <Laney> well, it's not a problem for me personally because I can pull them at 12MB/s :P
[12:49] <pitti> so I keep the base VMs around, and just have it put the temporary overlay fs into tmpfs with the -s option
[12:49] <pitti> Laney: but it still takes a while to generate
[12:49] <Laney> yeah, couple of minutes
[12:49] <pitti> Laney: I like the fact that I can get a throwaway saucy VM in seconds with run-adt-test -sSl
[12:49] <pitti> err, -sUl
[12:49] <Laney> oh yeah, that is nice
[12:50]  * Laney needs a bigger SSD
[12:52]  * darkxst just needs an SSD
[12:52] <Laney> yes
[12:52] <Laney> everybody does
[12:52] <darkxst> yes 20 million source files brings even the best HDD to its knees
[12:55] <Laney> dobey: http://paste.ubuntu.com/5867999/ there's my debian/ changes
[12:56] <Laney> you'll see the branch I pushed for the upstream ones
[13:02] <Mirv> sil2100: didrocks: hey, I'm running out of time here.. I haven't yet e-mailed SRU team about the XIM patches, could you do that? I was planning to check where are the raring branches of it, but so far I've only checked precise ones
[13:03] <Mirv> sil2100: the last item on the spreadsheet
[13:05] <Mirv> didrocks: I actually don't see anything proposed against the raring branches yet, and I initially only thought about precise (what bschaefer asked for) until you mentioned that SRU Team should be e-mailed about raring upload..
[13:05] <Mirv> maybe precise is all that is wanted, at least from Brandon's side?
[13:06] <Mirv> sil2100: but regarding precise, it's the usual drill we're familiar with :)
[13:17] <sil2100> Mirv: ok ;)
[13:17] <sil2100> Mirv: I can handle that, Brandon poked me about that yesterday anyway
[13:18] <sil2100> Mirv: so, since the queue is free, I'll poke the SRU guys about those and such
[13:18] <sil2100> Mirv: you can assign the task to me
[13:19] <Mirv> sil2100: <3
[13:19] <sil2100> ;p
[13:39] <didrocks> sil2100: yeah, just to confirm to you: raring is OK, (libgrip is in UNAPPROVED)
[13:39] <didrocks> sil2100: we should just email the SRU team as the xim change fore precise is quite intrusive
[13:42] <desrt> didrocks: i see you went with notre dame over sacré coeur
[13:44] <sil2100> didrocks: I know, I already e-mailed about that like a month ago, no response - will re-send
[13:44] <sil2100> I also asked cjwatson but he said he doesn't know much about unity and I should find someone else ;p
[13:47] <didrocks> desrt: yeah, finally, we thought sacré cœur was overrated :)
[13:47] <desrt> i disagree, but it's your wedding :)
[13:48] <desrt> i wish the invite had come sooner.  our trip to france is already booked for this year as of a week ago :/
[13:48] <didrocks> desrt: ah, so bad :( (but I told you the dates before, isn't it?), so you won't be around?
[13:49] <desrt> didrocks: we'll see :)
[13:49] <desrt> but uh... i don't suppose i'll be able to rsvp by 30 june
[13:50] <didrocks> desrt: tssss :p time to catch you up and get your address, remember? ;)
[13:50] <didrocks> desrt: TBH, we just need the definitive answer at last a month before
[13:50] <desrt> that will be easy
[13:50] <desrt> we'll see how it goes
[13:50] <didrocks> desrt: keep us posted :)
[13:50] <desrt> nice card btw.... not as cute as the fingers... but nice :)
[13:53] <didrocks> desrt: you don't want to know how my parents hate the card :)
[13:54] <didrocks> desrt: we got compliments only from people within our age!
[13:54] <didrocks> desrt: I'll transmit to Julie to you liked the card ;)
[13:54] <didrocks> (and won't tell that you prefered the fingers)
[13:55] <desrt> she already knows :p
[13:58] <didrocks> desrt: TBH, I bet it was the case :p
[14:26] <rsalveti> seb128: I'll check what is happening with ofono when we don't have a sim card
[14:26] <rsalveti> from a quick look it'd make sense for ofono to export the imei even without sim card
[14:27] <seb128> rsalveti, hey, feeling better?
[14:27] <rsalveti> seb128: better than yesterday at least :-)
[14:27] <rsalveti> but, weekend ahead
[14:28] <seb128> rsalveti, thanks for checking ofono, at least it's moving in the right direction, with the update we have the imei when there is a sim card ;-)
[14:28] <rsalveti> great
[14:28] <seb128> rsalveti, the qtsystems backend basically do org.ofono.Manager.GetModems and then GetProperty Serial on the first modem from that list
[14:29] <seb128> rsalveti, e.g "dbus-send --system --print-reply --dest=org.ofono / org.ofono.Manager.GetModems"
[14:29] <rsalveti> right, cool
[14:29] <seb128> if you want a dump of the infos
[14:29] <seb128> compare with/without sim maybe
[14:43] <seb128> mterry, hey, want some easy karma?  https://code.launchpad.net/~seb128/unity-greeter/use-ellipses-char/+merge/173477 ;-)
[14:46] <mterry> seb128, looking
[14:46]  * mterry could always use karma
[15:04] <kenvandine> seb128 is all into bribing with karma these days
[15:04] <seb128> haha
[15:07] <kenvandine> i miss the good old days of bribing with beer :)
[15:11] <seb128> kenvandine, oh, don't worry, there will be plenty of beer for you, next time we have a team sprint ;-)
[15:14] <seb128> kenvandine, Laney: should I renamed Licenses to License as well?
[15:15] <seb128> kenvandine, Laney: or is it just that software and info don't have plural or something?
[15:15] <seb128> you get information*s* in France, but I guess that's different in english? what about softwares, you can't have several of those? :-)
[15:18] <Laney> seb128: apparently they're both uncountable nouns ...
[15:19] <seb128> software as well?
[15:19] <Laney> yes
[15:19] <seb128> ok, learning every day
[15:19] <seb128> thanks ;-)
[15:19] <Laney> if Licenses is the component for displaying one package's license info then I'd have that singular too, yeah
[15:20] <seb128> one package can have several licenses
[15:20] <seb128> but I'm not picking, just tell me if singular is preferred
[15:22] <Laney> single sounds better to me
[15:22]  * Laney stares at gsettings-qt
[15:23] <Laney> adding a property which is never assigned to breaks it
[15:23] <Laney> wtf?
[15:26] <kenvandine> larsu, how does this look for a MM vapi?  http://paste.ubuntu.com/5868351/
[15:37] <Laney> hmm
[16:37] <tedg> seb128, What happens with gi repository typelib files and multi-arch ?
[16:37] <tedg> It seems like on my system Hud is the only person doing multi-arch there.
[16:38] <kenvandine> tedg, iirc they break...
[16:38] <seb128> tedg, we don't do multiarch for gir
[16:38] <kenvandine> although i haven't looked lately
[16:38] <seb128> you should move it back
[16:38] <tedg> Okay
[16:39] <kenvandine> larsu, is there any way i can run a locally built indicator-messages/phablet with some indicator loader like thing?  or does it require unity8?
[16:40] <tedg> kenvandine, You can use indicator loader on an indicator file
[16:40] <seb128> kenvandine, he called it a day already so you might not get a reply today
[16:40] <tedg> kenvandine, But I don't htink we have all the widgets in ido
[16:40] <kenvandine> tedg, will that work for the phablet build?
[16:40] <kenvandine> right
[16:40] <kenvandine> that's what i am trying to debug
[16:40] <kenvandine> and i can't kill indicator-messages-service on the phone
[16:40]  * seb128 is away for some exercice, be back in an hour
[16:40] <tedg> kenvandine, Just a small patch to IDO and it'll all work ;-)
[16:40] <kenvandine> restarting it for debug output doesn't work :/
[16:40] <kenvandine> tedg, do tell!
[16:41] <tedg> kenvandine, Hah, I'm fixing that now, putting an upstart job together.
[16:41] <kenvandine> i really want to be able to figure out why i never get the callback
[16:41] <kenvandine> replies to SMS works
[16:41] <tedg> bustle?
[16:41] <kenvandine> but my code doesn't
[16:41] <kenvandine> that's an option... i never think to run bustle over ssh :)
[16:44] <tedg> kenvandine, Can you look at this?  I ended up doing more packaging than expected in the end: https://code.launchpad.net/~ted/indicator-messages/upstart-job/+merge/174467
[16:45]  * kenvandine looks
[16:46] <kenvandine> tedg, what's the transition like from something dbus activated to upstart?  shouldn't this break the panel or something?
[16:47] <kenvandine> anything that expected it to be activated with dbus?
[16:51] <tedg> kenvandine, We're starting it when loading the files, so they'll try, fail, and magically it'll appear.
[16:51] <kenvandine> so this won't break current unity7?
[16:52] <tedg> It shouldn't, just tested in a guest session... that one didn't work.  indicator-sound/network do.
[16:52] <tedg> Not sure why messages is different yet.
[16:52] <kenvandine> tedg, see my comments in the MP too
[16:53] <kenvandine> tedg, also remember there is a indicator-messages/phablet branch, which has forked a bit... might be easier to merge this change into both branches now as opposed to expanding the delta
[16:53] <tedg> kenvandine, Yeah, I've been turning debug on for now.  If nothing else, it's in it's own file now so it won't get in the way.
[16:53] <tedg> kenvandine, Sure, guessing this stuff didn't change much.
[16:54] <kenvandine> yeah, i know larsu plans to merge that soon... i'd hate to make that harder on him :)
[16:55] <tedg> Hmm, didn't realize this branch was still using a .so
[16:57] <tedg> Hmm, not even the phablet branch has an indicator file :-/
[16:57] <tedg> Didn't realize indicator-messages was this far off.
[17:00] <kenvandine> tedg, yeah, hence my concern about not making the delta bigger
[17:02] <tedg> kenvandine, It actually merges cleanly, except for the conflicts that already exist between the two.
[17:03] <kenvandine> tedg, ok... what's the trick to X forwarding?
[17:03] <kenvandine>  -Y isn't working
[17:05] <tedg> kenvandine, Did you install xauth ?
[17:05] <tedg> kenvandine, Also, it might be easier to do the capture on the device, and then just copy the file.
[17:05] <tedg> YMMV
[17:06] <kenvandine> oh yeah
[17:06] <kenvandine> been a while since i've used bustle
[18:12] <seb128> kenvandine, xorg forwarding is -X not -Y
[18:13] <ogra_> both are :)
[18:13] <seb128> oh ok, I always used X
[18:13] <ogra_> -Y is "trusted" X11 forwarding ...
[18:14] <ogra_> whatever that means :P
[18:14] <ogra_> (i think -Y drops some security)
[18:17] <seb128> jbicha, hey, is libraw 0.15 a stable or unstable serie?
[18:17] <seb128> jbicha, oh, and please wait that Debian gets some work done on transition before jumping on those, that's creating extra work for no good reason...
[18:20] <jbicha> seb128: http://release.debian.org/transitions/html/libraw.html
[18:21] <jbicha> http://www.libraw.org/ claims that 0.15 is stable
[18:32] <kenvandine> larsu, the vapi i generated worked... i now have an equally buggy vala example using lp:indicator-messages/phablet :-D
[18:36] <robru> qengho, ping? I'm trying to find out when chromium >25 first landed in saucy.
[18:41] <robru> qengho, nm, just found it's debian/changelog
[18:42] <kenvandine> interesting
[18:42] <kenvandine> it looks like it was actually just published today
[18:42] <kenvandine> 28 that is
[18:44] <kenvandine> robru, maybe it's been stuck in -proposed?
[18:44] <robru> odd
[18:44] <Laney> it has
[18:44] <Laney> it failed to build on armhf lots
[18:45] <robru> that explains v28, but was v26 also stuck in -proposed for it's entire life? I'm only just now upgrading from v25 to v28
[18:45] <Laney> https://launchpad.net/ubuntu/+source/chromium-browser/+publishinghistory
[18:46] <robru> well I'll be damned
[18:50] <robru> I vote that we delete ALL debian/changelog files and just replace them with links to that URL.
[19:21] <seb128> jbicha, where do you see on http://www.libraw.org/ that 0.15 is considered stable?
[19:22] <seb128> jbicha, oh; on the side, I see
[19:22] <seb128> would be nice if they would put those infos in the release notes
[19:23] <seb128> jbicha, not sure what's going on with that tracker package, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt lists 45 items for that transition
[19:24] <seb128> though those are binary packages, but that's at least 15 sources
[19:25] <Laney> it's probably transitive rdepends
[19:25] <seb128> Laney, stop being on IRC a friday at 8:25pm ;-)
[19:26] <Laney> +1h to you :P
[19:26] <Laney> I'm playing games on my desktop though ;-)
[19:26] <seb128> damn, I don't even have that excuse :p
[19:28] <jbicha> seb128: the libraw transition is done now
[19:28] <seb128> jbicha, yeah, saw that, I would still appreciate if you were asking around before starting transition/moving to new series
[19:28] <seb128> we got bitten a few times now by that
[19:29] <jbicha> it seemed harmless as there were only 4 rdepends and Debian had already done all the work
[19:29] <seb128> there is no reason to always jump on the newest series when the update doesn't bring anything but is likely to create bugs
[19:29] <seb128> well, for what we know there might be new bugs
[19:34] <seb128> jbicha, thanks for all the work you are doing, sorry if I sound grumpy sometime, it's not always easy to find a balance between doing update and aiming at stability
[19:35] <seb128> we had a fun updates this cycle that did cost us quite some bugs/debugging time (including the new gtk)
[19:35] <jbicha> yes, the balance is tricky
[19:35] <seb128> we also had a fun people starting transition and letting stuff in proposed for others to finish
[19:36] <jbicha> I do appreciate the extra stability that we've had for raring and saucy even though the delay gets annoying some times too
[19:36] <seb128> (not always on purpose, sometimes it's soname changes overlooked when syncing with debian or updating)
[19:36] <seb128> oh, on the gtk note, don't count on gtk 3.10 any time soon...
[19:37] <seb128> seems like mccann decided to pick gtk as his next project to go against and break/drop half the feature before moving away to the next one :/
[19:38] <jbicha> lol
[19:39] <jbicha> it seems that gtk3 has always been disruptive
[19:39] <seb128> looking to https://git.gnome.org/browse/gtk+/log/?qt=committer&q=mccann give an idea of what he's doing
[19:39] <seb128> Deprecate and hardcode default toolbar style setting
[19:39] <seb128> Deprecate and hardcode values for gtk-tooltip* timeouts
[19:39] <seb128> Deprecate and hardcode the value of visible-focus setting
[19:39] <seb128> Deprecate and ignore gtk-enable-tooltips setting
[19:39] <seb128> ...
[19:39] <seb128> going on a page
[19:40] <seb128> yeah, they used to deprecate saying that those would be dropped in gtk4
[19:40] <seb128> he went for "let's ignore the config in 3.10"
[19:40] <seb128> "Deprecate and ignore gtk-can-change-accels"
[19:40] <seb128> that's going to be popular :p
[19:41] <jbicha> well it's like for the 3.8 cycle, deprecate fallback == remove everything that fallback uses but gnome-shell doesn't need with no deprecation cycle in between
[19:41] <seb128> right :/
[19:42] <seb128> well, let's say I'm glad we decided to stay one cycle behind
[19:44] <seb128> ok, on that note, enough work for this week
[19:44] <seb128> have a nice weekend everyone, see you next week
[20:09] <qengho> robru: Got it?
[20:11] <qengho> robru: https://launchpad.net/ubuntu/saucy/+source/chromium-browser/+builds
[20:11] <qengho> robru: inherited v25 from raring on first day.
[20:12] <chrisccoulson> qengho, were you planning to prepare the latest chromium stable?
[20:12] <chrisccoulson> (and hi, btw)
[20:13] <qengho> chrisccoulson: yes. Upstream isn't making release tarballs right now, so I'm having to check it out from their wonky source control system.
[20:13] <chrisccoulson> qengho, awesome, thanks
[20:41] <robru> qengho, yeah, no worries. I was just really surprised to discover that I was running v25 when other people were reporting webapps bugs against chromium 27 and 28.
[20:44] <qengho> robru: one architecture keeps failing to build for S.
[20:44] <robru> qengho, congrats on getting v28 out ;-)
[21:07] <asac> anyone strong from MIR team around?
[21:07] <asac> anyone konws who is strong? :)
[21:07] <asac> and also knows a bit about distro/packaging?