[05:42] <pitti> Good morning
[07:27] <didrocks> good morning
[07:29] <Sweetshark> morning. unfortunately not so much a good one. :-/
[07:30]  * Sweetshark found out people have ripped him of a ~1000Euros on his Visacard.
[08:07] <bschaefer> didrocks, hey
[08:08] <bschaefer> didrocks, good morning for you
[08:09] <pitti> hey didrocks
[08:09] <didrocks> hey bschaefer
[08:09] <didrocks> morning pitti
[08:09] <pitti> Sweetshark: urgh -- but I guess they'll reimburse it?
[08:09] <bschaefer> didrocks, so a I've been asked about doing an SRU for the new ibus changes
[08:10] <bschaefer> didrocks, or more or less people have asked for it
[08:10] <didrocks> bschaefer: hum? did your management asked for it?
[08:10] <didrocks> ask*
[08:10] <thumper> didrocks: no, I told him to ask you :)
[08:10] <bschaefer> didrocks, nope, thumper told me to talk to you about it. As the changes would be in both nux and unity
[08:10] <didrocks> bschaefer: seems quite a big change IMHO
[08:11] <thumper> and largeish
[08:11] <didrocks> bschaefer: and 2 month before we recommend using the LTS
[08:11] <bschaefer> didrocks, agreed
[08:11] <didrocks> doesn't seem reasonable to me
[08:11] <didrocks> better to focus on precise now
[08:11] <bschaefer> didrocks, I just wanted to check so I have something to tell people when I get asked about it :)
[08:11] <bschaefer> didrocks, but that sounds good thank you :)
[08:11] <didrocks> you can tell the above ^
[08:11] <didrocks> :)
[08:12] <didrocks> yw
[08:41] <BigWhale> I am experiencing strange movement of applications when I click their icons in launchre.
[08:41] <BigWhale> launcher.
[08:45] <chrisccoulson> good morning everyone
[08:45] <pitti> hey chrisccoulson, how are you?
[08:45] <micahg> hi chrisccoulson
[08:45] <pitti> chrisccoulson: is your foot any better?
[08:45] <chrisccoulson> pitti - yeah, it's much better, thanks
[08:46] <BigWhale> chrisccoulson, I hope you didn't shot yourself in the foot. :)
[08:47] <chrisccoulson> heh, not quite ;)
[08:47] <BigWhale> all well then.:)
[08:49] <pitti> need to take my wife to the doctor, back later
[08:52] <glatzor> morning mvo
[08:52] <mvo> hey glatzor!
[08:52] <mvo> glatzor: did you had a chance to look at my aptdaemon branch? the one about sudo vs admin group?
[08:53] <glatzor> mvo, regarding lp:~mvo/aptdaemon/admin-group-fix, we cannot rely on the group that the user is in
[08:53] <mvo> glatzor: in the test? or in the actual code?
[08:53] <glatzor> mvo, every user could theoretically buy software - thanks to policykit
[08:53] <glatzor> mvo, in the code.
[08:54] <mvo> glatzor: hm, in this case we could a) use 0640 and set the group to the users gid or we use the /etc/apt/netrc file for the username/password storing
[08:54] <mvo> I guess (b) is more elegant
[08:56] <glatzor> just for the background: ubuntu has merged the sudo group from debian? is there an automatic migration from admin to sudo?
[08:58] <glatzor> why is the permission root:root insufficient?
[08:58] <glatzor> does the user need to read his own password anywhere?
[09:04] <didrocks> chrisccoulson: hey hey, how was your week-end?
[09:04] <chrisccoulson> didrocks, yeah, not too bad thanks. and yours?
[09:05] <didrocks> chrisccoulson: was nice. However, the night was short (took Julie to see the doctor urgently, was feeling some pain. She's better now)
[09:05] <seb128> hey
[09:05] <didrocks> so, lacking sleep now :)
[09:05] <didrocks> salut seb128
[09:05] <chrisccoulson> oh, that sucks. it's good that she's better now though
[09:06] <chrisccoulson> hey seb128
[09:06] <seb128> lut didrocks
[09:06] <seb128> didrocks, what happened to Julie?
[09:06] <seb128> chrisccoulson, hey, how are you?
[09:06] <chrisccoulson> seb128, yeah, not too bad thanks
[09:06] <seb128> I made chrisccoulson do desktop work again \o/
[09:06] <chrisccoulson> lol
[09:06] <chrisccoulson> yeah :)
[09:06] <seb128> chrisccoulson, thanks for fixing that, I still don't get why the valgrind log on that bug didn't show an invalid write in nautilus code
[09:06] <didrocks> seb128: some stomach pained which seems to have happened shortly, but in an intensive way
[09:07] <seb128> didrocks, oh :-(
[09:07] <seb128> didrocks, is she better?
[09:07] <didrocks> pain*
[09:07] <chrisccoulson> seb128, i'm not sure valgrind works for stuff which isn't heap allocated
[09:07] <didrocks> seb128: yeah, way better this morning :)
[09:07] <seb128> great
[09:07] <seb128> chrisccoulson, hum, could be, maybe it's time I get a 64bits install ;-)
[09:07] <seb128> chrisccoulson, thanks for sorting it in any case!
[09:07] <chrisccoulson> you're welcome :)
[09:28] <RAOF> seb128, didrocks: If you see anyone complaining about "X froze when I moved the mouse to the screen edge to reveal the launcher", bug #946954 is what I'm using to track it.  apw has very kindly furnished me with a backtrace fully describing my oversight.
[09:28] <ubot2`> Launchpad bug 946954 in xorg-server "Deadlock on attempting to reveal launcher" [Critical,In progress] https://launchpad.net/bugs/946954
[09:28] <seb128> RAOF, hey, ok, great, thanks!
[09:29] <RAOF> Now, dinner.
[09:29] <didrocks> oh nice, thanks RAOF :)
[09:29] <didrocks> RAOF: enjoy
[09:34] <chrisccoulson> RAOF, oh, i keep seeing that bug too
[09:35] <chrisccoulson> i also noticed at the weekend that i get a blank screen when i resume from suspend (although, my session is functional and i can still interact with it - i even see the cursor changing on the screen)
[09:35] <seb128> chrisccoulson, but I'm sure you were blaming it on dx :p
[09:35] <chrisccoulson> seb128, yeah, it's always compiz fault
[09:35] <seb128> hehe
[09:36] <chrisccoulson> i was getting ready to blame compiz for the nautilus crash ;)
[09:36] <seb128> well to be fair that one was dx's fault :p
[09:36] <seb128> it was a patch from them
[09:36] <chrisccoulson> heh
[09:37] <chrisccoulson> ooh, nice: https://twitter.com/#!/mozhacks/status/176597541285142528 ;)
[09:37] <seb128> ok, I'm out for half an hour or so, bbiab
[09:42] <mvo> glatzor: ups, sorry missed your message. so ubuntu did merge sudo but there is *no* automatic migration
[09:43] <mvo> glatzor: root.root and 640 is not good  because then apt will not be able to read the package information for that repository
[09:43] <mvo> glatzor: and 644 is not good because the password is visible systemwide
[09:44] <mvo> glatzor: the alternative is 644 and putting the password into /etc/apt/netrc, maybe that is the way to go, let me test, its pretty much untested :/
[09:59] <mvo> glatzor: so /etc/apt/auth.conf seems to be fine, would you accept the patch if I simply write to there?
[10:00] <xclaesse> is it known that language reverted to English in ubuntu precise?
[10:00] <xclaesse> maybe lang pack are broken or something?
[10:01] <seb128> xclaesse, no, works fine here
[10:01] <seb128> xclaesse, what does "locale" say?
[10:02] <xclaesse> hm, weird, it's a mix of fr_FR and en_US...
[10:02] <seb128> did you play with the control center region capplet?
[10:03] <xclaesse> seb128, I've played with the stuff in keyboard layout (not asking why language is there...)
[10:03] <seb128> xclaesse, seems like a bug in the region stuff then
[10:06] <xclaesse> seb128, ok, I've moved french to the top in ubuntu's language window, and now all is fine
[10:06] <seb128> good
[10:06] <xclaesse> so it seems that conflicts with g-c-c
[10:08] <seb128> it should not, the GNOME region stuff is known to be buggy and unfinished though, that's why we hide it under Unity
[10:08] <seb128> it was on the list of stuff to fix for this cycle but we didn't get to it
[10:08] <seb128> so next cycle I guess
[10:15] <xclaesse> seb128, ok fair enough :)
[10:26] <glatzor> mvo auth.conf?
[10:26] <micahg> seb128: is there any reason not to update to the latest libglib-perl? I see one small feature (Add a fallback implementation of SvMAGIC_set), it also fixes the FTBFS in the latest rebuild
[10:27] <seb128> micahg, don't ask me, I've no clue about perl nor interest for it
[10:27] <seb128> micahg, but not reason as far as I'm concerned
[10:27] <mvo> glatzor: yeah, its a (very underused) feature in apt to support seperation of credentials from sources.list
[10:27] <mvo> glatzor: I work on a branch for it now and updated the merge proposal
[10:27] <glatzor> mvo, ah I see - back from Lucid :)
[10:28] <mvo> glatzor: yes
[10:28] <mvo> glatzor: I push my initial branch and need to run to a appointment
[10:28] <glatzor> mvo, is it ok for you if I take a look at it this afternoon?
[10:29] <mvo> glatzor: sure, I push my branch and you can tidy it up and make it pretty, sounds good?
[10:30] <mvo> glatzor: or I can make it as pretty as possible and you just need to ack it
[10:30] <glatzor> mvo, that is the way to go!
[10:30] <glatzor> mvo, it is ok for me to to do the dirty work :)
[10:30] <mvo> glatzor: awsome! lp:~mvo/aptdaemon/use-apt-auth.conf is the branch
[10:31] <mvo> glatzor: so far it just contains the failing test, but its hopefully easy to add the rest, I will see what I can do before lunch and leave you the pieces ;)
[11:06] <BigWhale> Why are my windows randomly displaced around the desktops? :/
[11:18] <pitti> hey seb128, how are you?
[11:18] <seb128> pitti, hey, alter! wie gehts?
[11:18] <seb128> I'm good thanks, had a relaxing w.e
[11:19] <pitti> seb128: me too; we can't do much anyway these days :)
[11:19] <seb128> pitti, so my week of effort was just enough to balance your two apport uploads and you got over the mark with jockey today, I'm working on fixing that ;-)
[11:20] <pitti> seb128: hehe
[11:20] <seb128> pitti, how is your wife doing?
[11:20]  * pitti finishes the lightdm upload he was preparing before
[11:20] <pitti> seb128: it's going as expected, no difficulties
[11:20] <seb128> ok, good
[11:20] <seb128> pitti, >lightdm, I guess it's just the fd leak stuff?
[11:20] <pitti> a lot of sessions at the physiotherapist and some at the doctor still, of couse
[11:20] <seb128> not a fixed 1.1.4?
[11:21] <pitti> seb128: oh, right, I should pick that, too
[11:21] <pitti> seb128: I'm working on bug 868400
[11:21] <ubot2`> Launchpad bug 868400 in gnome-settings-daemon "Synaptics touchpad stops working - two syndaemon instances running" [Medium,Confirmed] https://launchpad.net/bugs/868400
[11:21] <pitti> it also needs a g-s-d fix
[11:21] <seb128> pitti, the issue is mostly g-s-d
[11:21] <seb128> i.e when gsd segfault and is respawned
[11:21] <pitti> yes, understood
[11:21] <seb128> I think the lightdm part was a redherring
[11:21] <pitti> well, not quite
[11:22] <pitti> it also starts a syndaemon in the greeter session, and it's not properly killed
[11:22] <pitti> anyway, it can't hurt to just disable it, it's not really needed
[11:22] <pitti> but yes, I'll also work on the g-s-d side, that's more involved
[11:22] <seb128> gsd side> I think we should do whatever syncdaemon is doing in gsd
[11:23] <seb128> like copy the code there if we can
[11:23] <seb128> rather than calling an external command
[11:23] <seb128> I hoped upstream would pick it up but they didn't yet
[11:23] <pitti> that'd be more elegant, but it's also quite a lot of code
[11:23] <pitti> and the code also isn't very good
[11:23] <seb128> ok, that's what I feared
[11:23] <pitti> as a g-s-d maintainer I'd be opposed to adopting it
[11:24] <pitti> it's a very ugly polling loop, instead of subscribing to key events
[11:24] <seb128> I guess the easiest way is to check if a syndaemon is running and not start one in this case
[11:24] <pitti> I tried writing an event-based replacement, but did not get that far yet
[11:24] <pitti> seb128: right, and I'll start with that
[11:24] <seb128> great
[11:24] <seb128> GNOME 3.3.91 tarballs day today btw
[11:24] <pitti> we have bug 906987 to track the "ugly code" part
[11:24] <ubot2`> Launchpad bug 906987 in xserver-xorg-input-synaptics "syndaemon polls 5 times a second even though it is started with the -R XRecord extension option" [Medium,Triaged] https://launchpad.net/bugs/906987
[11:24] <seb128> just for info for those interested
[11:28] <pitti> seb128: the fd leak fix doesn't backport well, I'll rather wait for mterry to investigate the 1.1.4 regression
[11:29] <seb128> pitti, ok
[11:43] <Sweetshark> pitti: libreoffice_3.5.0-2ubuntu1 on chinstrap is waiting for sponsoring.
[11:43] <Sweetshark> didrocks: unless you volunteer for ^^
[11:43] <didrocks> Sweetshark: still kind of busy with unity/compiz
[11:49] <pitti> Sweetshark: sure, doing; BTW, did you get any feedback on your PPU application?
[11:54] <seb128> pitti, urg, your lightdm hack is wrong imho
[11:56] <seb128> pitti, I will revert that in the vcs
[11:56] <pitti> seb128: oh, how else do you provide an user specific dconf setting?
[11:56] <seb128> pitti, lightdm has nothing to do with gsd
[11:56] <seb128> pitti, that's an unity-greeter specific issue
[11:57] <pitti> perhaps, but it's lightdm which creates the user
[11:57] <seb128> pitti, and unity-greeter already has code to disable half the gsd plugins
[11:57] <Sweetshark> pitti: still only one endorsement (yours), so I didnt really push it further.
[11:57] <pitti> and the bug is not speicifc to the unity greeter
[11:57] <seb128> pitti, no other greeter run gsd
[11:57] <pitti> seb128: oh, fair enough; if it's better done in unity-greeter, I won't object
[11:59] <seb128> pitti, http://bazaar.launchpad.net/~unity-greeter-team/unity-greeter/trunk/view/head:/src/settings-daemon.vala
[11:59] <seb128> pitti, I think it's better to add a line there
[11:59] <seb128> pitti, rather than doing postinst hacks
[12:00] <pitti> seb128: oh, it already disables the mouse plugin
[12:00] <seb128> pitti, right, I wonder why the bug is happening at all then :-(
[12:01] <pitti> seb128: presumably due to multiple g-s-ds in one session (after crashing)
[12:01] <pitti> seb128: ok, I'll revert it in lightdm then, sorry
[12:01] <seb128> pitti, no worry, just revert it in the vcs
[12:02] <seb128> pitti, I'm puzzled by the second entry in the changelog btw, http://launchpadlibrarian.net/95371871/lightdm_1.1.4.is.1.1.3-0ubuntu1_1.1.4.is.1.1.3-0ubuntu2.diff.gz
[12:02] <seb128> pitti, I see no actual change matching it?
[12:03] <pitti> hm, that change already was in bzr
[12:03] <pitti> so yes, that looks missing indeed
[12:04] <pitti> seb128: I'll add it for good, while I'm at it
[12:04] <pitti> seb128: thanks for spotting this
[12:20] <seb128> hum, I disconnected during lunch it seems
[12:20] <seb128> pitti, if you said anything for me after my " oh, I bet robert_ancell forgot to bzr add in r1077" please say it again ;-)
[12:20] <seb128> (or anyone else)
[12:21] <pitti> seb128: I didn't actually see that any more
[12:21] <seb128> up
[12:21] <pitti> pitti | hm, that change already was in bzr
[12:21] <pitti> pitti | so yes, that looks missing indeed
[12:21] <pitti> pitti | seb128: I'll add it for good, while I'm at it
[12:21] <pitti> pitti | seb128: thanks for spotting this
[12:21] <seb128> pitti, thanks ;-)
[12:49] <mvo> glatzor: welcome back, I have a merge-proposal for you, but a second pair of eyes is more than welcome :)
[12:52] <mvo> glatzor: so for the install-different-versions branch you suggest that I simply make my code smarter to understand about upgrade/downgrade and use that when  a version is forced? and that will work even if apt is not of the opinion that the package is upgradable (its only upgradable when the version is explicitely set)?
[13:00] <m4n1sh> didrocks: ping
[13:00] <didrocks> hey m4n1sh
[13:00]  * didrocks will try to find some time to have a break at some point :)
[13:00] <m4n1sh> as you wished, here is UIFe proposal https://bugs.launchpad.net/ubuntu/+source/activity-log-manager/+bug/945557
[13:00] <ubot2`> Launchpad bug 945557 in activity-log-manager "[UIFe] Selection list for blocking application logging provides usage and last-used column. Upload activity-log-manager 0.9.3" [Undecided,New]
[13:00] <m4n1sh> you need to go hiking in the alps after every ubuntu release
[13:01] <didrocks> m4n1sh: well, I was born in the alps, so knowing this kind of landscape quite well ;)
[13:01] <m4n1sh> that's even better
[13:01] <m4n1sh> so what is the next step for UIFe process
[13:01] <m4n1sh> will it discussed in release meeting or they will look into the proposal separately?
[13:02] <didrocks> m4n1sh: we need to wait for the documentation team to ack or nack the change
[13:02] <m4n1sh> okay
[13:02] <didrocks> m4n1sh: as you subscribed them, they should look at it
[13:02] <didrocks> maybe, try to catch some people on IRC as well
[13:02] <didrocks> like Jeremy is around normally
[13:03] <didrocks> (jbicha)
[13:03] <m4n1sh> oh, he is in docs team. never knew that
[13:03] <didrocks> yeah ;)
[13:03] <didrocks> asking when he's around is the easiest way
[13:04] <desrt> good morning, ubupeeps
[13:04] <seb128> hey desrt
[13:05]  * m4n1sh once saw a photo of desrt comically photoshopped with ploum
[13:05] <seb128> lol
[13:05] <didrocks> something in a bed I guess :)
[13:05] <didrocks> hey desrt
[13:05] <m4n1sh> yes
[13:05] <m4n1sh> I think I found it, but not sure if it as per CoC
[13:05] <seb128> the internet never forget ;-)
[13:07] <desrt> m4n1sh: i think everyone has seen that picture
[13:08] <m4n1sh> it turned up on PGO and Planet Ubuntu
[13:08] <desrt> including my parents...
[13:08] <desrt> it comes up on the first page when you google my name, so.....
[13:08] <desrt> pretty much everyone i know has seen it :p
[13:10] <m4n1sh> so as per the post next up is with vincent
[13:10] <desrt> fortunately vuntz doesn't have the same flair for GIMP as ploum
[13:19] <glatzor> mvo, sorry. my laptop crashed.
[13:20] <mvo> glatzor: no worries
[13:20] <mvo> glatzor: glatzor: welcome back, I have a merge-proposal for you, but a second pair of eyes is more than welcome :)
[13:20] <mvo>  glatzor: so for the install-different-versions branch you suggest that I simply make my code smarter to understand about upgrade/downgrade and use that when  a version is forced? and that will work even if apt is not of the opinion that the package is upgradable (its only upgradable when the version is explicitely set)?
[13:25] <Sweetshark> ricotz: thats for the python reply. I thought that was a backport only issue. sorry about that.
[13:26] <glatzor> mvo,  I will be back soon
[13:26] <glatzor> see you
[13:26] <mvo> glatzor: see you
[13:27] <ricotz> Sweetshark, yeah, it is a upstream problem after all ;), but thanks for notifying
[13:29] <Sweetshark> ricotz: 90% of our open launchpad LO bugs are upstream -- and most even feature requests, so no exception there ;)
[13:30] <ricotz> Sweetshark, alright -- don't forget to push the git changes
[13:31] <Sweetshark> ricotz: done already.
[13:32] <ricotz> Sweetshark, i see, wasnt there when i looked ealier ;)
[13:35] <xclaesse> is there a way to disable apparmor on mission-control ?
[13:36] <xclaesse> now when I install a telepathy-gabble from source, MC won't be able to read my accounts anymore because:
[13:36] <xclaesse> open("/usr/local/share//telepathy/managers/gabble.manager", O_RDONLY) = -1 EACCES (Permission denied)
[13:40] <jdstrand> xclaesse: sudo apparmor_parser -R /etc/apparmor.d/usr.lib.telepathy to temporarily do it. to do it permanently, sudo aa-disable /etc/apparmor.d/usr.lib.telepathy. You can also add entries to /etc/apparmor.d/loca/usr.lib.telepathy such as '  /usr/local/** mr,' and do 'sudo apparmor_parser -r /etc/apparmor.d/usr.lib.telepathy'
[13:40] <jdstrand> /etc/apparmor.d/local/usr.lib.telepathy allows you to make local policy changes
[13:43] <xclaesse> jdstrand, thanks
[13:43]  * xclaesse just disabled permanently, to not get bothered anymore :)
[13:44]  * jdstrand does not generally advocate that ;)
[13:45] <xclaesse> jdstrand, any reason to not include /usr/local in those rules?
[13:46] <jdstrand> it isn't really appropriate for the disto. any number of things can be in there
[13:49] <xclaesse> hm, and teleapthy-* installed in /usr/local/libexec does not seems to get dbus-activated anymore neither
[13:50] <kenvandine> good morning everyone
[13:52] <xclaesse> jdstrand, I don't get it, only root can install in /usr/local
[13:53] <xclaesse> so surely if that's compromised, there is nothing you can do anymore....
[13:54] <jdstrand> xclaesse: /usr/local is site-specific and we don't know what's in there. the profile itself limits what it can read from /usr as well, which is also admin controlled. the point is to have a policy that is still meaningful security-wise. allowing all of /usr/local is too open
[13:58] <xclaesse> jdstrand, is there a way to disable all of apparmor? even after disabling the telepathy rules, telepathy-gabble installed in /usr/local does not get dbus-activated
[14:00] <jdstrand> xclaesse: if you are not getting any apparmor denials (look at kern.log), then it shouldn't be apparmor blocking that. that said, yes you can disable apparmor: boot with apparmor=0
[14:02] <xclaesse> jdstrand, I see no apparmor log in kern.log
[14:03] <xclaesse> even though I'm 100% sure that denial ( open("/usr/local/share//telepathy/managers/gabble.manager", O_RDONLY) = -1 EACCES (Permission denied)) was because of apparmor since disabling telepathy rules made it pass immediately
[14:06] <jdstrand> xclaesse: you might be hitting the kernel rate limiting: sudo sysctl -w kernel.printk_ratelimit=0
[14:08] <jdstrand> xclaesse: surely apparmor was not allowing /usr/local/share//telepathy/managers/gabble.manager, but that doesn't mean it is blocking dbus services (indeed, we don't confine dbus in Ubuntu)
[14:08]  * jdstrand points xclaesse to https://wiki.ubuntu.com/DebuggingApparmor
[14:17] <m4n1sh> jbicha: ping
[14:17] <Robot101> jdstrand: why is this file in /usr/local being prohibited anyway?
[14:17] <jdstrand> because the policy doesn't allow it (see backscroll for why the policy is written this way)
[14:18] <Robot101> I only recently joined
[14:18] <jdstrand> 07:54 < jdstrand> xclaesse: /usr/local is site-specific and we don't know
[14:18] <jdstrand>                   what's in there. the profile itself limits what it can read
[14:18] <jdstrand>                   from /usr as well, which is also admin controlled. the point
[14:19] <desrt> more telepathy apparmor woes?
[14:19] <jdstrand>                   is to have a policy that is still meaningful security-wise.
[14:19] <jdstrand>                   allowing all of /usr/local is too open
[14:19] <Robot101> isn't the policy supposed to protect from buggy software, not buggy administrators?
[14:19] <Robot101> like, /usr/local is still admin-controlled
[14:19] <jdstrand> desrt: if there are bugs in the telepathy profile, please file them
[14:20] <cyphermox> Robot101: there is no reason to put things in /usr/local/ rather than somewhere else in /usr/ allowed by policy.
[14:20] <desrt> jdstrand: just thinking about this recent bug where the profile caused problems with dconf as well
[14:20] <cyphermox> (or elsewhere on the filesystem of course)
[14:20] <jdstrand> Robot101: the policy is not supposed to protect against buggy software, it is supposed to limit the accesses the confined application has access to so an attacker as a smaller attack surface
[14:20] <jbicha> m4n1sh: good morning
[14:20] <m4n1sh> jbicha: good evening :)
[14:20] <Robot101> jdstrand: well... yes. I characterise an application controlled by an attacker to be buggy. :)
[14:21] <Robot101> cyphermox: because the FHS says that's what /usr/local is for, the local administrator to put things which they'd like to be run on the system?
[14:21] <m4n1sh> jbicha: are you in ubuntu-doc team? can you approve my mail which is in the queue? (I am not subscribed, but as per UIFe policy, I need to send a mail to it)
[14:21] <jdstrand> if an admin is installing things in /usr/local, the admin presumably knows what he/she is doing and can update the /etc/apparmor.d/local policy
[14:21] <cyphermox> Robot101: nm me, I thought this was a different kind of policy (regarding packaging things in /usr/local/)
[14:22] <jbicha> m4n1sh: I'm not a list admin, you could try subscribing to the list and then resending your email
[14:22] <cyphermox> regardless, I'm fully behind jdstrand re: the rationale for not allowing /usr/local/ in apparmor policy
[14:22] <m4n1sh> jbicha: looks like the only way left
[14:22] <xclaesse> jdstrand, I doubt ever dev building their sw knows about apparmor
[14:22] <jdstrand> that admin knows better than us where things are being installed. we shouldn't try to guess that or water down the shipped policy
[14:23] <xclaesse> (hm, in the meantime, it seems my gabble gets activated now... wondering what I changed...)
[14:23] <Robot101> I don't think that follows at all - the admin can't necessarily be expected to be familiar enough with apparmor or telepathy to correctly reconfigure those things
[14:23] <jdstrand> xclaesse: that may be true, but an admin can ask for help, like you did. we don't want to reduce the security policy of the (vast) many for the few
[14:23]  * kenvandine runs out for a bit, bbl
[14:24] <Robot101> I still don't understand what "vulnerability" running stuff which was put into /usr/local by root actually exposes you to - root can disable apparmor or any policy anyway can't they?
[14:24] <jdstrand> if you are an admin, you by definition should know how to administer the system. apparmor provides debug logs for denials
[14:25] <jdstrand> Robot101: you are conflating two things. we are protecting the normal user. if there is a security bug in telepathy, we want to limit what it has access to. just like we allow specific accesses to /usr, we don't allow full access to /usr/local. if you want full access to /usr/local, put it in /etc/apaprmor.d/local
[14:26] <jdstrand> Robot101: if someone were running telepathy as root, it would prevent a security bug from allow root to modify policy via telepathy
[14:26] <jdstrand> apparmor is root strong
[14:26] <Robot101> is there some middleground where we could provide the policy for, eg, telepathy to work properly in /usr/local, but have it disabled by default?
[14:27] <jdstrand> well, we have that now. anyone can add whatever they want to /etc/apparmor.d/local/usr.lib.telepathy
[14:27] <Robot101> the policy embodies a load of domain knowledge in how telepathy and apparmor should interact which I don't expect on average, an admin would have - and they'd just disable apparmor as a consequence of "stuff doesn't work"
[14:27] <jdstrand> as for some sort fo runtime variable-- it would be possible, but then the developer still needs to know to switch it
[14:27] <desrt> Robot101: +1
[14:28] <desrt> my general approach to apparmor is the same as my general approach to selinux: my life is a lot easier when i turn it off
[14:28] <jdstrand> which, in this case, they have to know about apparmor, and can just add the rule in /etc/apparmor.d/local/usr.lib.telepathy
[14:28] <desrt> over-active policies just make me turn it off that much faster
[14:28] <Robot101> yeah, but we're going to get a bunch of support requests from this - "I installed this; stuff didn't work" "ok, disable apparmor"
[14:29] <jdstrand> desrt: that is very unfortunate. if there iare bugs against apparmor policy in Ubuntu, please file them. we work extremely hard to have the apparmor policy work for normal users in the default install
[14:29] <xclaesse> just like SElinux
[14:29] <Robot101> the net result of neither us nor the administrator understanding or caring about apparmor. if we could say run "sudo aa-enable telepathy-local" or whatever, that'd be far nicer.
[14:29] <desrt> jdstrand: i think i have a fundamental disagreement with the idea behind things like apparmor/selinux
[14:29] <jdstrand> Robot101: we've shipped apparmor policy for various things since hardy. this is not new. people file bugs, we fix them
[14:31] <jdstrand> desrt: then we disagree. I would appreciate if you would not promote deactivating a meaningful protection that is protecting literally millions of users because you have a philosophical problem with it. by all means, on any systems you administer, do what you want, but the protection is real
[14:31] <jdstrand> plenty of times remote code execution vulnerabilities were reduced to a denial of service because of apparmor protections
[14:31] <jdstrand> (and these are noted in our USNs)
[14:33] <seb128> desrt, Robot101: well, normal users don't install stuff in /usr/local or when they do that 90% of the time bite them back later
[14:33] <seb128> some days I think we should drop /usr/local being loaded before /usr by default
[14:33] <jdstrand> Robot101: if you would like that functionality, please file a bug and submit a patch. we have been shipping a telepathy policy since oneiric. we have had extremely few bugs against the policy when compared against the number of users
[14:34] <seb128> it keeps bitting people who do make install without understanding and 1.5 year later wonder why things stop working because they have a 1.5 years old glib in local
[14:34] <desrt> seb128: i think /usr/local is a mistake from a forgotten era
[14:34] <jdstrand> and when there are bugs, I take them seriously and fix them
[14:34] <seb128> desrt, right, Robot101 seems to think it's not useful,used though
[14:34] <desrt> seb128: that doesn't change my fundamental hate for selinux and (to a lesser extent) apparmor :)
[14:34] <Robot101> jdstrand: I'm not 100% convinced either way - I just wanted to hear the arguments :)
[14:35] <Robot101> I don't disagree that a maximally-restrictive but properly-functioning policy by default is the best thing
[14:35] <xclaesse> note that it's not only /usr/local, if you install a telepathy CM in any prefix, you won't be able to use it until you disable apparmor rule
[14:35] <seb128> Robot101, your users should never have to fiddle with /usr/local
[14:36] <seb128> xclaesse, that seems wrong, the normal /usr directory for those should be whitelisted
[14:36] <xclaesse> seb128, that's even worse, you mean I should make install into /usr ??
[14:36] <seb128> xclaesse, no, I mean normal users shouldn't make install ever
[14:37] <jdstrand> desrt: I doubt I would convince you of anything else. but know that the security team is keenly aware of people knee-jerkingly turning off selinux and do not want them to turn off apparmor. we strive hard to make sure things work for people. there are bugs-- report them and we'll fix them. we also are keen to not break things-- look at the disabled by default rsyslog policy for evidence. we ship it, but could not ship it enabled for all Ubun
[14:37] <xclaesse> yeah, normal users are on windows7 anyway :p
[14:37] <xclaesse> seb128, devs are pretty common linux users...
[14:37] <Robot101> xclaesse: seb128 has a point - old crap in /usr/local probably breaks our stuff more often than apparmor does :)
[14:37] <seb128> xclaesse, dev should be able to run aa-complain or have a custom profile
[14:37] <desrt> jdstrand: i appreciate your position and i do appreciate that apparmor is quite a lot less bad than selinux
[14:38] <desrt> jdstrand: but these sort of added-on-after-the-fact approaches to security will always have these sorts of problems
[14:39] <didrocks> chrisccoulson: hey, are you still on unity on precise, right?
[14:39] <desrt> by and large, the 'upstream' world has failed to be convinced that one of these systems is necessary or useful
[14:39] <desrt> and therefore software is not written with it in mind
[14:39] <jdstrand> certainly. unfortunately stuff has security bugs and we can't fix them before the fact. telepathy is a network listening daemon installed on all Ubuntu systems and in use on many. a bug in it is scary stuff, so we do the best we can with what we've got
[14:39] <mdeslaur> desrt: that's because upstream thinks they write secure code :)
[14:39] <desrt> no.  it's more like upstream thinks that the standard unix permissions model will be good enough
[14:40] <jdstrand> (well, we could fix them before the fact with a deep audit, but then the codebase changes so significantly that audit would soon be out of date...)
[14:41] <desrt> honestly, this problem won't be solved by something like apparmor
[14:41] <desrt> it's just a hack/workaround
[14:41] <desrt> we need a proper privilege separation concept in the kernel as a first-class citizen
[14:41] <desrt> something like what android does, for example
[14:41] <Robot101> telepathy upstream doesn't think we write secure code - we designed telepathy specifically so it /could/ be thusly contained :)
[14:41] <Robot101> I mean, we load in libpurple. we're automatically doomed.... :P
[14:41] <xclaesse> each distro having completely different security rules/tools does not help trusting them...
[14:41] <desrt> (although that's obviously insane for us to adopt in its current form)
[14:42] <Robot101> olpc's rainbow thing did the same uid containment thing pretty nicely
[14:42] <mdeslaur> desrt: we're more like what ios does
[14:42] <desrt> things like disabling ptrace by default are quite helpful
[14:42] <desrt> but probably nowhere near good enough
[14:43] <desrt> anyway.. what i think i mean is that there needs to be higher walls between processes as a basic property of the normal functioning of the operating system
[14:44] <desrt> not according to some policy written by a human that changes from time to time
[14:44] <desrt> until that happens we are failing
[14:45] <desrt> pitti: ping
[14:46] <pitti> hello desrt (on call)
[14:46] <desrt> pitti: just a poke about XDG_RUNTIME_DIR
[14:46] <desrt> pitti: things are going to start getting *really* bad for dconf+nfs if you don't support this
[14:48] <desrt> pitti: i have an incoming patch, basically.  i could probably argue that we're well past feature freeze and i should hold off until next cycle
[14:48] <desrt> pitti: but it's absolutely certainly going to be in by early next cycle
[14:49] <desrt> if you will go systemd already next cycle and don't want to waste time doing the XDG_RUNTIME_DIR upstart hack in the meantime i could use that as an argument to wait
[15:03] <mitya57> jbicha: Can you please upload gnome-panel 3.3.91? It fixes half of bug 828392 :)
[15:03] <ubot2`> Launchpad bug 828392 in gnome-panel "light-themes don't display well in gnome-panel 3+" [Low,Triaged] https://launchpad.net/bugs/828392
[15:20] <dobey> seb128: i'm going to ping moch to make a rb release, when that side of the globe comes on-line later today, but if he doesn't make a tarball release tonight, do you think it would be better to package a snapshot, or to cherry-pick some fixes into the ubuntu package?
[15:21] <seb128> dobey, either way, I didn't look at git enough but I would be in favor of snapshot to reduce the delta with the next tarball
[15:22] <dholbach> hiya
[15:23] <dholbach> can we do something about the desktop sponsoring items? there's 22 of them (not only quicklists)
[15:23] <dobey> seb128: ok. it brings back magnatune plug-in i think, and a few other big changes (like getting rid of most all the gtk_dialog_run usage).
[15:23] <dobey> ricotz: i guess i should ask you if you have any opinion on it as well? ^^
[15:24] <seb128> dobey, open a ffe bug I guess
[15:24] <seb128> dholbach, heya
[15:24] <dobey> ok
[15:25] <dholbach> hey seb128
[15:25] <seb128> dholbach, I will try to have a look but today is GNOME 3.3.91 tarball day so it's likely to not be your lucky day for sponsoring
[15:26] <dholbach> thanks seb128
[15:26] <didrocks> seb128: when you get a chance, can you try latest compiz and unity (I just copied them in unity-team/ppa)?
[15:26] <seb128> didrocks, ok
[15:26] <didrocks> seb128: seems that most of RC bugs are fixed, but I still don't get any appmenu showing on pressing alt on Qt app or xul ones
[15:27] <didrocks> thanks seb128 :)
[15:27] <seb128> ok
[15:27] <didrocks> seb128: I can help you with 3.3.91 btw now
[15:27] <seb128> didrocks, \o/
[15:27] <seb128> didrocks, well waiting for tarballs still mostly but that will start soon :p
[15:27] <didrocks> let's do no-brainer uploads :)
[15:27] <didrocks> ok ;)
[15:27]  * didrocks opens the pad
[15:28] <seb128> didrocks, maybe you can get the gedit ql patch in? It seems mostly good on bugzilla and they already rolled their tarball for this week
[15:31] <didrocks> seb128: hum, sorry? I don't see it on the gnome ftp ML
[15:32] <seb128> didrocks, "it"?
[15:32] <didrocks> gedit
[15:33]  * Sarvatt will be extremely happy to see https://bugs.launchpad.net/unity/+bug/942625 fixed in 5.6.0, all macs are hanging in unity when 3 fingers are used on the bcm5974 touchpads and there are bugs all over the place about it
[15:33] <ubot2`> Launchpad bug 942625 in unity "Unity hangs when touching my touchpad/trackpad" [Undecided,Confirmed]
[15:33] <seb128> didrocks, sorry I was unclear, jbicha did it on friday already, it's just the unity list patch
[15:33] <didrocks> ah ok :) didn't get any newer than 3.3.5 :)
[15:33] <didrocks> ok, adding the ql then, I guess it's on the sponsoring list
[15:34] <seb128> didrocks, bug #938748
[15:34] <ubot2`> Launchpad bug 938748 in gedit "Add Unity Quicklist support" [Wishlist,Triaged] https://launchpad.net/bugs/938748
[15:34] <didrocks> seb128: thanks
[15:34] <seb128> yw
[15:45] <BigWhale> Why do I always find these potentially useful programs that are unmaintained and broken? :(
[15:58] <BigWhale> It seems I'll be picking up another thing that barely works and I'll fix it ...
[16:15] <ockham> anyone feel like reviewing this?
[16:15] <ockham>  https://code.launchpad.net/~ockham-razor/unity-lens-bliss/distutils/+merge/84702
[16:31] <didrocks> m4n1sh: around?
[16:33] <seb128> didrocks, there are some tarballs now if you feel like doing some
[16:33] <m4n1sh> didrocks: yes
[16:33] <didrocks> seb128: ok :)
[16:34] <didrocks> m4n1sh: famous last words? Going to update to newer a-l-m, nothing I should be awared of apart from your email?
[16:34] <m4n1sh> didrocks: what else do you want to know?
[16:34] <didrocks> m4n1sh: just checking that anything went badly meanwhile :)
[16:35] <m4n1sh> ha ha. nothing here
[16:35] <m4n1sh> brb. dinner
[16:36] <didrocks> m4n1sh: enjoy :)
[16:36] <kenvandine> seb128, i'm going to start uploading all the packages that need to change for the new empathy to the ~ubuntu-desktop PPA
[16:37] <kenvandine> even pidgin will need a rebuild :(
[16:37] <seb128> kenvandine, ok
[16:37] <seb128> why?
[16:37] <kenvandine> farstream build dep
[16:37] <seb128> oh, ok
[16:37] <kenvandine> so the package rename
[16:53]  * didrocks knows someone who didn't update the gnome-utils debian/watches :p
[16:53] <Riddell> wasnae me!
[16:54] <Riddell> didrocks: how much do you use debian/watches files?
[16:55] <didrocks> Riddell: I do uscan on debian/ only bzr dir to check the version bump I need to do in debian/changelog
[16:55] <Riddell> didrocks: how do you know you need to do that?  surely if upstream tells you there's a new version you already don't need to run uscan
[16:56] <seb128> didrocks, wazza! gnome-screenshot? iz new source with a correct watch!
[16:56] <didrocks> Riddell: so, you always download manually the tarball for you bzr branch
[16:57] <didrocks> seb128: ah interesting… in fact, was me :) the parent branch was gnome-utils
[16:57] <didrocks> and somehow bzr didn't complain
[16:57] <didrocks> interesting
[16:57] <seb128> ;-)
[16:57]  * didrocks rm -rf * and bzr branch a clean new complete seb128's bzr branch :)
[16:58] <seb128> didrocks, we use full source now, i.e ubuntu:gnome-screenshot
[16:58] <seb128> did I forgot to drop the vcs from the control?
[16:58] <didrocks> oh?
[16:58] <seb128> that I might have done :p
[16:58] <didrocks> no, I'm just using old branches
[16:58] <didrocks> didn't try debcheckout
[16:58]  * didrocks does to check
[16:58] <seb128> didrocks, I was too lazy to create a project and launchpad wouldn't let me use ~ubuntu-desktop/gnome-screenshot without a project with the same name
[16:58] <didrocks> seb128: you dropped it :)
[16:58] <didrocks> ahah
[16:58] <didrocks> I thought you changed your mind!
[16:58] <didrocks> just for less than a minute :)
[16:59] <seb128> ;-)
[16:59]  * didrocks apt-get source then
[17:13] <seb128> dobey, the gsettings key mirco listed on that bug exists
[17:13] <seb128> dobey, your notify-osd is correctly installed?
[17:28] <dobey> seb128: it's not incorrectly installed. at least, it's installed as the packaging system installed it. and dconf-editor shows no notify-osd keys in it under com.canonical
[17:28] <seb128> dobey, gsettings list-recursively com.canonical.notify-osd
[17:28] <seb128> what does that say?
[17:29] <seb128>   <schema id="com.canonical.notify-osd" path="/apps/notify-osd/">
[17:29] <seb128> dobey, I guess it's under apps > notify-osd in the editor
[17:29] <dobey> seb128: oh, hmm. that does list them
[17:29] <dobey> oh
[17:29] <dobey> well that's a bug then i guess
[17:29] <seb128> right
[17:30] <seb128> I blame gsettings for have id and path
[17:30] <seb128> rather than using the id as a path :p
[17:33] <dobey> but still, notify-osd doesn't have a setting for that key, which does what i want it to do. and for some reason it's not an enum, so i can type any value into the list, even though it won't work. whee
[17:36] <seb128> dobey, what are you trying to get?
[17:38] <Saviq> desrt, hey, didrocks pointed me your way with a problem we have in unity-2d tests
[17:38] <Saviq> desrt, one of our tests relies on a schema being installed
[17:38] <Saviq> but we'd rather not actually install the package that provides it
[17:38] <Saviq> so I created a fake schema, compiled it and pointed GSETTINGS_SCHEMA_DIR to the dir
[17:39] <Saviq> desrt, but that didn't help, not even with GSETTINGS_BACKEND=memory
[17:40] <Saviq> desrt, it would be great if you'd have an idea how to tackle that
[17:40] <desrt> Saviq: should have worked...
[17:40] <desrt> the backend has nothing to do with it, though
[17:40] <desrt> Saviq: you point the schema dir to the place that has the gschemas.compiled?
[17:42] <seb128> saviq: did you run glib-compile-schemas on that dir?
[17:42] <Saviq> seb128, yes
[17:42] <Saviq> desrt, yes
[17:42] <desrt> should be working, then
[17:42] <Saviq> if I go `gsettings list-schemas` then it works
[17:42] <Saviq> shows the schema
[17:42] <desrt> sounds working, indeed
[17:42] <desrt> but g_settings_new() for the same schema fails?
[17:43] <Saviq> desrt, we're not using those APIs directly, let me try and find out what's our path
[17:44] <Saviq> desrt, oh it seems you wrote QConf - so yeah, we're using that :)
[17:44] <desrt> oh.
[17:44] <dobey> seb128: i want the notifications to only appear on the primary display
[17:45] <desrt> Saviq: i bet it doesn't look at the environment variable
[17:45] <desrt> nope... it does
[17:45] <desrt> it really should be working
[17:45] <Saviq> desrt, ok so I'd say I'm not setting the env var soon enough
[17:45] <desrt> https://gitorious.org/dconf-qt/dconf-qt/blobs/master/lib/qconfschema.cpp#line71
[17:46] <Saviq> desrt, ok let me try something else
[17:46] <seb128> dobey, isn't that the default mode?
[17:48] <dobey> seb128: no. as per my bug report, it pops at the far right of all screens
[17:48] <dobey> and dbarth changed my bug to be a bug about it not popping on the screen with the foucsed window; which just seems like a silly thing to do anyway, to me
[17:51] <seb128> what, showing notification on the screen you are looking at?
[17:54] <dobey> seb128: focused window != eye focus
[17:54] <seb128> dobey, well you have a good chance that you are working on the focussed application so it's a reasonable bet
[17:54] <seb128> or rather looking at the screen which has the focussed application
[17:55] <dobey> i very often have something focused on one screen, and am looking at firefox or something on the other screen (and even scrolling the unfocused window)
[17:56] <dobey> and even when my eye focus is on the right screen, it's usually toward the left of the screen, not the center of it (generally, my eye focus stays near the split between both screens), and the notification is so far away that by the time i notice there is a notification, it is fading away, and i can't read it or even see what it was for
[17:57] <seb128> dobey, right, I don't argue your usecase it's not valid, I'm just saying the "use the screen which has the focus" is a reasonable default
[17:57] <seb128> dobey, some user do look at the screen they are working on ;-)
[17:57] <dobey> i don't think it is a reasonable default, when the rest of unity doesn't do that.
[17:57] <dobey> the rest of unity is on all screens at all times
[17:57] <seb128> dobey, should be on all screen by default?
[17:57] <seb128> yeah, works for me
[17:57] <dobey> so the notification default should probably be to pop on all screens by default
[17:57] <seb128> dobey, well it was not at the time notify-osd took that behaviour
[17:58] <dobey> sure
[17:58] <seb128> but yeah, since that changed this cycle notify-osd should probably follow
[17:58] <dobey> well, it doesn't seem to have taken that behavior yet. since it's not the default and i never changed the config :)
[17:58] <seb128> right
[17:58] <seb128> you should open a bug about that if there is not one
[18:00] <dobey> well i made that comment in my bug after dbarth changed it
[18:00] <dobey> though i don't know why he made it affect unity, since it's all in notify-osd
[18:01] <seb128> dobey, check with dbarth I guess
[18:05] <jcastro> Anyone have any insight on bug #924612 ?
[18:05] <ubot2`> Launchpad bug 924612 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGABRT in __GI___assert_fail()" [High,Confirmed] https://launchpad.net/bugs/924612
[18:06] <jcastro> specifically if anyone has a clue on things I can do less of to make it not crash. :)
[18:06] <dobey> jcastro: log in less?
[18:06] <pitti> seb128: want me to look into the new glib version, or are you on it?
[18:06] <dobey> :)
[18:06] <seb128> jcastro, it's not a bug
[18:06] <seb128> pitti: I'm on it
[18:06] <seb128> pitti: but thanks ;-)
[18:06] <pitti> ack
[18:06] <jcastro> seb128: Aww man, I was hoping it was a GTK boog
[18:06] <seb128> pitti: they have new g-i tarballs
[18:07] <pitti> seb128: oohh, finally
[18:07]  * pitti grabs in pad
[18:07] <seb128> pitti: if you want to do those
[18:07] <dobey> seb128: anyway, i just filed #947339 for the gsettings schema bug. :)
[18:07] <seb128> dobey, thanks
[18:18] <didrocks> have a good night
[18:21] <Saviq> desrt, take a look here http://pastebin.ubuntu.com/870263/
[18:21] <Saviq> desrt, do you recognize where the "Settings schema 'com.canonical.Unity' is not installed" message comes from?
[18:22] <desrt> Saviq: why are you root?
[18:22] <Saviq> desrt, that's pbuilder
[18:22] <desrt> okay
[18:22] <desrt> you will definitely need to use the memory backend in this case
[18:22] <desrt> because you don't have a dbus
[18:22] <desrt> but qconf doesn't have backends
[18:22] <desrt> so you're screwed :)
[18:23] <desrt> i think you can't do what you're trying to do, basically
[18:23] <desrt> unless you whip up a fake dbus
[18:24] <Saviq> desrt, but then I'd have to launch the dconf backend with GSETTINGS_SCHEMA_DIR, right?
[18:24] <desrt> yes
[18:25] <Saviq> desrt, ok thanks, will work off of that
[18:27] <dbarth> dobey: because affecting unity is our way to track that along with the main unity release
[18:27] <dbarth> dobey: otherwise, it all goes into /dev/null
[18:28] <dobey> that is confusing
[18:28] <dbarth> dobey: and as for the focus, i'll clarify with john tomorrow
[18:28] <dobey> ok
[18:28] <dbarth> dobey: for you, but not for the people who have to release it ;)
[18:28] <dbarth> whether it should be window focus or just mouse focus
[18:28] <dbarth> i guess the former
[18:28] <dobey> i don't want it to be any focus. and the default should be all screens i guess
[18:29] <dbarth> so a patch to determine which monitor holds the focused window would be nice if you know how to do that quickly
[18:29] <dobey> that's easy to do, and afaict, notify-osd already does that, it just isn't the default
[18:30] <dobey> indeed
[18:30] <dobey> just tested it, and it will pop up on the screen where the window is focused
[18:36] <ronoc> mvo - ping ?
[18:36] <ronoc> that signal on the package kit interface has changed
[18:36] <ronoc> by the looks of things
[18:37] <ronoc> so now it's restartschedule instead of restartscheduled ?
[18:37] <ronoc> is this correct ?
[18:37] <ronoc> i.e. i don't want to push a release with this small change if it is to be reverted
[18:52] <micahg> seb128: your glib changelog mentions pcre 8.30, but precise only has 8.12
[18:56] <seb128> micahg, I'm just copying the upstream NEWS
[18:56] <seb128> micahg, that's the pcre copy in the glib source
[19:01] <micahg> seb128: right, just wanted to make sure that we weren't expecting anything from it :)
[19:03] <dobey> hrmm
[19:03] <dobey> has anyone else experienced lost button press/release events in precise?
[19:05] <dobey> like, sometimes i will click on the send/recv icon in the evolution toolbar, and it will press, but not pop back up (like it stays pressed in), and thus not actually check for new mail, but it doesn't have a mouse grab, and i can click on other windows/applications just fine
[19:23] <seb128> dobey, I noticed that a few times in the control center breadcumb while doing debugging
[19:25] <dobey> seb128: i wonder if it's a gtk+ issue, or something one of the unity things is doing that breaks it
[19:26] <seb128> dobey, not sure either
[19:26] <mvo> glatzor: <ronoc> that signal on the package kit interface has changed. so now it's restartschedule instead of restartscheduled ? <- did you see that?
[19:29] <nessita> hello everyone! quick questions, would anyone know if changing a string from using "old" python string formatting to new style triggers a retranslation of the string? an example: going from "Hello %(world)s" to "Hello {world}"
[19:29] <dobey> nessita: yes
[19:29] <nessita> dobey: thanks
[19:32] <seb128> jbicha, hey
[19:32] <seb128> jbicha, is there any reason you stopped using the pad?
[19:35] <jbicha> seb128: no, except I wasn't going to do many uploads until tonight
[19:36] <seb128> jbicha, well I noticed you ignored my gedit comment on friday and uploaded ghex while it was in the "to claim"
[19:36] <seb128> jbicha, so I was wondering ;-)
[19:38] <jbicha> seb128: oh, I thought the gedit quicklist was waiting on upstream
[19:39] <jbicha> I also didn't expect the pad to say anything over the weekend so I didn't look
[19:39] <seb128> jbicha, sort of, it seemed on good enough track for it and since they already rolled their tarball for this week
[19:39] <seb128> jbicha, no worry ;-)
[19:39] <seb128> jbicha, I just wanted to make sure you didn't ignore it for good because I'm working on some updates :p
[19:40] <jbicha> yeah I generally keep an eye on it when gnome has a big release day
[19:41] <seb128> jbicha, ok, great ;-)
[19:41] <seb128> jbicha, how are you btw? ;-)
[19:41] <seb128> jbicha, did you talk to pitti about updating gnome-keyring yet?
[19:41] <seb128> we should do that this week if at all
[19:42] <seb128> since gnome-shell seems to depend on that as well now
[19:46] <jbicha> seb128: not yet, he's gone for today right? I think it just needs a ffe now
[19:46] <seb128> jbicha, yes
[19:46] <ricotz> seb128, dobey, hi, i am all in favor for a git snapshot of rhythmbox if there is no release planned
[19:46] <seb128> ricotz, hey, thanks
[19:47] <seb128> jbicha, "just", I emailed upstream a few weeks ago and he said most work in this cycle was gnome-shell integration work
[19:47] <seb128> jbicha, he also said that "fallback" didn't get that much testing
[19:47] <ricotz> seb128, if you want to pick it up a tarball there is one from today in my ppa
[19:48] <seb128> jbicha, which is not very encouraging when that's what we use for our default desktop experience ;-)
[19:48] <seb128> ricotz, I will let dobey deal with it but thanks
[19:48] <dobey> ricotz: hey, thanks.
[19:48] <ricotz> seb128, alright
[19:49] <ricotz> dobey, go for it then
[19:49] <jbicha> seb128: I'll push the gnome-keyring stuff to the desktop ppa then?
[19:49] <seb128> jbicha, no, please not, get pitti to ffe ack it first
[19:50] <seb128> the desktop ppa is stuff that are aiming at landing this cycle
[19:50] <ricotz> jbicha, hi, i guess you are running the new gnome-keyring packages?
[19:50] <seb128> we shouldn't put stuff that might get ffe nacked there
[19:50] <dobey> ricotz: yeah, i'm just waiting for moch to come on-line, and reply about making a tarball
[19:50] <ricotz> dobey, he is online
[19:51] <glatzor> mvo, ronoc what is the excat problem?
[19:51] <dobey> ricotz: he's connected, but i suppose inactive, as he hasn't replied
[19:51] <seb128> glatzor, mvo: the issue is indicator-session not picking the "need to restart"
[19:51] <ricotz> dobey, ah, i see
[19:51] <seb128> glatzor, mvo: seems like ronoc debugged it today and figured that the signal changed since he wrote the code earlier in the cycle
[19:52] <dobey> ricotz: it's only 6 am there still :)
[19:54] <ricotz> dobey, ok, so he still needs some time ;)
[19:54] <glatzor> seb128, mvo I am not aware of a change. it must have been a typo in indicator. the indicator is still not using the pk glib client?
[19:56] <jbicha> ricotz: yes, gnome-keyring seems fine here
[19:56] <seb128> glatzor, it is, see https://code.launchpad.net/~cjcurran/indicator-session/migrate-to-new-apt-api/+merge/92088
[19:56] <seb128> glatzor, that's what got merged
[19:56] <seb128> glatzor, it has a + else if (g_strcmp0(signal_name, "RestartScheduled") == 0) {
[19:56] <ricotz> jbicha, ok, i was holding them back for now
[19:58] <jbicha> ricotz: please try them out :)
[19:59] <ricotz> jbicha, i like to, but i am already dealing with other problems and dont wont to risk to loose the gpg-agent
[19:59] <ricotz> i will give them a try later this week
[20:00] <ricotz> seb128, which reminds be careful when there is a gtk3 tarball ;)
[20:00] <seb128> ricotz, still breaking scrolling?
[20:00] <ricotz> yes, pretty much
[20:01] <seb128> :-(
[20:01] <seb128> ricotz, even current trunk?
[20:01] <seb128> ricotz, where,in which way?
[20:01] <ricotz> although my snapshot is 10hours old
[20:02] <ricotz> seb128, no way to properly use the scrollwhell
[20:02] <ricotz> surprisingly it works in gedit
[20:02] <ricotz> hardly in nautilus
[20:03] <ricotz> not working in gnome-terminal
[20:04] <seb128> ricotz, is there a bug upstream? did you mention it on the gtk channel?
[20:05] <ricotz> seb128, i guess one could turn off the xi2.2 support which might make it work
[20:05] <ricotz> seb128, i mentioned it on the weekend to mclasen and he confirmed it
[20:05] <ricotz> i dont know if there is a report
[20:05] <seb128> ricotz, ok, let's hope they will fix it for the release
[20:06] <seb128> ricotz, did you try today? there was some commit yesterday like http://git.gnome.org/browse/gtk+/commit/?id=ab87579e3f7c63ab7b48b535c0aaae959b47882b
[20:06] <seb128> ricotz, or http://git.gnome.org/browse/gtk+/commit/?id=3dd5e88c07f659d66ee0f7305a96b51b7fe1072d
[20:06] <ricotz> 19 hours	gdk: Remove an unused enumeration
[20:08] <ricotz> (this is a snapshot base ^  -- https://launchpad.net/~ricotz/+archive/testing/+sourcepub/2288187/+listing-archive-extra)
[20:09] <thumper> morning
[22:49] <dupondje> Are there plans to integrate thunderbird calendar into gnome? Cause now it still connects to evolution
[22:52] <micahg> dupondje: not this cycle AFAIK
[23:07] <seb128> good evening