[00:00] <TheMuso> robert_ancell: Did metacity get sponsored? If not, I'll take care of it this morning.
[00:01] <robert_ancell> TheMuso, didrocks did it, thanks
[00:01] <TheMuso> np
[01:46] <robert_ancell> TheMuso, can you sponsor compiz-fusion-plugins-main from lp:~compiz/compcomm-plugins-main/ubuntu
[01:46] <TheMuso> sure
[01:47] <robert_ancell> do you have any idea why debian/install stopped working (and now requires debian/tmp in there)?
[01:56] <TheMuso> not without looking deeper into the package history
[01:57] <robert_ancell> what is the "correct" way - should all install files have debian/tmp ?
[01:58] <TheMuso> As far as I understand things, if there are multiple packages being created from one source package, all files go into debian/tmp and are copied to their apropriate packages from there.
[01:59] <ajmitch> that sort of thing can depend on debhelper compat level
[01:59] <RAOF> dh_install in compat mode 7 will automatically look in debian/tmp.
[01:59] <ajmitch> ^^ what he said
[02:01] <robert_ancell> ah, thanks.  It must have transitioned to 7
[02:10] <TheMuso> robert_ancell: uploaded
[02:11] <robert_ancell> TheMuso, thansk
[02:11]  * TheMuso must admit he is a little distracted by today's Australian political machinations.
[02:11] <TheMuso> And, disturbed.
[02:11] <TheMuso> macinations even
[03:35] <NCommander> anyone around who can look at a gobjection-inspection patch?
[03:58] <micahg> NCommander: would you happen to know what source the gnome shutdown dialog is in?
[03:58] <NCommander> micahg: gnome-session I think
[03:58] <NCommander> been awhile since I looked
[03:58] <micahg> NCommander: k, thanks
[04:14] <RAOF> Gah!  Damn you launchpad.  Don't oops on bug submission.
[04:14] <RAOF> Thank you Chromium, and your delicious form-saving back button.
[04:29] <lamalex> <3
[04:29] <lamalex> RAOF: do you need any help upstreaming those f-spot patches?
[04:29] <lamalex> or is that pretty much good
[06:28] <RAOF> Plenty of bugs for indicator-network!
[06:34] <lifeless> RAOF: hah
[06:35] <RAOF> But my UltraBase™ has arrived, and displayport is pleasantly painless.
[06:36] <lifeless> ooh
[06:36] <lifeless> hey
[06:36] <RAOF> I'm not entirely sure how people actually _use_ VGA outputs.  Or maybe my cable is made of rusty iron.
[06:36] <lifeless> can you do dual hdmi or whatever it is the cinema displays need, on an x201s with UltraBase ?
[06:36] <lifeless> RAOF: rusty iron.
[06:36] <lifeless> RAOF: I will say that I hate vga + LCD. But my 21" philips professional CRT kicks arse.
[06:37] <RAOF> I haven't had a CRT for over a decade.
[06:37] <RAOF> Actually, that's not quite true.  I picked one up from the side of the road to test VGA output at one point :)
[06:38] <RAOF> lifeless: Displayport can certainly push out the needed bandwith for your choice of insanely sized monitor.  I'm fairly sure the software will also be up to it.
[07:33] <TheMuso> RAOF: Does it also put audio out via displayport?
[07:36] <RAOF> I don't know.  The displayport protocol certainly allows for that, but I don't have anything that accepts DP audio.
[07:36] <RAOF> The DP protocol is actually rather freaky.  You can do USB over DP if you feel like having a USB hub in your monitor.
[08:19] <dholbach> hey guys
[08:20] <dholbach> micahg proposed to get gjs rebuilt (bug 597944) for gnome-shell
[08:20] <ubot2> Launchpad bug 597944 in gjs (Ubuntu) "libgjs needs a rebuild for xulrunner-1.9.2.4 (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/597944
[08:20] <dholbach> I wanted to sponsor it, but for me it seems to FTBFS
[08:20] <dholbach> http://paste.ubuntu.com/454309/
[08:26] <dholbach> hey seb128
[08:26] <dholbach> salut mon ami - comment ça va?
[08:26] <seb128> hello dholbach
[08:26] <seb128> dholbach, ca va bien merci, et toi ?
[08:27] <dholbach> ca va bien aussi :)
[08:27] <seb128> dholbach, qu'est-ce qui t'amène chez nous ? un bug de nouveau ? ;-)
[08:27] <dholbach> micahg proposed to get gjs rebuilt (bug 597944) for gnome-shell
[08:27] <ubot2> Launchpad bug 597944 in gjs (Ubuntu) "libgjs needs a rebuild for xulrunner-1.9.2.4 (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/597944
[08:27] <dholbach> I wanted to sponsor it, but for me it seems to FTBFS
[08:27] <dholbach> http://paste.ubuntu.com/454309/
[08:27] <dholbach> anything I should be doing about it? (seems he went to bed now)
[08:27] <dholbach> I dunno if it was important or urgent or anything
[08:29] <seb128> dholbach, I was just reading my email, got one from him about that
[08:29] <dholbach> ah ok, well, I guess I just update his bug then
[08:29] <seb128> dholbach, no, don't bother I meant to have chrisccoulson to give a try to it today or maybe do the merge from debian
[08:29] <seb128> they have a new version of gjs there
[08:30] <dholbach> ah, gotcha
[08:30] <seb128> dholbach, thanks for asking about it though ;-)
[08:30] <dholbach> yeah, I didn't know if it was important in any way
[08:30] <seb128> it's not
[08:30] <seb128> it's required to have gnome-shell new version to build
[08:31] <dholbach> ah ok
[08:31] <seb128> but it's not something we rely on, it's in universe
[08:31] <seb128> so if it takes a few extra days that's not an issue
[08:31] <dholbach> alrightie
[08:31] <didrocks> good morning
[08:32] <dholbach> seb128: je suis près de toi maintenant :)
[08:32] <didrocks> (seems like I overslept :))
[08:32] <seb128> lut didrocks, nice!
[08:32] <didrocks> salut seb128 :)
[08:32] <seb128> dholbach, oh ? en vacances ?
[08:32] <ogra> seb128, does that look sane to you ? http://launchpadlibrarian.net/50829991/gobject-introspection.debdiff
[08:32] <robert_ancell> does anyone know how to make dpkg triggers work?  I have a working dh_gsettings, but I think I should reimplement as a trigger
[08:33] <ogra> (i know its just a workaround)
[08:33] <dholbach> seb128: non, pas des vacances, mais je suis à Trèves :)
[08:33] <dholbach> seb128: visiter mes parents
[08:33] <ogra> robert_ancell, create debian/<binary package>.triggers
[08:33] <RAOF> robert_ancell: I've had a look at them before, although I'm a bit hazy.
[08:33] <seb128> ogra, I'm not sure why that's required on arm and not other archs
[08:34] <seb128> ogra, could you open an upstream bug about it maybe to get their comments?
[08:34] <seb128> robert_ancell, you can take gconf or gnome-menus as an example
[08:34] <robert_ancell> ogra, and where do I implement the trigger script?
[08:34] <seb128> robert_ancell, you need a .trigger and a trigger case in the postinst
[08:34] <seb128> robert_ancell, the postinst snippet has the code to run
[08:34] <ogra> seb128, will do, there is bug 597947 as downstream one already though
[08:34] <ubot2> Launchpad bug 597947 in gobject-introspection (Ubuntu) "ARM FTBFS fix (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/597947
[08:35] <robert_ancell> seb128, so the code is shared between all packages?
[08:35] <seb128> robert_ancell, editor /var/lib/dpkg/info/shared-mime-info.postinst
[08:36] <seb128> robert_ancell, see the triggered case
[08:36] <seb128> robert_ancell, see /var/lib/dpkg/info/shared-mime-info.triggers to register what trigger the triggers
[08:37] <didrocks> robert_ancell: yesterday, I had a look at metacity patches and saw you added "Description ? Authors?" to most of them. I've added those to 03_strict_focus.patch: if you google for META_FOCUS_MODE_STRICT, you'll find an IRC conversation between seb128 and lamont from Januay 2005 :)
[08:37] <seb128> robert_ancell, so you basically want a .triggers with your directory listed
[08:37] <seb128> robert_ancell, and the posting to run the update command in the triggered case
[08:37] <seb128> posting -> postinst
[08:38] <robert_ancell> oh, so I make these changes in libglib2.0-bin, and then once you have the new version installed any program that touches files in /usr/share/glib2.0/schemas will trigger the script in libglib2.0-bin?
[08:38] <seb128> didrocks, did you see my comment about the "Desk" naming? can you drop those in the next upload
[08:38] <seb128> robert_ancell, right
[08:38] <robert_ancell> much easier than modifying debhelper/cdbs :)
[08:38] <seb128> ;-)
[08:38] <ogra> seb128, would you accept the patch as a temp. workaround at least ?
[08:39] <seb128> robert_ancell, could you have a quick review of http://launchpadlibrarian.net/50829991/gobject-introspection.debdiff
[08:39] <mvo> robert_ancell: hi, I just look over the compiz merge diff. I'm sure that was a lot of work, good job! some nitpicking. i would really prefer to keep the old ubuntu changelogs, that should be trivial with dpkg-mergechangelogs. it also brings back compiz-gtk and remove compiz-dbg. I don't mind dropping compiz-dbg, but I don't think we need compiz-gtk (in addition to compiz-gnome). I have no strong opinion here though
[08:39] <didrocks> seb128: not on #ubuntu-desktop?
[08:39] <seb128> didrocks, no
[08:40] <didrocks> still, didn't finish to backlog everything :)
[08:40] <seb128> didrocks, ok, so "Desk" is a mistake, we dropped those changes from libwnck in lucid
[08:40] <robert_ancell> mvo, I didn't realise at the time that we'd removed compiz-gtk.  Why do you want the old changelogs?  I think they just make it more confusing to work out what has changed
[08:40] <seb128> didrocks, your changelog explains why some people still get naming issues
[08:40] <seb128> didrocks, I didn't notice the wms had changes for that
[08:41] <didrocks> seb128: ok, I will revert in mutter and in metacity so
[08:41] <seb128> didrocks, don't do an upload for that but next time you touch those...
[08:41] <mvo> robert_ancell: I think in the compiz case the old changelogs have a lot of useful information about the patches we added, who did it and when
[08:41] <seb128> didrocks, thanks
[08:41] <seb128> mvo, launchpad has the upload history as well
[08:41] <didrocks> seb128: I have to do an upload with the papercut about Alt + tab and copy/paste
[08:41] <seb128> I will not argue about those
[08:41] <seb128> but I don't like keeping tons of useless changelog entries
[08:41] <mvo> robert_ancell: I can see that its not that useful for a package that is less heavily patched (e.g. plugins-main). but for compiz I think there is some value
[08:41] <seb128> it makes merges harder and takes CD space
[08:42] <mvo> seb128: I disagree that they are useless
[08:42] <mvo> seb128: and dpkg-mergechangelogs should make the merge trivial
[08:42] <seb128> ok, fair enough
[08:42] <seb128> as said I will not argue I know other people have other opinions
[08:42] <robert_ancell> mvo, I moved all the patch info to patch headers
[08:42] <seb128> we never kept those for desktop packages
[08:42] <pitti> Good morning
[08:42] <seb128> hey pitti
[08:42] <didrocks> hey pitti
[08:44] <mvo> robert_ancell: yeah, that is a good thing! it appears that they also all contain the version the patch was added so I'm happy
[08:44] <ogra> grmbl
[08:44] <ogra> silly reconnects
[08:44] <seb128> ogra, I've no strong opinion about this change
[08:44] <mvo> patch-header info makes me happy to, so I'm happy now and don't want changelogs anymore
[08:44] <mvo> thanks :)
[08:44] <seb128> I don't know enough about gobject introspection to comment
[08:44] <seb128> mvo, ;-)
[08:45] <seb128> see, everybody always agrees with robert_ancell in the end
[08:45] <robert_ancell> :)
[08:45] <seb128> I don't know how we does that
[08:45] <seb128> but I need to learn from him ;-)
[08:45] <mvo> heh :)
[08:45] <seb128> we -> he
[08:45] <ogra> robert_ancell, did you comment on the patch already (i had a reconnect)
[08:45] <seb128> robert_ancell, could you give a quick ack, nack, don't know on http://launchpadlibrarian.net/50829991/gobject-introspection.debdiff ?
[08:46] <robert_ancell> ogra, no, but I just read that pygi was merged into python-gobject
[08:46] <mvo> robert_ancell: so about compiz-gtk - I don't mind either way, I doubt its a very useful pacakge, but you are the matinainer ;)
[08:46] <robert_ancell> seb128, don't know
[08:46] <seb128> robert_ancell, thanks
[08:47] <seb128> ogra, ok, feel free to upload but open a bug upstream with the build error and your workaround
[08:47] <ogra> seb128, thanks a lot :)
[08:47] <seb128> np, thank you for working on it
[08:47] <robert_ancell> mvo, my motivation is mostly just to have the same package in Debian and Ubuntu so we can make progress twice as fast
[08:47]  * ogra hugs seb128 ... also because he thinks french world cup viewers always need comforting ;)
[08:48] <robert_ancell> ogra, oh, the patch seb128 just showed me?  I hadn't seen it before then
[08:48] <seb128> ogra, hehe
[08:48] <mvo> robert_ancell: fair enough, it looks good I will sponsor if you want
[08:49] <seb128> robert_ancell, is pygi in pygobject a win, out of that making the pygi packaging work efforts somewhat wasted?
[08:50] <robert_ancell> seb128, well, it meant we had a little bit of a head start in understanding pygi so that's not a bad thing
[08:51] <robert_ancell> mvo, I agree we should remove the -gtk package, and then pester Debian to do the same if it's the right move
[08:53] <seb128> robert_ancell, btw gdm upstream seems very active atm
[08:53] <seb128> robert_ancell, we could maybe try to get some of our changes reviewed
[08:54] <seb128> robert_ancell, I noticed they fixed some of the issues for which we have distro changes, next update will be interesting
[08:54] <robert_ancell> seb128, they just closed the "no gdmsetup" bug
[08:54] <robert_ancell> WONTFIX
[08:54] <seb128> robert_ancell, right, they disagree it's the way to go, they want those options integrated in other configurations dialogs
[08:55] <robert_ancell> dosen't stop you having a dialog in the mean time...
[08:56] <seb128> robert_ancell, right, I stopped trying to argue with them about this though, they don't see the point for fedora and will not consider it
[08:58] <robert_ancell> seb128,  was there any particular feature from newer gdm's that we want, maybe a patch candidate?
[08:58] <seb128> no
[08:59] <seb128> I've been backport quite some fixes to lucid
[08:59] <seb128> they are doing lot of refactoring in git atm apparently on widgets loading, etc to speed things up it seems
[09:03] <seb128> didrocks, btw vala fails to build on debian the same way
[09:03] <seb128> didrocks, you might want to tell slomo about it
[09:03] <didrocks> seb128: yeah, I saw that
[09:03] <didrocks> seb128: -2 as well?
[09:03] <seb128> yes
[09:03] <didrocks> seb128: where do you see that?
[09:03] <seb128> slomo, hi
[09:03] <seb128> slomo, your vala updates don't build in i386
[09:03] <didrocks> (I saw for -1 as with the new upload, but not the build result)
[09:04] <seb128> didrocks, https://buildd.debian.org/fetch.cgi?&pkg=vala&ver=0.9.2-2&arch=i386&stamp=1277365652&file=log
[09:04] <robert_ancell> seb128, hey, do you know how gio-querymodules works? I notice it's only run when new packages are installed (postinst).  Shouldn't it also be run postrm?
[09:04] <didrocks> seb128: thanks
[09:04] <seb128> robert_ancell, it's a trigger, it should run whenever the dir change no?
[09:05] <seb128> robert_ancell, watch the .cache in the /usr/lib/gio dir
[09:05] <robert_ancell> seb128, so the postinst script always gets run when a trigger occurs?
[09:05] <seb128> robert_ancell, it should yes
[09:05] <robert_ancell> ok
[09:05] <didrocks> I've added strace to vala, tried to have a look but nothing relevant to me
[09:07] <seb128> brb restart
[09:13] <robert_ancell> later all
[09:15] <slomo> seb128, didrocks: thanks... any idea what could be wrong? :) looks like a gio problem
[09:16] <seb128> slomo, not really no...
[09:17] <didrocks> I tried to strace the check yesterday, nothing useful (in addition, I can't reproduce it in my pbuilder :/)
[09:24] <slomo> didrocks: same here :) maybe caused by a read-only $HOME?
[09:24] <didrocks> slomo: hum, can be, good idea
[09:28] <slomo> didrocks: g_bus_get_sync() for the session bus is the call that fails
[09:55] <nigelb> that nautilius bug has become too difficult to tolerate :/
[09:56] <seb128> what? which one?
[09:56] <nigelb> the one you just commented - the amount of begging, bitching, and complaining for something we didn't even do :/
[09:57] <seb128> oh, right, just ignore it
[09:57] <seb128> brb
[10:09] <huats> morning
[10:34] <dholbach> hey guys
[10:34] <dholbach> I was wondering if you need more contributors for the Desktop team
[10:39] <mvo> dholbach: isn't that like asking "do you want more money"? i.e. few people would say no ;) ?
[10:39] <lifeless> depends, is it counterfeit ?
[10:40] <dholbach> :)
[10:40] <dholbach> I was just wondering what kind of stuff desktop contributors should be doing
[10:41] <seb128> dholbach, triaging bugs, doing merges on debian, reviewing bugs with patches and sending those upstream or to debian, trying to lower our delta
[10:41] <vish> seb128: hi , upstream just pushed a slightly different fix for Bug #270206 , just a heads up
[10:41] <ubot2> Launchpad bug 270206 in rhythmbox (Ubuntu) (and 2 other projects) "RB should never start minimised to tray (affects: 32) (dups: 5) (heat: 156)" [Low,Fix released] https://launchpad.net/bugs/270206
[10:41] <seb128> dholbach, triaging bugs, doing merges on debian, reviewing bugs with patches and sending those upstream or to debian, trying to lower our delta, doing updates, etc
[10:41] <seb128> vish, ok, is there an issue with the current one?
[10:41] <dholbach> seb128: do you think somebody of the team could talk a bit about that at UDW? it'd be a good opportunity and we still have a few slots open: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep
[10:42] <vish> seb128: nope dont see any problems , just mentioning in case you didnt want any delta  :)
[10:43] <seb128> vish, I do regular snapshots for rb so no worry
[10:43] <vish> :)
[10:44] <seb128> dholbach, I knew you would try to trick me in! ;-)
[10:44] <seb128> dholbach, shouldn't the UDW topics be rather technicals?
[10:46] <dholbach> seb128: merging stuff, updating packages, etc sounds technical enough to my ears :)
[10:46] <dholbach> talking a bit about the process, maybe do a quick example or two
[10:46] <dholbach> done :)
[10:47] <seb128> dholbach, do I need to have the topic decided now?
[10:47] <seb128> dholbach, I'm fine doing an UDW session but I want to think a bit about the topic
[10:47] <dholbach> seb128: which slot on https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep would suit you?
[10:47] <seb128> dholbach, it will be something desktopish ;-)
[10:48] <seb128> dholbach, any of the slots on the 12th or 13th or the 8pm on the 15th
[10:48] <seb128> dholbach, let's say the monday 7utc one
[10:49] <dholbach> seb128: just seb128 or seb128 and his desktop mafia?
[10:49] <seb128> just put my name for now
[10:49] <seb128> I will sort details in the next days and update people and title ;-)
[10:50] <dholbach> super
[10:50] <dholbach> seb128: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep - done
[10:50] <seb128> dholbach, thanks
[10:51] <seb128> dholbach, it has better bringing me some contributors or I will ask for my money back! ;-)
[10:51] <dholbach> seb128: sure :)
[10:51] <dholbach> seb128: so… you're looking forward to the Germany game on Sunday already? ;-)
[10:53] <seb128> dholbach, seeing Germany getting kicked out by our british friends, sure ;-)
[10:54] <dholbach> seb128: MAN! YOU'RE GERMAN!
[10:54]  * dholbach better leaves the channel quickly :)
[10:54] <seb128> dholbach, lol
[10:54]  * seb128 hugs dholbach
[10:54]  * dholbach hugs seb128 back
[11:05] <tseliot> seb128: do you know how to set gconf key values in deb packages?
[11:05] <pitti> ah, I saw the game last night in a "Biergarten", very amusing
[11:05] <tseliot> as in default values
[11:05] <dholbach> tseliot: have a look at the ubuntu-artwork package
[11:06] <tseliot> dholbach: will do, thanks
[11:06] <pitti> tseliot: that's done with the gconf schema files in general (/usr/share/gconf/schemas)
[11:06] <pitti> tseliot: or a debian specific "overrides" set in /usr/share/gconf/defaults/
[11:07] <pitti> the latter is dh_gconf and generally easier to use in packaging
[11:07] <seb128> tseliot, you can add a .gconf-defaults in the debian directory with lines "key value"
[11:07] <seb128> binary.gconf-defaults
[11:07] <pitti> does anyone have a printer and a minute to grab a log for me?
[11:07] <tseliot> seb128, pitti: ah, nice, thanks
[11:07] <seb128> pitti, on lucid or maverick?
[11:07] <pitti> seb128: doesn't matter
[11:07] <seb128> pitti, I can on lucid
[11:08] <pitti> I need an "udevadm monitor -e --udev" output when you plug it in
[11:08] <seb128> pitti, ok, one minute
[11:08] <pitti> I don't have a printer these days, sorry (my wife has it in Munich)
[11:08]  * pitti hugs seb128, merci
[11:08] <pitti> seb128: what I'm trying to do is to stop system-config-printer.py being started on boot
[11:09] <pitti> and instead launch it from update-notifier once either cups sends out a job notification or we get a printer hotplug event
[11:09] <pitti> -> avoids python in the ureadahead pack and boot sequence
[11:12] <pitti> mvo: hm, it seems update-notifier 0.99.3 is in lucid, but missing from lp:~ubuntu-core-dev/update-notifier/ubuntu
[11:12] <pitti> mvo: it does have versions up to 0.99.2 and then the debian/maverick ubuntu bits
[11:14] <seb128> pitti, http://paste.ubuntu.com/454372/
[11:15] <pitti> mvo: 0.99.3 is in the /lucid branch, but shouldn't the fix also be in trunk?
[11:15] <seb128> pitti, do we need python there, I though we started those autostart with a delay
[11:15] <pitti> seb128: merci beaucoup!
[11:15] <seb128> pitti, de rien
[11:16] <pitti> seb128: we do start it with a delay
[11:16] <pitti> seb128: but all the python bits are still in the ureadahead pack
[11:16] <seb128> pitti, so do we need to profile it?
[11:16] <pitti> I know we are craving for sub-seconds here :)
[11:16] <seb128> pitti, well, couldn't we just drop those and pay a bit extra load after the delay?
[11:16] <pitti> but even boot speed aside, it's a constantly running python process
[11:16] <seb128> right
[11:16] <pitti> and we don't really need it until we actually print stuff
[11:16] <mvo> pitti: iirc the changes are not releavent for lucid -> maverick, its just a fix for a upgrade issue
[11:17] <pitti> mvo: I see, thanks
[11:17] <pitti> seb128: a cheesy hack would be to delay by 60 seconds, then it would be off the ureadahead collector radar :)
[11:17] <pitti> but still, we do not really need to have that running all the time
[11:17] <pitti> how many people print on a netbook every day
[11:17] <pitti> and for those it won't be worse
[11:18] <seb128> pitti, right, I'm not discussing the fix, but I was suggesting as a workaround if you care about login you could delay it a bit and drop it from the profiling, it will be slow to start but that will not count in the session
[11:18] <pitti> seb128: right; that's on the radar (bump the delay from 30 to 60 s)
[11:18] <seb128> pitti, yeah, the suggestion was just for a quick hack to get things working today
[11:18] <seb128> if you can get the nice way done as well that's better indeed ;-)
[11:19] <seb128> -as well
[11:19]  * pitti feels sorry for mvo to abuse update-notifier even more
[11:19] <mvo> pitti: what do you do this time?
[11:19] <pitti> you know, if only we had a system which could launch programs on certain events
[11:19] <pitti> we could call it "uplaunch" or "upstart" or so
[11:19] <mvo> pitti: and its all going into upstart, maybe even this cycle ;)
[11:19] <mvo> pitti: it will be run for the user as well
[11:19] <pitti> mvo: right, that's what I'm craving for
[11:20] <mvo> pitti: yeah - what will you do with u-n this time?
[11:20] <pitti> mvo: for now, u-n is just a convenient place to run system-config-printer.py when a printer gets connected or a print job is sent
[11:28] <pitti> mvo: would you mind if I rename the "firmware" bit to "uevent" in trunk and reorder things a bit so that it's easier to add new uevent types?
[11:28] <pitti> then I'd do the s-c-p things in a branch
[11:29] <mvo> ok
[11:29] <mvo> pitti: that is fine with me
[11:29] <pitti> danke
[11:44] <pitti> update-notifier (0.101ubuntu1) UNRELEASEDmaverick; urgency=low
[11:44] <pitti> mvo: I'll fix that in bzr, ok? since 1.01ubuntu1 is released
[11:44] <RAOF> pitti: Were you planning to upload a new apport with the attach_drm_info fixes soon?
[11:45] <pitti> RAOF: would tomorrow be ok? still busy with urgent OEM stuff today
[11:45] <pitti> RAOF: if it's hurting you, please just ask someone to cherrypick and upload, I'll deal with fixing bzr etc. later on
[11:46] <RAOF> I'd just like to wait on that before uploading the apport hook which depends on it.  It's only hurting in that our bug quality is slightly less than what it could be.
[11:51] <fta> i wish it was possible to specify which folders (from evo) are monitored in the indicator applet
[11:57] <didrocks> pitti: if you have some free slots, I have 3 sru waiting for some love: light-themes, evince and brasero
[11:58] <didrocks> no hurry though :)
[11:58] <pitti> didrocks: will have to wait until tomorrow, I'm afraid (or bug jdong/slangasek)
[11:58] <didrocks> pitti: don't be afraid, tomorrow is fine! thanks
[12:05] <seb128> didrocks, pitti: I tried pinging them on #ubuntu-devel, not sure if that will change anything but worth trying to balance a bit the sru load rather than always having pitti and cjwatson having to unblock those
[12:05] <didrocks> seb128: sure, thanks
[12:12] <pitti> seb128: do you have a /dev/lp0 or /dev/usblp0 of some sort with the printer turned on?
[12:12] <pitti> seb128: would you mind giving me an "udevadm info --attribute-walk --name=usblp0" output for that?
[12:13] <seb128> pitti, /dev/usblp0
[12:13] <seb128> ok
[12:13] <pitti> seb128: so I figure you have the "usblp" module loaded
[12:16] <mvo> mpt: hi, I just read your test-case in the SoftwareUpdateHandling page
[12:16] <mpt> hi mvo
[12:16] <seb128> pitti, usblp loaded yes
[12:17] <seb128> pitti, http://paste.ubuntu.com/454399/
[12:17] <pitti> purrfect, merci!
[12:17] <mvo> mpt: I'm not sure this is really what we want, it seems to me that if the user is presented with the updates he should see them all, no ?
[12:18] <seb128> pitti, you're welcome
[12:18] <mvo> mpt: I mean, I can see why you put it there, but it feels a bit odd, if he wants to apply them all *right now* why shouldn't he be able to?
[12:18] <mvo> mpt: or do you want to have different behvaior for auto-open and manual open? that would make it consistent again, but is IMO rather confusing
[12:19] <mpt> oh, hm
[12:19] <mpt> mvo, the reason it should show only non-security updates is that the security updates should already be installing in the background
[12:20] <mvo> (faketime is a good tool for these kinds of tests btw)
[12:20] <mpt> or have finished installing, even
[12:20] <seb128> rodrigo_, dobey: "ubuntu one disabled" displayed in every nautilus directory, wth?
[12:20] <rodrigo_> seb128, talk to the design team :)
[12:20] <seb128> rodrigo_, dobey: I know it's not enabled, I don't need it to be displayed everywhere
[12:20] <seb128> rodrigo_, who in the design team?
[12:20] <rodrigo_> seb128, we are adding a hidden gconf setting to not display it
[12:21] <rodrigo_> seb128, johnlea
[12:21] <pitti> that seems rather pointless to me?
[12:21] <rodrigo_> seb128, well, the label is just informational, the bar is there to be able to enable it
[12:21] <pitti> why would someone ever enable that gconf key to see the message?
[12:21] <mvo> mpt: right, but that is not necessarily the case that security-updates are installing aleady, it depends on when the background cron script runs
[12:21] <rodrigo_> seb128, don't you see the 'enable' button?
[12:21] <rodrigo_> pitti, the gconf key would be to hide the location bar
[12:21] <mvo> mpt: so I guess it would be better if u-m would monitor changes and remove them on-the-fly once they are installed
[12:22] <mpt> mvo, ok. So how can we fix the test case to test that the security updates *have* installed in the background?
[12:22] <rodrigo_> seb128, if I were the one to decide, I would have patched nautilus-share to support u1, and have all this as part of the 'Share' tab in nautilus properties
[12:22] <seb128> rodrigo_, I do, but I don't want to enable it!
[12:23] <rodrigo_> seb128, yeah, I understand you :)
[12:23] <mvo> mpt:  running sudo /etc/cron.daily maually to ensure it is run and has finished should archive that
[12:23] <pitti> it does make sense to have this bar in the ubuntu one folder; but everywhere seems to be a bug
[12:23] <seb128> pitti, you can sync any folder now...
[12:23] <seb128> but the design is just broken
[12:23] <rodrigo_> pitti, yes, you can enable any folder for sync to u1
[12:23] <mvo> silly question: can gio and the gio async stuff not be used for uid == 0 ? for some reaosn I get "operation not supported" when the same code works perfectly fine as user
[12:23] <pitti> well, but that doesn't mean that I'm going to
[12:24] <rodrigo_> pitti, right
[12:24] <mpt> mvo, ok, and how should faketime be used in that test case?
[12:24] <seb128> rodrigo_, thanks, I'm going to talk to johnlea
[12:25] <rodrigo_> seb128, do you have a u1 account?
[12:25] <mvo> mpt: hold on a sec, I contruct a commandline for tihs
[12:25] <rodrigo_> seb128, because there's still no code to check that, and not show the bar at all if you don't
[12:25] <seb128> rodrigo_, I think I have yes
[12:25] <rodrigo_> ah, ok, then you'll have to see it everywhere :D
[12:26] <mvo> mpt: faketime  -f '+1d' update-manager should work
[12:26] <rodrigo_> well, not in folders out of your home, that's also a bug that we need to fix
[12:26] <mvo> mpt: eh, nonsesnse, sorry
[12:26] <mpt> mvo, update-notifier instead?
[12:27] <mvo> mpt: yes, but that needs to be killed before, so killall update-notifier; faketime -f +1d update-notifier
[12:27] <pitti> mvo: faketime? is that an ld_preload which alters the result of gettimeofday()?
[12:27] <mvo> pitti: yes, pretty cool
[12:27] <pitti> neat
[12:28] <mpt> mvo, ok, and how do you tell that the background updates have finished? Does cron.daily wait for unattended-upgrades to exit?
[12:28] <mvo> mpt: hrm, sitll not right: NO_FAKE_STAT=1 faketime -f +1d update-notifier (the NO_FAKE_STAT is important
[12:28] <mvo> mpt: yes
[12:29] <mpt> mvo, so: killall update-notifier &&  NO_FAKE_STAT=1 faketime -f +1d update-notifier
[12:29] <pitti> mvo: I want a fakeseb128 script!
[12:29] <didrocks> pitti: why do you want the fake when you can have the real one? :)
[12:29] <pitti> cause I don't have sudo on seb128 :)
[12:29] <mvo> mpt yes
[12:30] <didrocks> heh
[12:30] <mpt> #!/bin/bash
[12:30] <mpt> echo "is gtk bug"
[12:30] <pitti> "iz"
[12:30] <pitti> mpt: but right, that'll get us 90% of the way
[12:31] <mpt> See, I can't even write a two-line script without at least one bug
[12:31] <lifeless> we've got no chance :)
[12:32] <pitti> $ apt-get source seb128
[12:32] <pitti> E: Unable to find a source package for seb128
[12:32] <mpt> mvo, so when you run that, update-manager should open immediately?
[12:32] <pitti> lifeless: I'm afraid we don't, right
[12:33] <rodrigo_> seb128, btw, if I understood correctly the notify-osd page, for a notification coming from a daemon (that is, no window to show the notification in), the morphing window/alert box should be shown in the background, behind all open windows, right?
[12:34] <rodrigo_> mpt, ^^
[12:34] <mpt> rodrigo_, you seem to be mixing up three different things
[12:34] <mvo> mpt: killall update-notifier ; NO_FAKE_STAT=1 faketime -f +9d update-notifier works for me, the delay is ~10 seconds or so
[12:34] <mpt> rodrigo_, what specifically are you notifying people of
[12:35] <mvo> seb128: any clue about the gio question? can it run as root?
[12:35] <mpt> ?
[12:35] <rodrigo_> mpt, quota exceeded on u1 server, we need to allow the user to upgrade when that happens
[12:36] <mpt> rodrigo_, ok. Is anything going to go horribly wrong if someone delays that for 10 minutes, or 30, or 120?
[12:37] <seb128> mvo, sorry was on mumble talking to somebody
[12:37] <seb128> mvo, reading backlog
[12:37] <rodrigo_> mpt, no, of course not, but I wonder, if the window does not get the focus, and I don't have a taskbar and my desktop is full of maximized windows and running for several days, I might not see the window for days
[12:38] <seb128> rodrigo_, ok, talked to johnlea
[12:38] <seb128> rodrigo_, the design includes a way for users to opt out from showing this
[12:38] <rodrigo_> seb128, yes, the hidden gconf key
[12:38] <mpt> mvo, so have we successfully constructed a test case that passes, and therefore does not represent bug 549217? :-)
[12:38] <ubot2> Launchpad bug 549217 in update-manager (Ubuntu) "security updates not installed daily as configured (affects: 12) (dups: 2) (heat: 105)" [High,Triaged] https://launchpad.net/bugs/549217
[12:38] <seb128> rodrigo_, and it should be displayed only for user dirs, not for my usb stick or system directories
[12:38] <seb128> rodrigo_, which seems a bug in the current code
[12:38] <rodrigo_> seb128, yes, if it shows up there is just a bug we're fixing soon, yes
[12:39] <seb128> rodrigo_, ok thanks
[12:39] <seb128> mvo, I dodn't see the gio question?
[12:39] <mpt> rodrigo_, an alert in the background would be the way to do this, yes. I don't see why U1 quota would be more important than software updates, for example.
[12:39] <seb128> mvo, oh
[12:39] <seb128> mvo, did you try to sudo dbus-launch your code?
[12:39] <rodrigo_> mpt, right, I miss software updates many times, since I don't see the window
[12:40] <seb128> mvo, it might be using something from gvfs but it needs session bus for that
[12:40] <mvo> seb128: code
[12:40] <seb128> mvo, well "sudo dbus-launch update-manager"
[12:40] <rodrigo_> mpt, I start my desktop, run several apps on separate workspaces maximized, and no taskbar, so I miss that kind of windows many ties
[12:40] <seb128> mvo, or whatever you try to run
[12:40] <mvo> seb128: ok, thanks. I will try a alternative approach then. unfortunate as gio is really nice :/ its for aptdaemon
[12:41] <rodrigo_> mpt, not saying I'm a "normal" user, but it can happen for several users
[12:41] <seb128> mvo, but async on local locations should work without dbus
[12:41] <mvo> seb128: its async on networked
[12:41] <mvo> seb128: async http to be exact
[12:41] <mpt> rodrigo_, our designs will often assume that your configuration has some way of showing you that a window is requesting attention. It dosn't have to be a taskbar, if you remove the taskbar, but it has to be *something*.
[12:41] <rodrigo_> mpt, and what is it?
[12:41] <seb128> mvo, ok, so you use the gvfsd-dav backend I guess
[12:42] <mvo> seb128: :) dunno, whatever gives me http :)
[12:42] <seb128> mvo, in which case you need dbus communication yes
[12:42] <rodrigo_> mpt, in my current setup, there's nothing
[12:42] <mpt> rodrigo_, by default, it's the taskbar. If you remove the taskbar, it's up to you. Might be Docky or something else.
[12:42] <seb128> mvo, glib is only local, all non local things are gvfs backends
[12:42] <mvo> seb128: ok, thanks. I will redo the code without gio then
[12:42] <seb128> mvo, ok
[12:43] <rodrigo_> mpt, so users without taskbar nor docky, they won't see the notification in many cases, that's my point
[12:43] <seb128> mvo, you don't want to depends on gvfs? or getting dbus to work is an issue?
[12:43] <rodrigo_> mpt, I wonder if the notifications (notify-osd) could be clickable so that a dialog is open when the user clicks on them?
[12:44] <mvo> seb128: getting it to work is the issue
[12:44] <seb128> rodrigo_, is there really anybody using a desktop without something listing open tasks?
[12:44] <rodrigo_> or even better, a place where notifications are stacked, not all (like user xx is online/offline, of course), but important ones, that need user's reaction
[12:44] <mvo> seb128: it does not seem to work for me, i get "operation not supported" when trying my codein sudo
[12:44] <rodrigo_> seb128, me :D
[12:45] <seb128> mvo, ok, dunno offhand then, would need debugging
[12:45] <rodrigo_> seb128, well, I have the window list applet, but that doesn't flash nor asks for attention when a window is flashing, afaik
[12:45] <seb128> rodrigo_, it does
[12:45] <rodrigo_> really? I've never seen it do that
[12:45] <seb128> or the one in the corner you mean
[12:45] <rodrigo_> I¡ll pay more attention
[12:45] <seb128> no I'm speaking about the tasklist
[12:45] <rodrigo_> seb128, yes, the one in the corner
[12:45] <seb128> rodrigo_, well maybe we should fix it to do that ;-)
[12:46] <mpt> rodrigo_, no, notification bubbles are for non-interactive notifications. As I said, our designs assume you have a way of seeing when windows request attention, and Ubuntu provides a mechanism for that by default.
[12:46] <rodrigo_> seb128, yes
[12:47] <kiwinote> mvo: lp:~kiwinote/python-apt/conflict-with-provided-packages
[12:48] <kiwinote> mvo: checks for conflicts with provided packages in deb files
[12:49] <mvo> kiwinote: aha, nice. are you working on porting the remaining bits of functinality/fixes from gdebi intp python-apt ?
[12:50] <kiwinote> mvo: this was a test case for gdebi, but gdebi failed it as well
[12:51] <kiwinote> mvo: gdebi-test7.deb
[12:55] <kiwinote> mvo: gdebi-test9.deb as well actually
[12:56] <mvo> kiwinote: let me have a look
[13:38] <tseliot> didrocks: what's the difference between setting gconf default values as you did in ubuntu-netbook-default-settings and doing it with a .gconf-defaults file in debian/ ?
[13:39] <didrocks> tseliot: which file are you looking at? (and which version, I had to change some stuff in maverick)
[13:39] <tseliot> didrocks: I'm looking at the lucid package (0.7.5)
[13:40] <tseliot> didrocks: here's a relevant debdiff: http://launchpadlibrarian.net/36752932/ubuntu-netbook-remix-default-settings_une_session.debdiff
[13:41] <didrocks> tseliot: 20_une-gconf-mandatory is just for mandatory, and I had to rename it to not being taken in dh_gconf as I don't install it in the default path
[13:42] <didrocks> tseliot: you see what was added to postinst? this is the magic that dh_gconf normally generate for you if you install in normal configuration path
[13:42] <tseliot> didrocks: ah, so there's no need to call update-gconf-defaults directly
[13:42] <tseliot> if you use the default path
[13:42] <didrocks> tseliot: no, if you use the default filenames and path (those value will be for every gnome session in gdm) :)
[13:43] <tseliot> didrocks: in my case 2 identical files were created: 10_metacity and 16_metacity in /usr/share/gconf_defaults
[13:43] <tseliot> didrocks: with the following content: /apps/metacity/global_keybindings/run_command_window_screenshot "<Alt>Print"
[13:43] <didrocks> tseliot: hum? I was thinking that 20 was the default priority value
[13:43] <didrocks> tseliot: what's your file name in debian/ directory?
[13:43] <tseliot> didrocks: however if I check gconf-editor nothing changed
[13:44] <tseliot> didrocks: metacity.gconf-defaults
[13:44] <tseliot> and in debian/rules I did:
[13:44] <tseliot> binary-fixup/metacity::
[13:44] <tseliot> 	dh_gconf --priority=16
[13:44] <didrocks> tseliot: can you pastebin the diff, please?
[13:44] <tseliot> sure
[13:45] <didrocks> tseliot: gconf-editor won't take the value if you changed it manually btw
[13:45] <didrocks> tseliot: you should unset it first
[13:46] <tseliot> didrocks: http://pastebin.ubuntu.com/454435/
[13:47] <tseliot> didrocks: yes, I changed it manually but then I removed the value from gconf-editor
[13:47] <didrocks> tseliot: which do you want it to be specially 16 as a priority?
[13:47] <didrocks> tseliot: I think dh_gconf is called twice there
[13:48] <tseliot> didrocks: yes, that's my guess too. They are the same file, and I need just one
[13:48] <tseliot> didrocks: shall I unset the key in the preinst?
[13:48] <didrocks> tseliot: check you debian/metacity.postinst but you should see two update-gconf-defaults
[13:48] <didrocks> tseliot: no, please, don't do that :)
[13:48] <didrocks> tseliot: so, first thing (just having one file)
[13:49] <didrocks> remove your change in debian/rules
[13:49] <didrocks> it's not needed
[13:49] <tseliot> didrocks: I didn't really want to do that in the preinst, it sounded a little ugly ;)
[13:49] <didrocks> tseliot: and wrong, as it's runned as root :)
[13:49] <didrocks> tseliot: so, remove your changes in debian/rules
[13:50] <tseliot> so much for user configs ;)
[13:50] <didrocks> you will get just one file in /usr/share/gconf/defaults/ which is 10_metacity
[13:50] <didrocks> tseliot: evevn, you should add you value to metacity-common, isn't?
[13:50] <tseliot> didrocks: ah, so dh_gconf is called automatically
[13:50] <didrocks> tseliot: you already have one
[13:51] <didrocks> tseliot: yeah, gnome.mk is making the magic happen :)
[13:51] <tseliot> ok
[13:51] <didrocks> so, add your lilne to metacity-common
[13:51] <didrocks> line*
[13:51] <didrocks> then, we will check why the value isn't taken into account
[13:52] <tseliot> didrocks: right, I hadn't even noticed the existence of metacity-common.gconf-defaults
[13:53] <tseliot> didrocks: maybe quotation marks confused gconf
[13:54] <didrocks> tseliot: hum, IIRC, yeah, you don't need it
[13:54] <tseliot> I'll try with <Alt>Print instead of "<Alt>Print", just in case
[13:54] <didrocks> tseliot: I'm surprised, Alt Print is already the default there
[13:54] <tseliot> I saw that in the metacity-common file
[13:54] <didrocks> yeah
[13:55] <didrocks> so, what are you trying to do? :)
[13:55] <tseliot> didrocks: yes,  Alt Print is hardcoded in a header. Mutter is doing some funny stuff though
[13:55] <didrocks> tseliot: oh ok, so the gconf value is ignored?
[13:56] <tseliot> didrocks: I'm rebuilding the package right now
[13:56] <didrocks> great, that should work then
[14:02] <pitti> tkamppeter: does s-c-p and udev-configure-printer currently pick up and autoconfigure bluetooth printers?
[14:02] <pitti> tkamppeter: I don't see anything in /lib/udev/rules.d/70-printers.rules which would do that; is that correct?
[14:05] <tseliot> didrocks: it still doesn't seem to be set
[14:06] <tseliot> didrocks: "gconf-tool --dump /apps/metacity/global_keybindings" shows that it has no value
[14:06] <didrocks> tseliot: gconftool-2 -g /apps/metacity/global_keybindings/run_command_window_screenshot
[14:06] <didrocks> gconftool-2 -u /apps/metacity/global_keybindings/run_command_window_screenshot
[14:06] <didrocks> gconftool-2 -g /apps/metacity/global_keybindings/run_command_window_screenshot
[14:06] <didrocks> the second line should unset the value
[14:07] <didrocks> I have moderate confidency in gconf-editor for that task, I think I had some issue with it not resetting the value to default
[14:08] <tseliot> didrocks: yes, after passing it "-u" it finally gives me "alt Print"
[14:08] <didrocks> tseliot: never trust graphical tools :)
[14:09] <tseliot> didrocks: I know.. ;) Thanks a lot for your help
[14:09] <didrocks> tseliot: you're welcome
[14:38] <pitti> RAOF: fixed apport uploaded to maverick, so go wild
[14:39] <seb128> didrocks, no hurry but could you uploaded the version of your sru to maverick when you will have a free slot? not likely today with unity updates, that can wait next week
[14:39] <seb128> didrocks, lucid and maverick and not on sync for the GNOME sources we merged so they can't be copied
[14:39] <seb128> uploaded -> upload
[14:40] <didrocks> seb128: sure, will be probably tomorrow
[14:40] <seb128> didrocks, no hurry, next week will do
[14:40] <pitti> didrocks: thanks for your p-d-e LINGUAS fix; do you have some time to also write a quick test for it?
[14:40] <didrocks> seb128: theme/envince/brasero right?
[14:40] <seb128> didrocks, I'm just mentioning it in case you didn't notice the versions in maverick were different
[14:40] <pitti> in exchange, I have 20 mins now to look at the SRU queue
[14:40] <didrocks> pitti: can put that on my TODO :)
[14:40] <seb128> didrocks, the theme can be copied I think
[14:41] <seb128> didrocks, the 2 others yes
[14:41] <didrocks> pitti: ahah, some kind of trade? :-)
[14:41] <pitti> didrocks: j/k
[14:41] <dobey> pitti, seb128: hehe, i see you guys missed that big argument session at uds :)
[14:41] <didrocks> pitti: will do next week, when the boring freeze will be in process
[14:41] <seb128> dobey, the nautilus ubuntuone sync one?
[14:41] <pitti> dobey: ♩ Madness takes its toll! ♪
[14:42] <didrocks> seb128: there is an annoying libtool incompatibity issue btw in brasero as upstream use a new version, you have to remove ltmain.sh and autoreconf -i to get it copied with our (older) version
[14:42] <didrocks> (just FYI)
[14:42] <dobey> seb128: yeah, where i was like "yeah, we can't really be putting that bar in every folder in the user's face"
[14:43] <seb128> didrocks, ok
[14:43] <seb128> dobey, you were right
[14:43] <dobey> of course. but hard to make design see that sometimes :(
[14:44] <seb128> displaying until somebody click "enable" or "stop bothering me" would be ok
[14:44] <seb128> ie having both options in the bar on first run
[14:44] <seb128> and display it until the user pick one
[14:46] <pitti> please let's not turn everything into a billboard
[14:49] <pitti> seb128: seems the recent gdm SRU changes aren't in maverick yet?
[14:50] <pitti> I mean for the one currently in -proposed; it's ok for -updates otherwise
[14:52] <pitti> same for empathy
[14:53] <seb128> pitti, empathy we have 2.31.3 so they should
[14:53] <seb128> pitti, gdm right, I was waiting for the 2.30 tarball they will roll this week rather than playing backport game over 2.30.2 we have in maverick
[14:53] <pitti> seb128: are the changes in bzr?
[14:53] <pitti> I mean the ones which we did in the packaging
[14:59] <seb128> pitti, we did some in the packaging?
[15:00] <seb128> pitti, the 2.30.2.is.2.30.0-0ubuntu1 changes are in maverick
[15:00] <seb128> didrocks' fixes from the current upload is in maverick
[15:00] <seb128> other changes are git backports we can drop when gdm guys roll a tarball
[15:00] <seb128> which should be this week
[15:01] <seb128> they got delay because of a string freeze breakage issue they try to get resolved with translators
[15:01] <rickspencer3> seb128, pitti, kenvandine, didrocks, vuntz, lamalex, everybody ...
[15:01] <seb128> pitti, so short reply "once they roll a tarball maverick will have all the sru changes"
[15:01] <didrocks> hey rickspencer3
[15:01] <kenvandine> hey rickspencer3
[15:01] <lamalex> salut
[15:01] <rickspencer3> why aren't we getting people applying for the netowrking/browser maintainer job?
[15:01] <pitti> seb128: the changes to read .Xinitrc or whatever we fixed in that SRU
[15:01] <rickspencer3> we desperately need someone, and it's a *cool* job!
[15:02] <kenvandine> :)
[15:02] <seb128> pitti, those are in maverick
[15:02]  * pitti in a meeting, bbl
[15:02] <seb128> pitti, we got the 2.30.2 updates which had those changes in maverick and didn't roll back versions there
[15:02] <seb128> pitti, ie the first sru which had all the changes and failed verification
[15:03] <seb128> rickspencer3, that I would like to know as well...
[15:03] <rickspencer3> here's the job: http://webapps.ubuntu.com/employment/canonical_UDE/
[15:03] <lamalex> well, i mean i *technically* applied for that job, but you sold me on the other one
[15:04] <rickspencer3> lamalex, nooooooo
[15:04] <lamalex> haha
[15:04] <lamalex> Maybe people have the perception that it's a particularly difficult job
[15:05] <rickspencer3> well, difficult jobs can be the most rewarding
[15:05] <didrocks> I agree with lamalex, i think it's more fear than anything else
[15:05] <lamalex> has anyone tried approaching a nm/chromium community member?
[15:08] <pitti> seb128: ah, and we put that into maverick, right? so we can just close the maverick tasks?
[15:10] <vuntz> rickspencer3: to be honest, any job with "web browsers" is something I would not consider fun
[15:10] <vuntz> rickspencer3: my first thought is "wow, backporting security fixes for firefox, no way"
[15:10] <rickspencer3> vuntz, aaarg
[15:10] <rickspencer3> but that's chrisccoulson job
[15:11] <rickspencer3> this job is more about eating candy, and petting unicorns
[15:11] <vuntz> heh
[15:11] <vuntz> but I guess most normal people would think like me on this anyway
[15:12] <lamalex> maybe the job description could be made more exact, to keep people from having that thought
[15:12] <seb128> pitti, just deal with the sru I will deal with the maverick tasks
[15:12] <vuntz> err
[15:12] <seb128> pitti, will be easier this way ;-)
[15:12] <vuntz> I meant "would not think"
[15:12] <chrisccoulson> my ears are burning
[15:12] <chrisccoulson> ;)
[15:13] <seb128> vuntz, why not trying to apply for this job just to see if you are right? ;-)
[15:13] <vuntz> seb128: heh. Because I don't see why it'd be a better job than the one I have now :-)
[15:14] <seb128> vuntz, that's because you didn't try! ;-)
[15:14] <vuntz> seb128: tss
[15:14] <vuntz> seb128: if I were to apply, I'd probably consider the release manager one, I guess. Although it's probably not that fun
[15:15] <rickspencer3> vuntz, I thought maybe you might know someone awesome who likes a good challenge
[15:15] <rickspencer3> vuntz, all jobs on Ubuntu are fun!
[15:16] <rickspencer3> lamalex, do you know anyone who knows any networking and/or browser code bases?
[15:16] <lamalex> the people i worked with at jolicloud
[15:16] <vuntz> rickspencer3: the awesome people I know are generally already aware of those jobs :-)
[15:18] <rickspencer3> lamalex, maybe you could let them know that we have this position?
[15:19]  * lamalex isn't sure how he feels about trying to poach ex-coworkers
[15:19] <lamalex> i can let them know though
[15:26] <rickspencer3> lamalex, well, it's not like you work for Canonical, so it's not really poaching
[15:26] <rickspencer3> but I understand
[15:26] <rickspencer3> it's more that they may also know people
[15:27] <rickspencer3> like, maybe they interviewed someone who wasn't a fit for their company, but would be awesome for this job, for example
[15:28] <lamalex> yeah, i will ask them
[15:58] <Laney> is there a PPA with rgba/csd gtk+?
[15:58] <Laney> or shall I just build my own with the patch?
[15:59] <seb128> tedg, bratsche, kenvandine: ^
[16:00] <kenvandine> no ppa
[16:00] <kenvandine> not that i know of anymore :)
[16:00] <Laney> kenvandine: I guess I can just install ubuntu1 though yeah?
[16:01] <seb128> you can yes
[16:01] <Laney> cool
[16:01] <Laney> there's a banshee patch that i hope will fix it there
[16:01] <Laney> want to test it
[16:01] <bratsche> Laney: Yeah, just patch it if you don't mind.  Let me know if there's anything I can do to help.
[16:03] <seb128> bratsche, do we have a wiki page or something explaining common issues or a reference bug?
[16:03] <bratsche> I don't think so.
[16:03] <seb128> bratsche, I guess the crashes are mostly a similar issues in different softwares
[16:04] <bratsche> Yup.
[16:04] <seb128> bratsche, by explaining what the issue is and how to fix it we might get people contributing to fixing some?
[16:05] <bratsche> Yeah, that's probably true.  There's a wiki page on live.gnome.org already, maybe I write something there.
[16:07] <seb128> bratsche, would be great ;-)
[16:44] <micahg> seb128: did you want me to look at merging gjs when I do my debian merges?
[16:45] <seb128> micahg, that would be nice thanks
[16:46] <seb128> micahg, do you think you will have time to do that for next week?
[16:46] <micahg> seb128: k, can gnome-shell wait until then?
[16:46] <micahg> seb128: idk, I guess it depends on what's left with the xulrdepends backporting
[16:46] <seb128> micahg, there is no hurry, g-s is outdated for 6 months and not building for weeks
[16:47] <seb128> micahg, but just updating to 0.7 and rebuilding might work for now?
[16:47] <micahg> seb128: the merges are scheduled as an alpha 3 work item, so I was planning to do them in a couple of weeks
[16:47] <seb128> micahg, ok, I will maybe try to do the version update for now if nobody else does it
[16:48] <seb128> just to see if we can get g-s to build
[16:49] <micahg> seb128: k, did you get my email earlier?  I'm going to try to make gnome-shell and gjs xul version independent
[16:53] <seb128> micahg, yes I did and dholbach pinged me about at the same time I was reading it to tell me your rebuild doesn't build
[16:53] <seb128> micahg, so I figured I would reply on IRC later on to discuss it
[16:55] <micahg> seb128: k
[17:35] <tkamppeter> pitti, principally yes, as the /usr/lib/cups/backend/bluetooth returns the IDs of the available Bluetooth printers. Problem is that the backend takes to long and so usually misses the 15 sec timeout of CUPS.
[17:37] <pitti> tkamppeter: but the udev rules can't pick that up, since there is no event when you turn on a BT device?
[17:38] <tkamppeter> pitti, yes, Plug'n'Print does not work, what I tried now is to connect to a Bluetooth printer like to a network printer.
[17:38] <tkamppeter> pitti, to make them discovered by Plug
[17:38] <pitti> tkamppeter: right, that'd work; thanks for confirming!
[17:39] <tkamppeter> 'n'Print (printer setuo by turning it on and/or bringing it close enough) we need UDEV rules.
[17:41] <tkamppeter> pitti, I wonder why the Bluetooth backend takes so long to find Bluetooth printers. I would need to make the network printer timeout in s-c-p much longer so that it does not miss Bluetooth printers and then users of network printers think that their printers are not found and give up too early.
[17:58] <pitti> seb128: do you happen to know if there is a non-deprecated equivalent of gtk_init()? i. e. for a small application to generate the default --help and set app name/version?
[17:58] <pitti> erm, gnome_init() I mean
[18:10] <dobey> pitti: i think the answer is to use the GOptionParser bits. and gtk_init() knows how to do things
[18:11] <pitti> but in Python you don't even call gtk_init(), it's done by the import
[18:11] <pitti> dobey: GOptionParser, ah; thanks, I'll check that
[18:11] <dobey> pitti: yeah, in python you do some weird magic to hook up GOptionParser and the python OptionParser, iirc
[18:12] <dobey> pitti: i recall doing that in the old ubuntuone-client-applet...
[18:16] <dobey> pitti: ah, no special magic really, pygobject has the magic built-in :)
[18:16] <dobey> from gobject.option import OptionGroup, OptionParser, make_option
[18:17] <dobey> http://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-client/stable-1-0/annotate/10/bin/ubuntuone-client-applet#L563
[18:17] <pitti> dobey: awesome, thanks!
[18:18] <dobey> sure
[18:18] <dobey> pitti: you're an archive admin right? :)
[18:18] <pitti> dobey: yes
[18:19] <dobey> pitti: care to poke at the mocker package that's in that queue? :)
[18:19] <pitti> in which queue?
[18:19] <dobey> pitti: ajmitch sponsored it from revu last night, and so i believe it is just waiting for archive approval to make it into universe
[18:19] <pitti> ah, NEW?
[18:20] <dobey> yeah, i guess it would be in NEW
[18:23] <seb128> pitti, what dobey said
[18:23] <pitti> dobey: added to my todo list for the evening
[18:26] <dobey> pitti: thanks!
[18:33] <tkamppeter> pitti, I got an e-mail from Tim Waugh about the release of s-c-p 1.2.3 and he tells that it has udev support in the Bluetooth helper program.
[18:34] <pitti> nice
[21:42]  * didrocks waves goodnight
[22:13] <pitti> dobey: mocker accepted; sorry for the delay, have some fires to stamp out
[22:14] <dobey> pitti: no worries, thanks much!
[22:19] <seb128> dobey, the description is not really clear about what that is ;-
[22:22] <dobey> seb128: if you can find a better one, i'll be happy to change it, but it seems pretty clear to me. at least, the first sentence. The other part was added to satisfy the 3 line complaint, and is what the description of mocker is on launchpad.net/mocker
[22:22] <seb128> dobey, I've only read the one line description in the changes email
[22:23] <seb128> dobey, I guess the detailled description is better ;-)
[23:12] <gnomefreak> any idea on who to talk to about gnome-shell, launchpad tells me to file bug on gnomes bug tracker and they keep closing bugs on it since it is our packages PPA or official repos
[23:15] <seb128> upstream
[23:15] <seb128> what is their concern with ppa builds? those are daily builds no?
[23:18] <gnomefreak> seb128: our official builds have the issue as well
[23:19] <seb128> what issue?
[23:19] <gnomefreak> seb128: our desktop file contains menu items and it shouldnt
[23:19] <gnomefreak> there was another 1 i filed a while ago and cant recall what it was
[23:19] <gnomefreak> https://bugzilla.gnome.org/show_bug.cgi?id=622582
[23:20] <ubot2> Gnome bug 622582 in general "Gnome-shell fails to load from gnome menu" [Normal,Resolved: notgnome]
[23:20] <gnomefreak> thats this one
[23:21] <seb128> ok, dunno then
[23:21] <gnomefreak> we should also allow at the very least to be able to file bugs on our packages
[23:21] <seb128> our current official package comes from debian
[23:21] <seb128> and I don't know about the ppa one
[23:21] <seb128> you are
[23:21] <seb128> but I guess you use the ppa and not the ubuntu version
[23:21] <gnomefreak> i tried PPA to see if it had issues as well
[23:22] <seb128> well the ppa is not an ubuntu version
[23:22] <gnomefreak> seb128: tried both atm i have neither installed
[23:22] <seb128> that's why you can't open an ubuntu bug
[23:22] <seb128> where do you get an error?
[23:22] <gnomefreak> seb128: going to the LP page it says to file bugs with gnome-bt
[23:23] <seb128> which url?
[23:23] <gnomefreak> seb128: looking for it now
[23:24] <seb128> you tried to open a bug againt the upstream product not the ubuntu source
[23:24] <seb128> ?
[23:24] <gnomefreak> seb128: https://bugs.edge.launchpad.net/gnome-shell
[23:24] <seb128> TheMuso, hey
[23:24] <gnomefreak> oh
[23:25] <seb128> TheMuso, should we try to sru a accerciser update to lucid?
[23:25] <seb128> TheMuso, it fixes a crash bug reported in launchpad due to gtkbuilder changes in the lucid cycle
[23:25] <TheMuso> seb128: SOunds reasonable.
[23:26] <TheMuso> I can follow it up if you like.
[23:26] <seb128> TheMuso, that would be nice, maybe check GNOME a11y components we want to update for lucid .1?
[23:27] <seb128> TheMuso, we did sru quite some GNOME updates, so we might want do some of those as well
[23:27] <TheMuso> seb128: Yeah that too
[23:27] <seb128> TheMuso, we have some weeks so no hurry but if you find some time to review the updates which could be interesting and sru those...
[23:27] <seb128> TheMuso, thanks!
[23:27] <TheMuso> Sure thing.
[23:29] <Sarvatt> hmm, having all kinds of problems with totem-ffmpeg not finding codecs in maverick, its linked against libavutil49 not libavutil50?
[23:30] <Sarvatt> libavutil-extra-49 seems to be an empty package with just docs in it
[23:30] <seb128> Sarvatt, I've noticed some bugs about that but didn't have time to investigate yet
[23:30] <gnomefreak> seb128: thanks got it filied
[23:30] <seb128> I'm still running lucid on my main box, I was waiting for those sru round to be uploaded to upgrade now
[23:30] <Sarvatt> libgstffmpeg.so can't find libavutil.so.49 because the package isn't installing it, ahh
[23:32] <Sarvatt> ok that makes more sense now :) i didn't see any errors until i ran gst-inspect and saw the problem, it was just failing to find codecs to download
[23:33] <Sarvatt> libavutil49 is correct, its libavutil-extra-49 that is screwed up and that replaces libavutil49
[23:34] <seb128> Sarvatt, oh, so you figured the issue?
[23:34] <seb128> Sarvatt, could you let siretart know if that's a ffmpeg bug?
[23:34] <Sarvatt> not yet, i dont know where i got this screwed up libavutil-extra-49 from, could have gotten it from medibuntu and it hung around after the upgrade
[23:35] <seb128> not likely
[23:35] <seb128> we got quite some bugs about it and I've got a buggy box which was a stock lucid install upgraded
[23:35] <Sarvatt> yeah this is in universe, grabbed the deb from the archive and its messed up
[23:36] <seb128> I never added any additional apt source for ffmpeg on it
[23:36] <Sarvatt> gstreamer0.10-ffmpeg should just be built against libavutil50 anyway though shouldn't it?
[23:37] <seb128> I guess so
[23:37] <seb128> I've not tried to figure what soname is current
[23:37] <seb128> why is there 2 versions?
[23:38] <Sarvatt> other junk is still using libavutil49 though like vlc and thats screwed up also if you have extra installed :(
[23:39] <Sarvatt> they bump the sonames so often, i'm sure stuff just hasn't been rebuilt against the new one yet
[23:39] <seb128> can you check with siretart which one should be used?
[23:39] <Sarvatt> yeah libavutil49 isn't even built in ffmpeg-extra anymore so the screwed up empty package is just hanging around in the archive
[23:40] <Sarvatt> yeah will try to track him down
[23:40] <seb128> thanks