[06:25] <kklimonda> hey, can someone take a look at https://code.launchpad.net/~kklimonda/evolution-data-server/ubuntu/+merge/53196 when you have a moment? It's a cosmetic change, not really worth its own upload (hence I haven't subscribed ubuntu-sponsors) but It's still worth updating when someone makes a new upload.
[07:27] <pitti> Good morning
[07:43] <TheMuso> Hey pitti.
[07:43] <pitti> hey TheMuso, had a nice weekend?
[07:43] <TheMuso> pitti: Very nice indeed thanks, although was still warm here. Its a bit cooler today however.
[07:44] <pitti> spring has just begun here, I for one am happy that it's finally not freezing any more :)
[07:44] <TheMuso> I'm somewhat the other way. Looking forward to a bit of cooler weather.
[07:45] <TheMuso> Which of course will change com the end of winter, or sooner.
[08:03] <didrocks> good morning
[08:15] <pitti> bonjour didrocks!
[08:15] <didrocks> Guten Morgen pitti :)
[08:20] <rodrigo_> morning
[08:24] <didrocks> hey rodrigo_
[08:25] <rodrigo_> hi didrocks
[08:27] <jbicha> will the gnome3 ppa be getting a rebuild soon for 2.91.91?
[08:28] <Sweetshark> Morning all
[08:28] <rodrigo_> jbicha, yes, I've been on vacation last week, so didn't do any update, but will get it up-to-date in the next few days
[08:29] <jbicha> rodrigo_: thanks, I was just curious
[09:04] <chrisccoulson> good morning everyone
[09:07] <pitti> hey chrisccoulson
[09:07] <chrisccoulson> hi pitti, how are you?
[09:08] <pitti> I'm great, thanks! Had a Taekwondo camp yesterday again, and helped a friend moving on Saturday, so some muscle strain :)
[09:08] <pitti> but it was really good yesterday
[09:17] <pitti> chrisccoulson: btw, I did some samplings of the existing search plugins, and some are already localized; so I extracted them all from maverick's -base packages and committed them into langpack-o-matic
[09:17] <pitti> chrisccoulson: writing the necessary code/test cases now
[09:17] <pitti> chrisccoulson: I propose we only install them into -base and do a full maverick -base update, to clean up the replaces: mess
[09:18] <pitti> dpm: ^ FYI
[09:18] <pitti> dpm: (I just requested a full maverick export)
[09:18] <pitti> then maverick and natty will be consistent, and both will work again
[09:20] <dpm> hey pitti good morning, sounds good. How will this affect the ongoing testing of maverick langpacks? Do you want to call it off, release new full langpacks and re-new the call for testing?
[09:20] <chrisccoulson> pitti - thanks for working on this. i didn't realise that some were already localized :/
[09:26] <pitti> I'm off for some two hours for a doctor appointment
[09:34] <mpt> mvo, good morning
[09:36] <mvo> hey mpt
[09:37] <mpt> mvo, have you received any contributions this cycle on bits of <https://wiki.ubuntu.com/SoftwareUpdates>?
[09:38] <mvo> mpt: not that I'm aware of
[09:38] <mvo> mpt: there is the branch about renaming update-notifier to update-manager-daemon
[09:38] <mvo> but that was prev cycle iirc
[09:38] <mpt> ok
[09:39] <mvo> mpt: haven't look at the spec in detail since a while, but I remember we wanted to push more updates into the background, right?
[09:40] <mvo> mpt: oh, there was another patch to run the "update" automatically on manual invocation via the desktop file
[09:40] <mpt> mvo, more updates in the background was mdz's goal, but that's more a platform team thing to decide that they're confident enough to make it the default
[09:41] <mvo> mpt: fair enough, some support has landed in the unattended-upgrades branch now (but not enabled by default yet). so we can ask people running natty (once its final) to use it and give us feedback
[09:42] <mpt> Correcting the settings probably should happen before changing the defaults, otherwise there would be all sorts of confusion about exactly what had changed
[09:44] <mvo> indeed
[09:44] <mvo> I think that this is something we should push for next cycle
[09:44] <mvo> fixing the backend to be proper polkit etc
[09:45] <mpt> yah
[11:29] <pitti> smspillaz: since Friday or today (ish) I have huuuge shadows around the focussed window, which spills over a lot in the adjacent terminal windows. is that a bug, or meant to be that way?
[11:36] <smspillaz> pitti: its meant to be that way
[11:36] <smspillaz> we could clip the shadows of windows when they are close to each other but *shudder* that's a hack
[11:36] <pitti> ugh
[11:37] <pitti> the spillover to the adjacent virtual desktop is now also much worse than before
[11:39] <pitti> smspillaz: e. g. this (http://people.canonical.com/~pitti/tmp/shadow-spillover.png) is workspace 2 with a fullscreen firefox
[11:39] <pitti> you still see the shadow from teh terminal on workspace 1
[11:42] <and471> can someone upload the images http://i.imgur.com/CJL4C.jpg http://i.imgur.com/CJL4C.jpg to a site such as imagebin.org
[11:43] <and471> that way I can see them (blocked by content screening for me)
[11:43] <and471> ?
[11:47] <pitti> and471: http://imagebin.org/142915
[11:48] <and471> pitti: thanks very much
[12:40] <Laney> anyone seen asac recently? is he on holiday?
[12:41] <seb128> Laney, the canonical calendar says he's on holiday today at least
[12:41] <seb128> seems he should be back tomorrow
[12:46] <Laney> ok
[13:10] <ari-tczew> Hello. I noticed that some developers from desktop team often upgrade packages in Ubuntu if package exists in Debian. I was wondering why get upload access in Debian and upgrading there?
[13:12] <seb128> there is quite a bunch of sources updates in debian and synced but it's not always pratical
[13:12] <seb128> it requires having a debian installation and testing those there as well which is extra work
[13:12] <ari-tczew> why not practical?
[13:12] <seb128> debian often doesn't track unstable series as we do
[13:13] <seb128> there is also quite some sources who have a maintainer who handle updates in a slower way than debian but doesn't want someone taking over his package
[13:13] <seb128> than "ubuntu" rather
[13:14] <ari-tczew> seb128: I see not logical flow of work. e.g. Robert Ancell upgrades package then some day later merge with Debian. Why not get sync/merge directly from Debian?
[13:15] <ari-tczew> anyway later merges do extra work as well
[13:15] <seb128> because we don't know when Debian will update and it makes sense to wait on them
[13:15] <seb128> they could not upgrade before natty
[13:15] <ari-tczew> seb128: so I'm talking: get upload access in Debian and upgrade there.
[13:16] <seb128> it doubles the work and often those have a maintainer and not free to update
[13:16] <seb128> Debian updates are usually done by the maintainer not free to be done by whoever wants to do it
[13:17] <ari-tczew> seb128: actual model doesn't double the work? maintainer and Robert upgrade packages. I'm counting this 1...2... double work!
[13:17] <seb128> right, but not double the work for us
[13:18] <seb128> it's two people doing the work once,it's not one doing it twice
[13:18] <ari-tczew> I don't understand and it's still uneconomical for me.
[13:18] <seb128> well you might need to try for a bit to understand it ;-)
[13:19] <ari-tczew> seb128: no, this is uneconomical
[13:19] <ari-tczew> and eod.
[13:19] <seb128> I've basically stopped maintaining things in Debian when we have an Ubuntu diff
[13:19] <ari-tczew> seb128: so let's blacklist all packages related to desktop team.
[13:19] <seb128> because it means: having to have a Debian unstable system uptodate to be able to do binaries build there, having the upload the binaries to debian and the source to debian and ubuntu
[13:19] <ari-tczew> it doesn't make sense merge with Debian once a year.
[13:20] <seb128> having to deal with bugs in debian due to your update
[13:20] <seb128> having to ask for a sync request
[13:20] <seb128> test your update on both distros
[13:20] <seb128> you basically need 2 computers instead of one
[13:20] <seb128> or to play with vms, etc
[13:21] <seb128> not to mention you have to care about extra architectures and extra bugs if you become maintainer on the debian side
[13:21] <ari-tczew> seb128: good point, VM ;-)
[13:22] <seb128> which you need to keep updated, which means blocking your downloads for ours every day if you are on a slow internet
[13:22] <seb128> ours->hours
[13:23] <seb128> not to mention that to get there you need to get upload rights to Debian, which is non trivial to get
[13:27] <ari-tczew> seb128_: does Robert test packages merged with Debian before uploading?
[13:28] <seb128_> dunno, you would have to ask him but likely yes
[13:28] <seb128_> why?
[13:28] <ari-tczew> seb128_: if so, he spends a time anyway on testing, whatever whether it's on Debian or natty.
[13:29] <seb128_> well testing on 2 distros mean you need to start them both, use them both for a while, see if it's buggy
[13:29] <seb128_> so basically it means having 2 computers and switching between those
[13:29] <seb128_> it's not because something builds or work on debian than it does on ubuntu
[13:30] <seb128_> sometimes the gcc behaviour is different or the xorg stack is not in the same versions
 hey pitti good morning, sounds good. How will this affect the ongoing testing of maverick langpacks? Do you want to call it off, release new full langpacks and re-new the call for testing?
[13:31] <pitti> ari-tczew: is apt.VersionCompare obsolete somehow? "from apt import VersionCompare" works in python-apt, but not any more in python3-apt
[13:31] <pitti> dpm: yes, as the current maverick ones are mostly broken anyway due to bug 732768
[13:31] <ubot2> Launchpad bug 732768 in langpack-o-matic "ask.com is the only search provider" [High,Fix released] https://launchpad.net/bugs/732768
[13:32] <ari-tczew> pitti: I don't have an idea. why you're asking me?
[13:32] <pitti> ari-tczew: sorry; brain fart
[13:32] <pitti> mvo: is apt.VersionCompare obsolete somehow? "from apt import VersionCompare" works in python-apt, but not any more in python3-apt
[13:32] <ari-tczew> kk
[13:35] <dpm> pitti, ok, I'll call it off then. There's another potential regression in the current maverick-proposed langpacks (bug 544203)  - which is the best way to track it? Just leave it assigned to langpack-pt-br?
[13:35] <ubot2> Launchpad bug 544203 in language-pack-pt-base "pt_BR and pt_PT firefox translations not included in Maverick" [Undecided,New] https://launchpad.net/bugs/544203
[13:36] <mvo> pitti: its the new push for "lower_case". i.e. version_compare() will work
[13:37] <pitti> mvo: ah, danke!
[13:37] <mvo> yw
[13:40] <pitti> mvo: hmm: AttributeError: 'module' object has no attribute 'version_compare'
[13:40] <pitti> mvo: (neither in the py2 version)
[13:46] <mvo> pitti: python -c 'import apt_pkg; apt_pkg.version_compare' works for me, hold on a sec for py3
[13:46] <mvo> pitti: aha, in apt
[13:46]  * mvo looks
[13:56] <pitti> mvo: oh, apt.apt_pkg.version_compare() apparenlty?
[13:56] <mvo> yeah
[13:56] <mvo> a bit silly IMO, worth talking to juliank about it
[14:00] <pitti> mvo: at least that works fine; now on to the replacement of apt_pkg.ParseTagFile().. :)
[14:01] <pitti> (got that, too)
[14:24] <rickspencer3> tseliot, hey, can you please check out bug #733989
[14:24] <ubot2> Launchpad bug 733989 in xserver-xorg-video-intel "dragging with Dell Mini 10v track pad is unforgiving" [Undecided,New] https://launchpad.net/bugs/733989
[14:24] <rickspencer3> note that it's a possible input issue, not a video issue
[14:25] <rickspencer3> but it seems that something changed on my Dell Mini 10v
[14:25] <rickspencer3> pedro_, can someone take a look at bug #734600 ?
[14:25] <ubot2> Launchpad bug 734600 in gst-plugins-bad0.10 "camerabin throws an error in gst_camerabin_capture_start gstcamerabin.c(4036)" [Undecided,New] https://launchpad.net/bugs/734600
[14:26]  * tseliot has a look
[14:30] <mterry> Heyo!  I've got a FF exception for ya'll.  So, I want to split time-admin into a separate package from gnome-system-tools (so that we can avoid having indicator-datetime-preferences and time-admin both installed by default).  This will require a trivial binary package NEW approval and some seed changes for flavors that don't use indicator-datetime by default.  This seems like maybe a FFe is in order?
[14:30] <tseliot> rickspencer3: I see this line in your X log. Maybe the code that handles the option was changed:
[14:30] <tseliot> Option "AreaBottomEdge" requires a percent value
[14:30] <mterry> s/for ya'll/question for ya'll/
[14:31] <chrisccoulson> mterry, what else are we using from gnome-system-tools? we're pretty much at the point where we can drop it from the CD, right?
[14:31] <chrisccoulson> oh
[14:31] <chrisccoulson> users-admin too
[14:31] <seb128> right, users-admin
[14:31] <seb128> someone was supposed to package the new user-account thing previous cycle? ;-)
[14:31] <seb128> mterry, hey, check with pitti but seems a trivial ffe to get
[14:31] <chrisccoulson> yeah, it's merged in to the new control-center now though :P
[14:32] <seb128> mterry, you probably need a bug for the tracking
[14:32] <mterry> seb128, k
[14:32] <pitti> mterry: sounds fine, go ahead
[14:33] <pitti> mterry: will indicator-datetime-preferences do all the bits that time-admin provides?
[14:33] <mterry> pitti, yeah, both ntp and manual date changes
[14:33] <mterry> pitti, and timezone
[14:33] <pitti> nice
[14:33] <mterry> (and not "will", but "does"  :))
[14:34] <pitti> mterry: replacing t-a with i-d-p will require an FFE, though
[14:35] <seb128> pitti, it's not replacing, we have both now
[14:35] <pitti> ah, we do? ncie
[14:35] <pitti> can't tell, indicator-time still crashing :/
[14:35] <mterry> pitti, https://bugs.launchpad.net/ubuntu/+source/gnome-system-tools/+bug/732757
[14:35] <ubot2> Launchpad bug 732757 in gnome-system-tools "FFe: time-admin and indicator-datetime-preferences shouldn't both be installed by default" [Undecided,New]
[14:35] <tseliot> rickspencer3: so, yes, upstream changed the value that the option (which I originally implemented) accepts. It should be just a matter of updating a configuration file. I'll write further details in the bug report and fix the issue. Thanks for reporting the problem
[14:36] <mterry> pitti, indicator-datetime-preferences crashes or indicator-datetime does?  you can run the prefs dialog manually
[14:36] <rickspencer3> thanks tseliot!
[14:36] <pitti> mterry: the indicator-service does; right, it does start manually
[14:38] <pitti> mterry: Set the time "AUtomatically from the Internet" is grayed out for me, though
[14:38] <mterry> pitti, even if you authenticate?
[14:38] <pitti> yes
[14:39] <mterry> pitti, that's set insensitive if we asked system-tools daemon if you can use ntp or not.  It apparently said no?
[14:40] <pitti> mterry: ah, I don't have ntp server installed indeed
[14:40] <mterry> hah, feature!
[14:41] <pitti> same confusion with 'ntpdate' as before, I guess
[14:41] <pitti> perhaps it shouldn't be displayed at all then
[14:44] <mterry> pitti, current behavior is part of the spec, so that's mpt's call
[14:44] <seb128> tedg, mterry, chrisccoulson: the recent appmenu-gtk update broke the desktop menu, not sure if any of you want to work on that
[14:44] <mterry> seb128, desktop menu?
[14:44] <seb128> like it doesn't display the nautilus menu when being on an empty workspace
[14:45] <tedg> seb128, Hmm, it does for me...
[14:45] <chrisccoulson> i'm still trying to get to the bottom of the unity-panel-service memory leaks ;)
[14:45] <chrisccoulson> (of which, i've managed to fix some)
[14:45] <seb128> doesn't here and we got a bug report where the user said that downgrading appmenu-gtk fixes it
[14:45] <tedg> seb128, Which bug number?
[14:46] <seb128> tedg, 733050
[14:46] <tedg> bug 733050
[14:46] <ubot2> Launchpad bug 733050 in appmenu-gtk "appmenu-gtk 0.1.96-0ubuntu1 prevents desktop global menu from appearing" [Undecided,New] https://launchpad.net/bugs/733050
[14:47] <mpt> mterry, I didn't realize (though I should have guessed) it was possible to not have the ability to use NTP
[14:48] <mterry> mpt, huh yeah.  I thought I had done that whole 'insensitive if can't use ntp' bit off a line in the spec, but looking now, I can't see it.  I went rogue (<- pitti, I take it back, it is my fault.  :))
[14:48] <mpt> mterry, what do you think of prompting to install the NTP software if you click "Automatically from the internet" without it installed?
[14:49] <mterry> mpt, that's fine.  I can work on that and file an FFe
[14:50] <pitti> I think that's what time-admin does, isn't it?
[14:50] <pitti> yes, just confirmed
[14:50] <pitti> mterry, mtp ^
[14:50] <mterry> shoot, so we're not feature compatible
[14:51] <pitti> TBH I don't really like this
[14:51] <pitti> we already have ntpdate, so time should be good enough for desktops
[14:51] <pitti> I really don't see a strong case for installing ntpd locally
[14:51] <pitti> if I were the ruler of the world, I'd kill this radio button completely :)
[14:52] <mpt> pitti, and do what instead?
[14:52] <pitti> but I guess that was discussed over and over already
[14:52] <pitti> mpt: nothing; just offer to correct the time manually
[14:52] <mpt> pitti, it hasn't as far as I know, I was just pulling it out of my imagination
[14:52] <pitti> it already gets set whenever you (re)connect to the internet
[14:52] <pitti> set by ntpdate, I mean
[14:53] <kenvandine> pitti, it does?
[14:54] <pitti> kenvandine: /etc/network/if-up.d/ntpdate
[14:54] <mpt> pitti, so are you saying that if Ubuntu can connect to an NTP server, you sholdn't be able to override it manually at all?
[14:54] <mpt> shouldn't
[14:54] <pitti> mpt: there are two ways to get NTP
[14:54] <kenvandine> pitti, and that happens by default right?
[14:54] <pitti> mpt: (1) ntpdate; that's what we install by default, there is no GUI for configuration, and it's done when you connect to the net
[14:54] <kenvandine> if so... then i think ntpd shouldn't get installed
[14:55] <pitti> mpt: (2) a local ntpd server, which has a different configuration file, which you can set up by time-admin (and apparently the indicator prefs now)
[14:55] <pitti> (2) is useful if you don't reboot your computer very often (like servers), and never change/reconnect to your network
[14:56] <mpt> pitti, I didn't know that #2 existed, so I wasn't designing with it in mind :-)
[14:56] <pitti> mpt: right; it's utterly confusing
[14:57] <mpt> pitti, what's confusing about it?
[14:57] <pitti> it leads people into thinking that there's no internet sync by default, and that they better install that
[14:57] <pitti> mpt: that there are two independent NTP ways, and that the GUI doesn't point this out
[14:57] <mpt> But "Automatically from the Internet" is selected by default, right?
[14:57] <mpt> So it is synced by default
[14:57] <pitti> i. e. that GUI thing will switch from "sync time when you connect to the network" to "permanently sync time with the network"
[14:57] <kenvandine> i would say just drop it from the gui then... let it just happen
[14:58] <pitti> mpt: no, we don't install ntpd by default (for good reasons), so it's grayed out by default
[14:58] <mpt> pitti, but the interface isn't for ntpd. Again, I didn't even know that ntpd existed.
[14:58] <pitti> mpt: time-admin offers you to install ntpd when you select the option, in time-admin-prefs it's insensitive
[14:58] <seb128> mterry, ^
[14:58] <mpt> gnargh
[14:58] <kenvandine> mpt,  i think it is for time-admin
[14:58] <seb128> mterry, maybe wait before adding the option ;-)
[14:58] <pitti> mpt: time-admin's interface is for ntpd; if time-admin-prefs replicates that, then it will be, too (and I think it does according to what mterry said)
[14:59] <mpt> ok, so, next question
[14:59] <pitti> mpt: if even you and I get confused by it, I wonder what users will think..
[14:59] <pitti> mpt: don't get me wrong, time-admin isn't any better here
[14:59] <mterry> seb128, yeah, I'm watching.  I remember now dealing with this in oem a bit actually.
[14:59] <pitti> but maybe that's the right time to remove this confusion
[14:59] <mpt> *Why* does time-admin have an interface for ntpd?
[14:59] <pitti> mpt: good question
[14:59] <kenvandine> mpt, designed by geeks..
[14:59] <kenvandine> :)
[15:00] <pitti> it's a rather advanced thing
[15:00] <mpt> It doesn't look like it
[15:00] <tedg> seb128, So are you getting the no-desktop menus error?
[15:00] <mpt> pitti, the choices in time-admin are "Manual" and "Keep synchronized with Internet servers". I see no mention of "Keep synchronized with a local network server".
[15:00] <mpt> or anything like that
[15:01] <glatzor> hello mpt, pitti, seb128 and mvo
[15:01] <seb128> hey glatzor
[15:01] <pitti> hey glatzor
[15:01] <seb128> tedg, on unity yes, I didn't try in GNOME
[15:01] <glatzor> mvo: have you already found the time to look at python-apt multiarch?
[15:01] <seb128> tedg, well it's not so much an error that you don't get the nautilus menu on empty desktops
[15:01] <pitti> mpt: if you install ntpd locally, the local server will regularly sync with internet ones, and then your local computer clock to the local ntpd
[15:01] <tedg> seb128, Can you see if killing nautilus fixes it?  I'm curious if it's just restarting nautilus with the newer version that fixes it :)
[15:02] <seb128> tedg, it does
[15:02] <mvo> phey glatzor
[15:02] <pitti> brb, plumber just arrived
[15:02] <mvo> glatzor: no, sorry :(
[15:03] <mpt> pitti, so the behavior of "Keep synchronized with Internet servers" is different depending on whether ntpd is installed?
[15:03] <tedg> seb128, Okay. I bet it's a race, probably not version dependent.
[15:04] <mterry> mpt, no, I think what pitti's saying is that we don't actually have a real "manual time" option.  That the two choices right now are secretly "keep synchronized all the time" and "synchronize when you connect to the internet"
[15:05] <mpt> mterry, then what are the time and date controls for?
[15:05] <mpt> For making temporary changes that get washed away next time you connect to the Internet?
[15:05] <pitti> mpt: yes
[15:05] <mterry> mpt, good question.  Yup, sounds like.  I remember dealing with a bug about that in oem now
[15:05] <mpt> Eh.
[15:05] <pitti> if you have an offline computer, or wnat to change it on the plane, etc.
[15:05] <mpt> That's daft.
[15:06] <pitti> mpt: note you can disable ntpdate in /etc/default/ntpdate
[15:06] <pitti> but we don't have a GUI for it
[15:06] <mterry> pitti, but there's no policykit-friendly way to change ntpdate's config, eh?
[15:06] <pitti> so perhaps we should devote the time-admin-pref to configuring ntpdate instaead of ntpd?
[15:06] <pitti> mterry: no, you'd need a backend which changes /etc/default/ntpdate
[15:07] <mterry> pitti, yeah, we could switch system-tools-backend to configure that setting
[15:07] <pitti> mterry: ah, it's actually using s-t-b?
[15:07] <mterry> pitti, yeah
[15:07] <pitti> I had hoped it has its own thing, as I'd like to drop s-t-b at some point
[15:07] <pitti> (and g-s-t)
[15:07] <seb128> mterry, didn't we say to uyse g-s-d?
[15:07] <mterry> pitti, actually, let me confirm.  i just wrote this, but even I'm confused
[15:08] <mterry> seb128, yeah, i think i was wrong about s-t-b
[15:08] <seb128> mterry, you backport g-s-d3 code for that iirc
[15:08] <pitti> mpt: are you concerned about "temporary changes that get washed away next time you connect to the Internet?"?
[15:08] <mterry> seb128, pitti: yep, uses new g-s-d code
[15:08] <pitti> mpt: i. e. would you deliberately want to set a wrong clock?
[15:09] <mterry> so same point though, we could modify g-s-d to configure ntpdate instead
[15:09] <mpt> pitti, yes, I know some people who deliberately set their clock ten minutes early to make them more likely to get to things on time (for example)
[15:09] <mterry> hah
[15:09] <pitti> mpt: off-topic, but curious: does that actually work? I mean, your brain would know that the time is off..
[15:10] <mpt> pitti, yeah, as long as you don't think about it too hard
[15:10] <seb128> doesn't work for me, I know how much my clock is off and adapt to that ;-)
[15:12] <tedg> pitti, Doesn't matter if it works, many people swear by it.  :-)
[15:13]  * tedg just sets his clock to yesterday so that I can always say "I sent you that e-mail yesterday!"
[15:13] <mpt> You could still get the previous behavior of "I'll tell you what the time is now, but update it when I next go online" by setting the time manually then clicking the "Automatically..." radio button
[15:13] <pitti> mpt: so ideally we would re-devote this radio button between "manual" (completely) and "automatic" which would be the default and mean ntpdate
[15:13] <mpt> yes
[15:13] <pitti> mterry: as a poor man's PK backend, you could call pkexec sed -i ... :)
[15:14] <mterry> pitti, makes sense to do it the Real way, that way time-admin gets benefit too
[15:15] <mterry> pitti, is this an Ubuntu thing, using ntpdate?
[15:15] <mterry> pitti, I'm curious if I should bother talking to upstream about such a change
[15:15] <pitti> mterry: Debian as well at least; not sure about Fedora
[15:15] <pitti> mterry: certainly worth investigating
[15:16] <mterry> pitti, OK.  Sounds like I should file a FFe for this too, eh?
[15:16] <pitti> mterry: for changing what g-s-d backend configures? I guess might be better, yes
[15:17] <pitti> I'm happy to ack it, but at least there's a paper trail
[15:17] <pitti> we'll need a bug report for the thing anyway (for documentation, upstream link, etc.)
[15:19] <mpt> sooooo, the ntpd case
[15:21] <mpt> mterry, pitti: If you do have ntpd installed, is there any GUI-worthy situation in which you'd want to use an Internet NTP server *instead of* the local NTP server?
[15:22] <pitti> mpt: I don't think so; you want to configure the input sources for the local ntpd of course (that's what time-admin does), but aside from testing scenarios it's much quicker to use the local ntpd then
[15:23] <mpt> mterry, pitti: ok, how about this:
[15:24] <mpt> Whenever “Set the time:” is set to “Automatically from the Internet”, the “Time:” and “Date:” controls should be insensitive, and the time and date should be updated from the local NTP server (if there is one) or otherwise Internet NTP servers whenever you go online.
[15:24] <mterry> pitti, if ntpd is installed, does ntpdate use it?
[15:24] <pitti> mpt: that sounds like a great way to fit all three methods
[15:24] <mterry> pitti, i.e. does ntpdate become a no-op?
[15:24] <pitti> mterry: RTFS, hang on
[15:25] <mterry> mpt, and "manual time" should actually do what it says on the tin, right?  and not reset when you connect to the Internet?
[15:25] <pitti> mterry: apparently not, when I interpret /usr/sbin/ntpdate-debian correctly
[15:25] <pitti> ntpdate will always run if it is installed
[15:26] <mpt> mterry, right
[15:26] <mterry> pitti, so you'd connect, ntpdate would use Internet servers, then in a sec ntpd would set local time from local server?  so you'd potentially have a time hiccup?
[15:26] <pitti> mterry: yes, but usually at the ntpdate time
[15:26] <mterry> pitti, yeah.  that's a separate, tiny bug
[15:27] <pitti> mterry: diff between ntpdate and local ntpd should be by and large 0, if you configured your ntpd
[15:27] <mterry> mpt, ok, I understand what we want, am working on paperwork and code
[15:29] <mpt> mterry, https://wiki.ubuntu.com/TimeAndDate?action=diff&rev2=24&rev1=22
[15:29] <mterry> pitti, /etc/default/ntpdate does not seem to have a conditional to control whether it runs?
[15:30] <pitti> mterry: you can disable $NTPSERVERS
[15:30] <pitti> like, comment it out
[15:30] <mterry> pitti, hrm...  ok
[15:33] <seb128> mterry, btw not sure if you checked the open bugs but while you are at it there is a bug about the dialog not having a proper name and icon if you want to fix those ;-)
[15:33] <seb128> mterry, easy to notice in the unity launcher
[15:34] <mterry> seb128, it was missing a .desktop file, already fixed in trunk  ;)
[15:34] <seb128> mterry, great ;-)
[15:34] <mpt> mterry and pitti, thanks for helping me understand all that.
[15:35] <mterry> pitti, https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/734894
[15:35] <ubot2> Launchpad bug 734894 in gnome-settings-daemon "FFe: DBus time API should control ntpdate, not ntpd" [Undecided,New]
[15:44] <pitti> mterry: (will look in a bit, me@phone)
[15:55] <pitti> seb128, didrocks, mterry: do you have anything for gnome-control-center? otherwise I'll do an upload now
[15:55] <didrocks> pitti: nothing particular for me
[15:55] <seb128> pitti, no
[15:55] <mterry> pitti, no
[15:56] <pitti> good, thanks
[16:00] <GunnarHj> pitti: Hello Martin, could you pls take a look at bug 636693? Currently the design of indicator-session and gdm-guest-session are contradictory in that the indicator menu item "Guest Session" precludes interactivity such as a zenity dialog in /etc/guest-session/prepare.sh. I for one fail to understand why Ted persists. Maybe you and he could talk about it author to author at some time or other?
[16:00] <ubot2> Launchpad bug 636693 in indicator-session "Premature lock when launching guest session" [Low,Confirmed] https://launchpad.net/bugs/636693
[16:08] <mterry> Is there a robust way to programmatically comment/uncomment lines in bash scripts?  I'd like to be able to run something like "comment VARIABLE /path/to/script".  I can do it with sed, but doesn't seem as fool-proof
[16:10] <mterry> pitti, what are issues with installing ntpd by default?
[16:13] <pitti> mterry: nonzero overhead (extra CPU power, battery drainage, network traffic, CD space) for very little benefit
[16:14] <mterry> k
[16:14] <pitti> mterry: and formally it violates the "no open ports in default install" policy
[16:16] <pitti> mterry: commented and asked skaet to review
[16:20] <pitti> hey GunnarHj
[16:20] <pitti> GunnarHj: ok, tab opened for it; I'll have a look soon
[16:22] <GunnarHj> pitti: Good, then I 'rest my case' for now. :)
[16:24] <seb128> GunnarHj, still arguing with ted over this one?
[16:24] <seb128> GunnarHj, I've to admit I fail to see what you really want to get there
[16:26] <mterry> pitti, hrmm.  NTPSERVERS is ignored if /etc/ntp.conf exists and NTPDATE_USE_NTP_CONF=yes (which it does by default).  I may want to add an NTPDATE_ENABLED var
[16:27] <pitti> mterry: that's correct
[16:28] <GunnarHj> seb128: Yes, unfortunately  I am. The use case that made me suggest it was a zenity dialog where you select the guest session language on-the-fly when launching the session.
[16:28] <pitti> mterry: but /etc/ntp.conf doesn't exist by default, only if you install ntpd
[16:28] <mterry> pitti, yeah, but if you do have both installed, i still want to be able to disable ntp.conf
[16:28] <mterry> I mean, ntpdate
[16:29] <pitti> mterry: I think we should do that differently -- if ntpdate-debian sees that ntpd is installed and enabled, it probably shouldn't run at all
[16:29] <pitti> mterry: that would also avoid the "time jump" at connection time
[16:29] <pitti> (ntpd can gradually move the system clock to the right time)
[16:30] <mterry> pitti, OK
[16:32] <mterry> pitti, and you'd still prefer to (un)comment NTPSERVERS?  Seems so indirect
[16:33] <mterry> Doesn't really matter.  Not adding an NTPDATE_ENABLED is easier than adding it
[16:33] <pitti> mterry: I have no strong opinion there, except that if we add a new var I'd like to see it getting added to Debian as well
[16:33] <pitti> other packages might read the file, too
[16:42] <mterry> pitti, since NTPDATE_USE_NTP_CONF=yes is a thing, we probably don't have a "time jump" issue?  the existing ntpdate.ifup seems to explicitly stop ntpd and start it after, which implies there's a usecase.   What would be the usecase for running ntpdate if ntpd is on?
[16:43] <GunnarHj> seb128: Btw, there are more details about the background at http://ubuntuforums.org/showthread.php?t=1566078
[16:43] <pitti> mterry: the only thing that this does is to take the $NTPSERVERS configuration from /etc/ntp.conf instead of from /etc/default/ntpdate
[16:43] <pitti> mterry: but ntpdate still gets called, so you would have a time jump
[16:44] <mterry> pitti, because ntpd gradually adjusts rather than all at once?
[16:44] <pitti> mterry: hm, indeed; I think it's even more wrong to stop/restart ntpd, ntpdate should shut up if it's running
[16:44] <pitti> mterry: yes
[16:44] <pitti> mterry: and for the latter, because ntpd updates regularly instead of just at if-up.d time
[16:44] <mterry> pitti, ok, will make the patch and throw to debian too
[16:45] <pitti> cool, thanks!
[16:52] <seb128> pitti, there is a new gobject-introspection which can be synced from Debian, should we get it?
[16:52]  * pitti checks upstream changelog
[16:53] <pitti> seb128: yes, only one bug fix, can be synced
[16:53] <seb128> pitti, ok, will do
[16:53] <pitti> merci
[16:53] <seb128> de rien
[16:55] <bcurtiswx> Good day all.
[16:56] <seb128> hey bcurtiswx
[16:56] <bcurtiswx> Hey seb128
[16:57] <bcurtiswx> kenvandine: Do you use an colloquy bouncer?
[16:57] <kenvandine> bcurtiswx, never heard of it
[16:57] <kenvandine> isn't colloquy a mac thing?
[16:57] <bcurtiswx> kenvandine: Yes I'm using my iPad.
[16:58] <kenvandine> nope, not using it
[16:58] <bcurtiswx> Do you have an irc bouncer tho?
[16:58] <kenvandine> i haven't owned an apple product in many years
[16:58] <kenvandine> znc
[16:58] <bcurtiswx> Ok may I pm you?
[16:58] <kenvandine> sure
[17:14] <evilvish> pitti: hi, i would like to drop the scour dependency for humanity.. :)
[17:23] <tkamppeter> jasoncwarner,
[17:23] <tkamppeter> jasoncwarner, hi
[17:49] <seb128> tedg, kenvandine, mterry: bug #734616 might be worth investigating
[17:49] <ubot2> Launchpad bug 734616 in lernid "lernid hangs closing the "about" window or the preferences dialog window" [Undecided,New] https://launchpad.net/bugs/734616
[17:50] <tedg> Is Lernid python?
[17:51] <seb128> tedg, yes
[17:51] <tedg> Hmm, I wonder if that's the same bug as that music player one.
[17:52] <seb128> tedg, it's the application jono wrote for UDW sessions
[17:52] <tedg> Ah, so you're saying people might use it here in a bit? :)
[17:53] <seb128> ;-)
[17:53] <seb128> tedg, feel free to dup it if it's the same issue
[17:53] <tedg> I think it might be a dup of bug 717162  -- but I have no idea how to debug them.
[17:53] <ubot2> Launchpad bug 717162 in unity-2d "quodlibet UI freeze in Unity after accessing its menu" [High,Confirmed] https://launchpad.net/bugs/717162
[17:54] <tedg> I e-mailed barry, as I'm sure he's at PyCon to see if he can help.
[17:54] <tedg> It seems to be where the Python meets the C.  Which is a very scary place.
[17:54] <kenvandine> tedg, that does seem similar
[17:54] <seb128> hehe
[17:54] <kenvandine> tedg, all the other menus in quodlibet are working
[17:54] <evilvish> seb128: lernid team is not actively developing it, it has a lot of problems on its own.. so it not sure it is worth spending time on it ;)
[17:55] <tedg> kenvandine, I think it must be something with launching the dialog.
[17:56] <kenvandine> something with the response?
[17:56] <kenvandine> in quodlibet it happens with the file chooser
[17:56] <seb128> evilvish, oh, it's not about trying to stabilize lernid but rather catching indicator-appmenu issues because they can impact on other applications
[17:56] <evilvish> ah, OK :)
[17:56] <tedg> kenvandine, Yeah, there may be stacked mainloops there.
[17:56] <seb128> kenvandine, the guy thinks "this is related to the use of dialog.run() in a signal handler from the indicator-appmenu"
[17:57] <kenvandine> seb128, ok, that is basically what happens in quodlibet
[17:57] <seb128> not sure what made him wrote that though
[17:59] <tedg> The odd part there is that we're processing those events in the idle loop.  So they should be safer if nothing else.
[17:59] <tedg> I wonder if Python does something funky to lock the main loop from GUI events normally.
[18:00] <seb128> tedg, could it be an issue if those dialogs were transient from the caller?
[18:00] <mterry> pitti, just an update on ntpdate.ifup to make sure I'm not going off the deep end: because of the complexity of determining if ntpd is a thing (could be removed, not purged, so ntp.conf is still there, so NTPSERVERS is ignored), I'm thinking it'd be easiest to just move ifup.d/ntpdate to ifup.d/ntpdate.disabled.  How does that sound?
[18:01] <tedg> seb128, I imagine they're created, run, and destroyed.  That's how most GTK programs do it.
[18:02] <pitti> mterry: ah, I actually thought about "status ntpd", but renaming away the ifup.d script sounds fine as well
[18:03] <pitti> mterry: ".disabled" works in if-up.d? I. e. anything with a period is ignored?
[18:03] <mterry> pitti, yeah, it uses run-parts
[18:03] <pitti> evilvish: oh, why? (btw, will do another upload of scour with a bunch of bug fixes)
[18:04] <evilvish> pitti: i just subscribed you to a bug report..
[18:04] <evilvish> i've*
[18:05] <evilvish> pitti: in short, it is not stable enough to be used for icon themes. it changes the design when the whole purpose of the icon theme is just that
[18:05] <evilvish> pitti: or what we could do is, reduce the fuzzy check to depend on the package, allow icon themes to set the check limit to something lower so that no icon is visibly modified …
[18:06] <pitti> evilvish: ah, I'll reply in the bug report, there are some confusions there
[18:06] <evilvish> pitti: cool.., but 0.5.35 is not a perfect build either ;)
[18:06] <kenvandine> tedg, quodlibet did use a .run for the dialog, but it does get past that
[18:06] <evilvish> err, 0.5.3.6
[18:06] <kenvandine> it gets the response event and moves on
[18:06] <kenvandine> the code after that is executed
[18:07] <kenvandine> it is like the existing main loop is hung though
[18:08] <tedg> kenvandine, Can you put that on the bug... I think this one is going to take a bunch of people looking at it.
[18:08] <kenvandine> yeah
[18:08] <kenvandine> will do
[18:08] <kenvandine> it really looked like it did the right thing... just stopped doing it
[18:08]  * kenvandine goes to comment
[18:12] <pitti> evilvish: replied
[18:13] <seb128> mterry, you won bug #733688 (crashes in sanitize_label_text (label=0x0) which seems code you changed recently?)
[18:13] <ubot2> Launchpad bug 733688 in libdbusmenu "bluetooth-applet crashed with SIGSEGV in g_cclosure_marshal_VOID__PARAM()" [Medium,New] https://launchpad.net/bugs/733688
[18:13] <mterry> :-/  yeah, seems like me
[18:13] <seb128> mterry, but feel free to bounce to ted if you are busy on other things
[18:13] <mterry> seb128, I'm busy right this second, but I can get to it this week
[18:13] <mterry> or is this a frequent crasher?
[18:13] <seb128> mterry, ok, so I let it on your list
[18:14] <seb128> ted is of 2 days at the end of the week and seems to have quite to do already
[18:14] <seb128> mterry, no, just spotted 1 bug about it
[18:14] <seb128> but it seems an obvious case of non handling of null value
[18:16] <seb128> mterry, no hurry, whenever you have time before beta will do, I will ping you if it starts being a frequent crasher
[18:29] <evilvish> pitti: i've not noticed any problems with editing, only 18 files which had been converted properly.. i dint realize its a new option we in inkscape
[18:29] <evilvish> had not* been
[18:31] <pitti> evilvish: but that's what upstream specifically warns not to do..
[18:31] <evilvish> pitti: yea, but that is not our working branch.. just a release branch.. btw, I'm OK with a 0.0% check:)
[18:32] <pitti> evilvish: ok, I'm about to do a scour upload anyway (probably need to finish tomorrow morning, need to run out for taekwondo)
[18:32] <pitti> evilvish: I'll just lower the default threshold then
[18:33] <pitti> good night everyone!
[18:33] <evilvish> pitti: neat! and then we have have a re-build for the branch.. :)
[18:33] <pitti> evilvish: yep, will do
[18:33] <evilvish> nite pitti :)
[18:33] <pitti> evilvish: I still recommend to revert the committed scour'ed packages
[18:33] <pitti> the source package should have the acutal source files IMHO
[18:34] <pitti> s/packages/images/
[18:34] <pitti> and it would also be a nuisance to keep this up to date manually
[18:35] <evilvish> pitti: yea.. but reverting is not needed IMO, there really is no problem with the images though ;)
[18:35] <evilvish> pitti: just that I dont need to do it manually later ;)
[18:35] <pitti> you checked them all in inkscape and made sure they didn't lose any annotation, etc.? because that's what scour does..
[18:35] <evilvish> pitti: yup.. i checked *several* files..
[18:36] <evilvish> i did it to compare if the colors and lines and stuff matched
[19:44] <mterry_> pitti, hello.  So now that I fixed gnome-settings-daemon to configure ntpdate as well, bug 732757 could use an official pat on the back
[19:44] <ubot2> Launchpad bug 732757 in gnome-system-tools "FFe: time-admin and indicator-datetime-preferences shouldn't both be installed by default" [Undecided,New] https://launchpad.net/bugs/732757
[21:53] <rickspencer3> kenvandine, hey, you mentioned somehting once about getting "streams" from gwibber, like I could get the stream of images
[21:54] <rickspencer3> do you remember what I'm talking about, and is there any documentation or samples for that?
[22:07] <rickspencer3> robert_ancell, RAOF either of you guyses clueful about Gstreamer, specifically,  camerabin?
[22:08] <robert_ancell> rickspencer3, haven't played with camerabin yet
[22:08] <rickspencer3> it stopped working for me this weekend, and I don't know who should look at it :?
[22:09] <movi> can someone using networkmanager and wifi please stand up? i need someone to generate a file for me
[22:10] <rickspencer3> robert_ancell, it's bug #734600, if you know someone who can look at it
[22:10] <ubot2> Launchpad bug 734600 in gst-plugins-bad0.10 "camerabin throws an error in gst_camerabin_capture_start gstcamerabin.c(4036)" [Undecided,New] https://launchpad.net/bugs/734600
[22:10] <rickspencer3> movi, what do you need?
[22:11] <movi> rickspencer3, i need a keyfile. i'm building a GUI-less server, and want networkmanager to handle the wifi. but the only "right" way to create that file is to let nm-applet create it. the documentation sucks
[22:12] <movi> rickspencer3, basically go to the nm-applet connection editor, create a connection to a wifi network which is protected by a WPA/WPA2 security scheme, and select "avaible to all users". then hopefully it will show up as a file in /etc/NetwormManager/system-connections
[22:12] <rickspencer3> movi, I don't have any protected AP to connect to, sorry
[22:12] <movi> rickspencer3, that doesn't really matter. you don't need to connect to it at all :)
[22:13] <movi> just create it in the connectino manager.
[22:17] <rickspencer3> movi, do you want me to pick WPA/WPA2 personal or enterprise?
[22:19] <movi> personal
[22:19] <movi> can you even tick the "avaible for all users?
[22:19] <rickspencer3> yeah
[22:19]  * rickspencer3 peruses resulting file for pii
[22:20] <movi> ?
[22:20] <rickspencer3> Personally Identifying Information
[22:20] <movi> ah
[22:20] <rickspencer3> in other words, making sure I'm not being socially engineered ;)
[22:20] <movi> it'll have a mac adress probably
[22:20] <movi> nope, you're not. but stay vigilant, that's a good habit :)
[22:21] <rickspencer3> lol
[22:21] <RAOF> rickspencer3: Heh.  That's a most unhelpful error message for the camerabin :)
[22:21] <rickspencer3> but of course if I was being socially engineered, that's exactly what I would expect you to say movi :)
[22:21] <rickspencer3> movi, http://paste.ubuntu.com/580332/ , I have no idea why they couldn't just document that, seems enough to make
[22:22] <rickspencer3> RAOF, uh, yah
[22:22] <movi> ah, thank you
[22:22] <rickspencer3> RAOF, I noticed cheese works
[22:22] <movi> hopefully this will work
[22:22] <rickspencer3> good luck movi
[22:22] <movi> oh, just one more question
[22:22] <movi> network-manager-0.8.x ?
[22:23] <rickspencer3> ah geez
[22:23] <rickspencer3> latest and greatest in natty, I just dist-upgraded
[22:23] <rickspencer3> RAOF, any ideas about camerabin, there?
[22:23] <movi> will i get kbanned if i mention i'm doing this for gentoo :> ?
[22:24] <movi> and hence the reason why i'm asking
[22:24] <Amaranth> Wow when you setup a NM system-wide connection it stores your wifi password in plaintext?
[22:24] <Amaranth> Screw that, stick with per-user where it gets stored in your keyring
[22:24] <rickspencer3> sweet, huh
[22:24] <movi> rickspencer3, quick question, was ssid= field really plaintext? or was it ascii encoded like 124;112; ..
[22:24] <rickspencer3> I dunno man
[22:25] <movi> how did you name the AP ?
[22:25] <movi> TEST_AP ?
[22:25] <rickspencer3> yeah
[22:25] <movi> ok, thanks
[22:25] <rickspencer3> it just looks like a simple text file to me
[22:25] <movi> Amaranth, doesn't work like that, no-one logs into the machine locally
[22:25] <movi> also, it's not plaintext, it has to be hashed
[22:26] <movi> http://projects.gnome.org/NetworkManager/developers/settings-spec-08.html
[22:26] <Amaranth> movi: err, it's 12345678 in his pastebin
[22:26] <movi> this is the documentation for the keyfile. welcoming no?
[22:26] <Amaranth> very clearly plaintext
[22:26] <rickspencer3> looks like POT to me
[22:26] <movi> Amaranth, i've figured that's what he changed not to be incriminated?
[22:26] <movi> POT ?
[22:27] <rickspencer3> Plain Old Text
[22:27] <rickspencer3> movi, no, the password I sepcified was 12345678
[22:27] <Amaranth> Surely he just put in a dummy psk when creating the connection, no need to change that
[22:27] <rickspencer3> nah, that's my normal password
[22:27] <rickspencer3> I use it for everything
[22:27] <movi> :>
[22:27] <rickspencer3> actually, I shouldn't have said that, even jest, now everyone knows one password I don't use, one step closer to hacking me
[22:28] <rickspencer3> movi, seriously, what I pastebinned is what NM made for me
[22:28] <Amaranth> movi: networkmanager itself hashes it for auth with the AP but it is stored plaintext
[22:28] <Amaranth> Otherwise you couldn't edit the connection afterward and have it show you the password
[22:32] <movi> mm
[22:32] <movi> it still doesn't work
[22:35] <movi> nope, it works
[22:35] <movi> just needed to chmod 600 the keyflie
[22:35] <movi> thanks rickspencer3
[22:35] <rickspencer3> sweet
[22:35] <movi> and yeah, it may be insecure, but it's the closes way to having an "intelligent" connectino manager
[22:35] <rickspencer3> well, it's not really "insecure"
[22:36] <movi> one which won't fall over when the AP is unavaible for a couple of secconds
[22:36] <rickspencer3> I mean, you need su to see it at all
[22:36] <rickspencer3> and also, it's a password for a public AP, which has presumedly been passed out to all kinds of people
[22:36] <rickspencer3> if someone can read that file, the fact that they can log onto the AP easily is probably the least of yoru concerns ;)
[22:37] <movi> umm, what do you mean by public ap?
[22:38] <movi> i mean it's visible, but i'd like to think it's my own, and nobody exept me hass the PW ;)
[22:42] <movi> anyway, that's done. now to fix the xbmc/hal mess and finally squish that php+ipv6 bug
[22:43] <movi> thanks again guys :)