[02:23] <robru> so I needed a headset for mumble. went to two different stores and got two different brands (yknow, just to be safe), get them both home... and neither of them actually work. one has a working ear piece with a broken mic, and the other one (which was more expensive!) does not actually work at all.
[02:27] <robru> tried them both on two different computers, so I can be reasonably sure that it's actually them, not the computer.
[02:42] <mterry> robert_ancell, I'm close to a fix.  What's your EOD?
[02:42] <mterry> (I'm talking about the average color issue)
[02:43] <robert_ancell> mterry, I'm here another 2.5 hours
[02:43] <mterry> cool
[02:43] <robert_ancell> mterry, the lightdm release is good to go, just waiting the ffe. I can make the u-g release any time you're ready
[02:44] <mterry> robert_ancell, I ended up pulling the algorithm gnome-desktop uses into unity-greeter.  We own the copyright since it's from unity and patched on top of what upstream uses for color-picker
[02:44] <robert_ancell> mterry, btw, I noticed if you move the cursor to the second monitor the layout is all messed up :(
[02:44] <mterry> robert_ancell, oh noes
[02:44] <robert_ancell> oh, easy
[02:44] <mterry> robert_ancell, I can fix that post UIF  :)
[02:44] <robert_ancell> mterry, yeah
[02:56] <mterry> robert_ancell, https://code.launchpad.net/~mterry/unity-greeter/average-color/+merge/121977
[02:57] <mterry> robert_ancell, so the only other change I think may be coming for unity-greeter is Wellark_ was going to patch our spawn call for nm-applet to set an environment variable that it would use to hide some of its UI
[02:57] <robert_ancell> cool
[02:57] <mterry> robert_ancell, cyphermox didn't want to use the existing GREETER_MODE var I don't believe
[02:57] <mterry> robert_ancell, so I can either release during my day with that patch
[02:58] <mterry> robert_ancell, or you can and we can just distro patch that one-liner for a bit
[02:58] <cyphermox> mostly just want it upstreamable as much as possible, there are already so many patches in nm-applet and this is reusable outside a greeter
[02:58]  * mterry waves at cyphermox  :)
[02:58] <cyphermox> yo/sup ;)
[02:59] <robert_ancell> mterry, we can make a release today and one tomorrow
[02:59] <mterry> robert_ancell, true
[02:59] <robert_ancell> the second release should be easy to get approved if it just has that one change
[02:59] <mterry> robert_ancell, if the FFes don't come in, I'll push feature-hobbled versions to Ubuntu
[02:59] <robert_ancell> ok
[03:02] <mterry> robert_ancell, pushed.  I'll stop working now and see you again tomorrow sometime  :)
[03:02] <robert_ancell> mterry, thanks
[03:04] <RAOF> mterry: Oooh! While you're here, are you aware of https://bugs.launchpad.net/ubuntu/+source/duplicity/+bug/1016850 ? I can reliably reproduce this on my system.
[03:04] <ubot2`> Ubuntu bug 1016850 in duplicity "duplicity crashed with UnicodeDecodeError in __main__: 'ascii' codec can't decode byte 0xc3 in position 1066: ordinal not in range(128)" [Undecided,Confirmed]
[03:04] <mterry> RAOF, I am, it's stopped me from making backups for the past few months
[03:04] <mterry> RAOF, so I will definitely fix it
[03:04] <mterry> RAOF, but I scheduled the fix for post FF
[03:05] <RAOF> Ah, good.
[03:05] <mterry> Some utf8 issue it seems, hopefully easy fix
[03:06] <RAOF> Yeah; it's probably that I've got a (valid UTF-8) ? in a filename somewhere.
[03:08] <robert_ancell> mterry, I'm not seeing the push
[03:09] <mterry> robert_ancell, gah
[03:09] <mterry> got it
[03:09] <mterry> robert_ancell, try now
[03:09] <robert_ancell> mterry, there now, ta
[03:13]  * ml|vacation waves at raof
[03:13] <RAOF> ml|vacation: Yo!
[03:13] <RAOF> ml|vacation: How's .au treating you?
[03:14] <ml|vacation> the dry air has caused too much problems but slowly getting over it now :)
[03:14] <ml|vacation> other than that great
[03:15] <RAOF> You're way out in inland NSW?
[03:15] <ml|vacation> yeah was in newcastle yesterday, lot better there
[03:16] <RAOF> What with the ocean and all!
[03:16] <ml|vacation> ;D
[03:17] <ml|vacation> think i saw a kangaroo on the way back from NSW too, small one though
[03:17] <ml|vacation> near the side of the road
[03:18] <RAOF> I'm surprise you haven't seen lots of them.
[03:18] <RAOF> They're usually pretty numerous.
[03:18] <RAOF> Also: quite like jumping out in front of cars.
[03:18] <ml|vacation> yeah..
[03:19] <ml|vacation> was warned about that
[03:19] <ml|vacation> it even has its own sign, watch out for kangaroos, made me laugh
[03:20] <ml|vacation> and all the driving on the wrong side of the road is weird
[03:21] <ml|vacation> arrrrrk
[03:23] <RAOF> Heh
[03:25] <ml|vacation> according to the person that typed arrrk, you're no fun
[03:41] <RAOF> ??
[03:56] <ml|vacation> visiting a friend while here ;)
[03:56] <ml|vacation> *:)
[04:35] <pitti> Bonjour
[04:47] <RAOF> Hm. That's not going to end well. Shotwell is up to 13.5GB virt.
[04:53] <pitti> urgh, you have that much RAM?
[05:24] <RAOF> Ram + swap, yes. Not *much* more ram + swap than that, which is why the OOM killer kicked in shortly after.
[05:29] <lickalott> wondering if anyone has seen this issue before:  I have 3 drives mounted through fstab and shared out via NFS through exports.  Im also sharing one of the drive out via apache.  After the apache installation and configuration, I can't "map network drive"(nfs) the one drive that is shared out on apache
[08:09] <seb128> hey desktopers
[08:09] <pitti> c'est un homme français!
[08:20] <davidcalle> seb128, hey, le changement de langue par défaut est prévu pour quand déjà? ;)
[08:22] <seb128> davidcalle, salut, tu fais bien de le rappeler, on devrait faire ça cette semaine si on le veut pour beta1
[08:22] <seb128> ;-)
[08:22] <seb128> pitti, salut, ca va ?
[08:23] <pitti> seb128: un peu mieux; I caught a cold from my wife :/
[08:23] <seb128> oh :-(
[08:23] <seb128> summer is not the season for colds!
[08:24] <AfC> it's winter
[08:24] <pitti> that's what I told her as well; il fait froid!
[08:24] <pitti> it's been 10 degrees in the mornings now
[08:25] <seb128> ici aussi...
[08:31] <davidcalle> seb128, the photos lens mir has been answered, I've fixed the first issue (Flickr -> https), but I'm wondering if the request of deploying a brand new python3-oauth2 package is not out of scope at this point of the cycle.
[08:32] <chrisccoulson> good morning everyone
[08:32] <seb128> chrisccoulson, hey, ca va ?
[08:32] <davidcalle> hey chrisccoulson
[08:32] <chrisccoulson> hi seb128, good thanks. how are you?
[08:32] <chrisccoulson> hi davidcalle, how are you?
[08:33] <davidcalle> chrisccoulson, good, thanks
[08:33] <seb128> chrisccoulson, I'm good thanks
[08:33] <seb128> davidcalle, it wouldn't make a big difference for you, would it? We just need somebody to get you that package available right?
[08:34] <davidcalle> seb128, right, it wouldn't make any difference for me.
[08:35] <seb128> davidcalle, ok, don't bother much then, I will see with Ken to get that problem solved
[08:35] <davidcalle> seb128, oh ok then, ty
[08:36] <seb128> davidcalle, yw!
[08:38] <ogra_> seb128, i was pointed to bug 1043589, you might want to close it with the next upload :)
[08:38] <ubot2`> Launchpad bug 1043589 in compiz "[FFe] Add support for OpenGL|ES" [High,Fix released] https://launchpad.net/bugs/1043589
[08:38] <ogra_> (if you dont have it on the radar already)
[08:40] <seb128> ogra_, cf #ubuntu-release :p
[08:42] <seb128> ogra_, but thanks for thinking about it and telling me ;-)
[08:43] <ogra_> :)
[08:43] <xnox> seb128: what is the minimum screen resolution ubuntu desktop supports?
[08:43] <seb128> xnox, we don't have such notion I think
[08:43] <seb128> xnox, as low as xorg supports? 320x200?
[08:44] <ogra_> 800x600 i think
[08:44] <ogra_> wrt app sizes at least
[08:44] <seb128> I don't understand the question
[08:44] <seb128> ogra_, well, you can go lower, it's just not a nice experience...
[08:44] <xnox> seb128: but we do. With 320x200 you will not see "continue" button in ubiquity for example, and will fail to install.
[08:44] <ogra_> seb128, we once defined that all apps have to fit on 600 vertical pixels, didnt we ?
[08:44] <seb128> xnox, you can alt-click-dnd to access it
[08:44] <ogra_> or OSG (or however they were called back then) did
[08:45] <seb128> ogra_, I don't think we did, we have stuff that are known to not fit
[08:45] <xnox> seb128: virtual desktops, for the win?!
[08:45] <ogra_> probably it was only ubiquity ...
[08:45] <seb128> xnox, being able to dnd part of dialogs out of the screen for the win
[08:45]  * ogra_ isnt sure anymore but i know there was some work invested ...
[08:46] <xnox> seb128: how tall is the top unity bar?
[08:46] <seb128> xnox, I'm not sure what you are trying to figure out, but yeah, 800x600 is what we would recommend to have, though we don't go out of our way to block users to run ubuntu if their screen is lower resoluition
[08:46] <ogra_> (back when there still was a mobile team and unity-2d was just being developed)
[08:47] <seb128> xnox, 24 pixels I think
[08:47] <seb128> or maybe 16 ;-)
[08:47] <xnox> seb128: I have a failing unit test in ubiquity: if there is an existing old ubuntu installation(s) i need to present the following options: upgrade in-place, erase and reinstall, dual-boot, wipe all and setup full-disk encryption, lvm & manual partitining..... I am running out of vertical pixels. And currently a unit test limits me to 500px height.
[08:47] <seb128> take a screen, open it in gimp and look :p
[08:48] <xnox> =P
[08:48] <xnox> seb128: retina display, anyone?!
[08:48] <xnox> =)
[08:48] <seb128> xnox, we used to have top and bottom panels and wm decorations
[08:48] <seb128> but 500pixel seems a good limit
[08:48] <xnox> uhah =)
[08:49] <AfC> You use Xephyr to test various things, right?
[08:52] <xnox> AfC: not for the installer, Xephyr is not running in the LiveCD. I use VMs
[08:52] <AfC> Hm.
[08:52] <AfC> xnox: do you now anyone using it for $whatever?
[08:52] <AfC> xnox: do you know* anyone using it for $whatever?
[08:53] <AfC> (I should just put my question)
[08:53] <AfC> Does anyone know how to get e.g. themeing to work in a nested X server like Xephyr or Xvfb?
[08:53] <AfC> Right now there's no window manager or settings demon, so there's no GTK theme, so using it to take snapshots for documentation is rather horrid
[09:00] <chrisccoulson> hmmmm, i wonder why ken is requesting a FFe for bug 1040313? the patch is in a future stable update (Firefox 17) anyway, so that seems a bit pointless :/
[09:00] <ubot2`> Launchpad bug 1040313 in firefox "[FFE] Need access to native handle for tabs" [Undecided,Confirmed] https://launchpad.net/bugs/1040313
[09:02] <seb128> chrisccoulson, people tend to forget that firefox has a special update status that let it land features any time :p
[09:02] <ogra_> if its carried as a patch until v17 enters the archive it needs an FFe
[09:03] <chrisccoulson> ogra_, that seems like a waste of time. what's going to happen if the request is rejected? it  just means that it will land, but a few weeks later instead
[09:03] <seb128> ogra_, that's a bit stupid rule since the feature will land anyway even if nacked
[09:03] <chrisccoulson> it seems like busy-work to me ;)
[09:04] <ogra_> well, not sure that is the actual rule ... its the assumption under which i ask for FFe's
[09:04] <ogra_> :)
[09:04] <seb128> ogra_, which makes sense for everything bug firefox
[09:04] <ogra_> if there is a patch to be maintained ...
[09:04] <seb128> since nothing else will land new features in a security update :p
[09:04] <xnox> some of the stuff I want to land are bug-fixes, unless past the User Interface Freeze, in which case I'll need exceptions?!
[09:04] <ogra_> xnox, no
[09:05] <ogra_> bug fixes that dont add new features are always fine
[09:05] <ogra_> same goes for minor version upgrades of packages
[09:05] <xnox> ogra_: in that case there are not 4 ubiquity FFe bugs, but 2
[09:05] <ogra_> major needds an FFe, minor doesnt
[09:05] <ogra_> (unless its firefox indeed :) )
[09:05]  * xnox doesn't do firefox =)
[09:06]  * xnox 's messaging menu.... is well.... small
[09:07] <seb128> xnox, how small?
[09:09] <xnox> seb128: it's usually ~ twice as long. But I'm confused what's missing
[09:09] <seb128> xnox, things that didn't get ported to the new protocol include: evolution pidgin liferea unity-webapp
[09:11] <xnox> seb128: for some reason empathy is there & thunderbird is taking less space. I have pleanty of unread folders, but it's not showing them. Xchat not ported either?
[09:12] <seb128> xnox, xchat is ported
[09:12]  * xnox doesn't use empathy nor launches it
[09:12] <seb128> did you upgrade xchat-indicator and restart xchat since?
[09:12] <seb128> xnox, tb should work ... is it listed at all?
[09:12] <xnox> yeah.
[09:13] <xnox> everything is listed, just taking less space. & empathy appeared althought it shouldn't be there
[09:13] <seb128> xnox, maybe sure you don't have an old messaging extension in .thunderbird hijacking the system one
[09:20] <chrisccoulson> anyone with either a lucid, oneiric or precise install wants to pick a build from https://launchpad.net/~mozillateam/+archive/firefox-next to check it works before i turn publishing back on? :)
[09:22] <seb128> chrisccoulson, what sort of testing do you want?
[09:22] <seb128> just "it starts, my awesome bar content is still there"?
[09:22] <chrisccoulson> seb128, literally just to make sure that it's not completely broken :)
[09:22] <chrisccoulson> yeah, pretty much
[09:23] <seb128> can do that
[09:23] <chrisccoulson> cool, thanks :)
[09:23] <seb128> yw
[09:39] <chrisccoulson> hmmm, i just replaced the batteries in my mouse because the cursor has been stuttering all morning, and i thought they were discharged
[09:39] <chrisccoulson> but, no improvement
[09:39] <chrisccoulson> and it seems that compiz and xorg are happily chewing away at my CPU
[09:39] <ogra_> change the batteries in your computer :)
[09:40] <chrisccoulson> heh
[09:54]  * xnox can't see mouse pointer in the VM =/
[09:58] <pitti> xnox: try with -vga vmware ?
[10:00] <xnox> pitti: KVM/VirtManager?
[10:00] <pitti> I don't know virt-manager, I always run kvm from the command line
[10:00] <pitti> xnox: with either -vga std or -vga vmware I get the same effect
[10:00] <xnox> ok.
[10:00] <xnox> on the next run ;-)
[10:10] <seb128> chrisccoulson, works fine on precise, got a running firefox 16 with my startage, awesome bar content, bookmarks, etc
[10:10] <chrisccoulson> seb128, excellent, thanks!
[10:12] <seb128> chrisccoulson, yw
[10:25] <Chipaca> o/
[10:27]  * Chipaca was about to complain, but an update related to the complaint just came in, so is retesting... :)
[10:27]  * Chipaca hates only talking in here when things break
[10:29] <seb128> Chipaca, hey
[10:29] <seb128> Chipaca, what is the issue?
[10:30] <Chipaca> seb128: hey yourself! :)
[10:30] <Chipaca> seb128: mousepad scroll stopped working
[10:30] <seb128> oh, that's something for #ubuntu-x ... if somebody broke it, it's them ;-)
[10:31] <Chipaca> seb128: just got an updated kernel and an updated libsyndaemon, so am going to reboot
[10:31] <Chipaca> seb128: I am never sure how the pie is cut wrt desktop vs x vs kernel
[10:31] <Chipaca> seb128: thanks :)
[10:31] <seb128> yw
[10:31] <seb128> could be kernel as well yes ;-)
[10:31] <xnox> somebody reported scroll wheel stopped working in VirtualBox.... against ubiquity
[10:32] <dpm> hi pitti, seb128, I've finally come round to generating the first Q language pack, but it fails with an error: http://pastebin.ubuntu.com/1175572/ - this seems similar to what happened when I was building the 12.04.1 langpacks: langpack-o-matic tries to download static translations (docs) from LP through the API, and LP is blocking that (too many requests). Could someone from the desktop team give me a hand with that?
[10:32] <dpm> let me ask the LP folks about it too
[10:32] <pitti> gzip: stdin: not in gzip format
[10:32] <pitti> really?
[10:33] <pitti> dpm: I didn't see "too many requests" before; is that new?
[10:33] <pitti> but then again, LP times out all the time since the DC migration, so that is a new error
[10:34] <dpm> pitti, yeah, aparently that was introduced recently. They made another change when I spoke to them about langpack-o-matic failing, so that I could run it for 12.04.1, which it did. But now this seems quite similar to what happened back then
[10:34] <chrisccoulson> Chipaca, do you mean that edge-scrolling is broken for you?
[10:35] <Chipaca> chrisccoulson: i do
[10:35] <chrisccoulson> Chipaca, ah, you're not alone (bug 1041594) :)
[10:35] <ubot2`> Launchpad bug 1041594 in linux "Edge scrolling on touchpad broken since the upgrade to 3.5.0-11" [Medium,Incomplete] https://launchpad.net/bugs/1041594
[10:35] <pitti> dpm: hm, if we can't download the static tarballs, I'm not sure how to build langpacks; did they say something about the nature of that error?
[10:36] <pitti> dpm: do they have a new rate limit for this or so?
[10:36] <dpm> pitti, about to ask them, I was looking for some context in my xchat logs from last time I spoke to the lp team
[10:39] <seb128> chrisccoulson, I like how any kernel bug reported is immediatly set to incomplete...NOT
[10:39] <chrisccoulson> heh
[10:39] <seb128> they try their best to make sure you don't report bugs again...
[10:41] <chrisccoulson> yeah, reporting kernel bugs can be a frustrating experience
[10:41] <chrisccoulson> but then, i imagine that reporting firefox bugs can be as well. especially when i insist that people read https://wiki.ubuntu.com/MozillaTeam/Bugs ;)
[10:43] <seb128> chrisccoulson, you both hate your users :p
[10:44] <seb128> chrisccoulson, I wouldn't manage to fully read that wikipage without falling asleep midway I think
[10:44] <seb128> I should bookmark it as an evening read :p
[10:44] <chrisccoulson> heh
[10:45] <chrisccoulson> you can sort-of get the idea of how to report a bug by looking at the contents on the right-hand side
[10:45]  * seb128 likes to "doesn't work, please help, kthxby" bugs :p
[10:45] <seb128> +report
[10:45] <chrisccoulson> eg, "Use Apport", "Try running in safe mode", "Be specific" etc :)
[10:45] <seb128> chrisccoulson, but yeah, dealing with high number of reports is tricky :-(
[10:46] <Chipaca> chrisccoulson: tested 3.6.0-030600rc3.201208221735. Bug has been fixed there.
[10:46] <Chipaca> chrisccoulson: (have updated the bug with the exact same comment. Retagged, also)
[10:47] <dpm> pitti, anyway, I asked on #launchpad-dev a while ago, waiting for an answer
[10:47] <pitti> dpm: thanks
[10:47] <Chipaca> seb128: chrisccoulson: I love that it's fairly quickly responded to with usually quite good and clear (and simple) instructions on how to progress
[10:48] <Chipaca> seb128: chrisccoulson: especially if I have to choose between that and the kind of response bug #1021661 has gotten
[10:48] <ubot2`> Launchpad bug 1021661 in bamf "emacs window not picked up on startup" [Undecided,New] https://launchpad.net/bugs/1021661
[10:48] <seb128> Chipaca, yeah, it's just annoying that you have to fight with a bot doing "is it fixed yet for you?" -> incomplete at each kernel upload
[10:48] <seb128> Chipaca, I like better the "no reply" way personally
[10:49] <seb128> Chipaca, at least they don't insist on putting the bug incomplete and getting it closed without having an human reading it
[10:50] <Chipaca> seb128: the automated response is usually empowering (granted it can get long, like the panel bug i had that wasn't fixed for a whole release of kernel updates). The no-reply makes me feel powerless, frustrated, and ultimately unhappy about using the product
[10:51] <seb128> Chipaca, I guess different people react differently ;-)
[10:51] <seb128> Chipaca, I find insulting to put my bug to incomplete when nobody put the effort to read it
[10:51] <seb128> Chipaca, I had bug where it was clearly an issue that didn't need testing with a new version of anything the automated replied commented
[10:51] <Chipaca> that bit might be down to attitude. I assume all my bugreports are quite incomplete :)
[10:52] <seb128> Chipaca, well I had example where I had specific hints and questions for the other side
[10:52] <seb128> Chipaca, which got granted with "let's give an automated reply which has nothing to do with what you were asking"
[10:52] <seb128> granted->welcomed
[10:53] <Chipaca> false cousins, there
[10:53] <seb128> then I had to fight for 6 months reopening the bug after each kernel upload saying "that's still something I wanted to discuss, not something to test"
[10:53] <seb128> Chipaca, yeah ;-)
[10:58] <dpm> pitti, while investigating the langpack issue, here's some context on what happened last time if you're interested: http://pastebin.ubuntu.com/1175613/
[11:01] <pitti> dpm: hm, but from your recent log it seems that getPackageUploads() already succeeded? it already starts downloading the tarballs, after all?
[11:02] <dpm> pitti, yeah, and didn't get a LP oops this time around. I'm just guessing and seeing if someone in LP can throw some light on it
[11:02] <pitti> dpm: "fetching tarballs..." that comes from create_static_tarballs(), which is called after all tarball URLs have been fetched from LP
[11:02] <pitti> and I don't see an LP error
[11:03] <pitti> gzip: stdin: not in gzip format
[11:03] <pitti> tar: Child returned status 1
[11:03] <pitti> this rather looks like a broken tarball
[11:03] <pitti> $ wget -O- https://launchpad.net/ubuntu/quantal/+upload/4494487/+files/gnome-orca_3.7.0.90-0ubuntu1_static_translations.tar.gz | tar tz
[11:03] <pitti> that works, so I don't think it's something specifically broken to that tarball
[11:04] <dpm> pitti, ah, it seems the run started at 10:00 UTC, which is pretty close to the LP database disconnect
[11:04] <pitti> dpm: My suspicion is that the urlretrieve() to that URL got back an error .html page
[11:04] <pitti> so trying it again has a pretty high chance of working, AFAICS
[11:04]  * dpm restarts
[11:05] <dpm> err *retries
[11:05] <pitti> don't restart yourself :)
[11:05] <pitti> it took some 30 years to get you so far!
[11:06] <dpm> :-)
[11:07] <dpm> yeah, with lots of trial and error :)
[11:21] <xnox> seb128: hmmm... on 800 or less screens launcher should really hide, otherwise it's not usable.
[11:23] <Chipaca> xnox: doesn't it?
[11:24] <xnox> Chipaca: just now in a VM I had to change the settings in the appearance.
[11:24] <xnox> Chipaca: it's ok for the installer~ish.
[11:37] <seb128> xnox, what is not usable?
[11:38] <xnox> seb128: ubiquity =) (me develops ubiquity, loves ubiquity, and cares only about ubiquity)
[11:38] <xnox> seb128: from try ubuntu session, no way to click continue =) and the screen is chopped off to the right and bottom. It's ok in the "install-only" mode.
[11:39] <xnox> as there is no launcher there.
[11:39] <xnox> i guess wait for bugs, then worry about it now.
[11:40] <seb128> xnox, ubiquity is bloated if it doesn't fit on 800 ;-)
[11:41] <seb128> but I guess hidding the launcher on small screens where you need the space could make sense, that would need to go through design though
[11:45] <ogra_> seb128, the point is that it fits ... it just doesnt once there are any desktop elements
[11:45] <ogra_> xnox, just make casper detect the screen size or so and make it run onyl-ubiquity if the space isnt sufficient
[11:46] <seb128> ogra_, well, we never had no desktop element on the liveCD
[11:46] <ogra_> seb128, we doo, all arm images run with only-ubiquity set
[11:47] <ogra_> seb128, and i think if we know that it wont fit, the image should be clever enough to suppress the desktop altogether ...
[11:48] <ogra_> (not your prob indeed :) )
[11:48] <seb128> ogra_, what I'm saying that "you have no desktop chrome" is something which was never true on the live system in desktop mode
[11:48] <seb128> we had always had panels on top and bottom
[11:49] <seb128> ubiquity should start itself in fullscreen mode if that's the intent
[11:52] <ogra_> thats what i'm saying :)
[11:59] <xnox> seb128: fullscreen is not the intent (ugly on normal & large screens), does make sense on tiny screens. But it's a "window manager" problem ;-)
[12:18] <ogra_> xnox, there is surely no prob to read the EDID of your monitor to find out if its capable of more than 800x600 ... if not just start ubiquity-dm instead of a desktop session
[12:42] <ogra_> heh, todays panda image is "intresting" ... GLES enabled drivers but no GLES enabled desktop ... it still works in a quite funny way
[12:43] <seb128> ogra_, hopefully Laney acks compiz GLES, he had questions on the FFe bug :p
[12:43] <seb128> otherwise no arm desktop for beta1
[12:43] <ogra_> eek
[12:43] <ogra_> Laney, stop that !
[12:43] <ogra_> :)
[12:45] <Laney> :P
[12:46] <Laney> ogra_: so how was it running on your panda?
[12:46] <ogra_> Laney, better than unity-2d
[12:46] <ogra_> there are some cursor flickering issues ...
[12:46] <Laney> yeah I looked at the bug list
[12:46] <ogra_> but no matter how it runs, getting it in is our only opportunity to have ubuntu-desktop on arm
[12:47] <ogra_> which is a mgmt requirement, so if its not suitable, it needs fixing, it *has* to go in this cycle
[12:47] <Laney> can we get the most important bugs milestoned?
[12:47] <ogra_> we should get them all milestoned (well, everything above Low at least)
[12:47] <ogra_> and unmilestone if needed
[12:49] <ogra_> though, looking at that list, all nvidia and nouveau ones are not valid (GLES wotn be enabled on x86)
[12:50] <ogra_> and i'm also pretty sure BUILD_GLES isnt intresting for us anymore
[12:57] <ogra_> ogra@panda:~$ ls /var/crash/
[12:57] <ogra_> _usr_bin_telepathy-indicator.1000.crash  _usr_lib_indicator-datetime_indicator-datetime-service.1000.crash  _usr_share_apport_apport-gtk.1000.crash  _usr_share_software-center_update-software-center.0.crash
[12:57] <Laney> seb128: approved
[12:57] <ogra_> wow, intresting, i would have expected to see at least one compiz crash in there
[12:57]  * ogra_ hugs Laney 
[12:57] <seb128> Laney, thanks
[12:58] <ogra_> Laney, you just ended a two year ongoing oddysey for me :)
[12:59] <Laney> heh
[12:59]  * Laney sends ogra_ off to run a bar by the sea
[12:59] <ogra_> haha
[13:00] <Laney> seb128: for unity, is this the last FFe we're anticipating?
[13:00] <seb128> Laney, no
[13:00] <seb128> Laney, but for beta1 yes
[13:01] <seb128> Laney, they still want to land a feature to disable,enable workspace apparently, that can be argued over after beta1, also support for xim input methods
[13:01] <seb128> Laney, why?
[13:03] <Laney> seb128: just trying to get a handle on where we're at
[13:03] <Laney> I have this feeling that the feature freeze process doesn't work so well for parts of our platform
[13:03] <seb128> Laney, imho we need to land that and we will have most of the work landed, other stuff are mostly details
[13:04] <seb128> Laney, I'm open to discuss improvements to the process (maybe at UDS), what do you think doesn't work there?
[13:05] <Laney> We always end up getting things that "need" exceptions, which are known quite far in advance
[13:05] <Laney> I imagine some kind of conversation around freeze time where we ack/nack features as a whole
[13:06] <seb128> isn't that what we have at this point?
[13:06] <Laney> like it's not really an option to nack unity now really
[13:06] <seb128> you are saying it's too late for the conversation?
[13:07] <seb128> no, but there is no solution to that problem, out of unity team to be better organized and land their stuff on a regular basis
[13:08] <Laney> but there's no incentive to do that if it's going to get in anyway
[13:08] <Laney> I think I will propose a UDS topic about it
[13:09] <seb128> I don't understand what you suggest changing
[13:09] <seb128> they are things Ubuntu has little control on
[13:09] <Laney> it's pointless filing freeze exceptions that we have to accept anyway
[13:09] <seb128> it's like firefox, we had to take new versions as SRUs
[13:09] <Laney> so we might as well do something about it to not waste time
[13:09] <seb128> we don't "have to", we could state we stay on the precise version
[13:10] <chrisccoulson> isn't this really a side effect of that fact that we try to mix a time-based release process with a feature-based one?
[13:10] <chrisccoulson> ie, if we had a truly time-based release, we'd just nack all features after a certain cut-off date, and there'd be no such thing as a FFe
[13:11] <chrisccoulson> a bit like mozilla's release process ;)
[13:11] <chrisccoulson> (ie, if it doesn't make the 6 week cut-off - tough luck)
[13:11] <seb128> well, where we are aiming at is a rolling release
[13:11] <seb128> that's the 6 month cycle screwing us
[13:11] <seb128> we should just land features are they get ready
[13:12] <seb128> the issue is that 6 months is a long time in that industry
[13:12] <seb128> so you get quite some insensitive to have stuff 90% done landing now and not delayed by 6 months
[13:13] <chrisccoulson> yeah, i agree
[13:13] <Laney> it does say something to me if even our own upstreams aren't sticking to our release schedule
[13:14] <seb128> they try
[13:14] <ogra_> Laney, sounds like you want the old general freeze exception for desktop stuff back we had in gnome 2.x days
[13:14] <Laney> I don't really know what I want
[13:14] <Laney> someone wiser than me to decide :-)
[13:14] <chrisccoulson> i know what i want
[13:15] <chrisccoulson> coffee!
[13:15] <seb128> hum, and cake!
[13:15] <Laney> aaaaaaaanyway
[13:15] <Laney> do you want to land this unity for b1?
[13:17] <Laney> there we go
[13:28] <chrisccoulson> cool, bt have confirmed there is a fault on my phone line :)
[13:28] <chrisccoulson> now, lets hope they fix it!
[13:39] <mterry> tedg, there is a question for you in https://bugs.launchpad.net/bugs/1039636 about the PAM config
[13:39] <ubot2`> Ubuntu bug 1039636 in lightdm-remote-session-freerdp "[MIR] lightdm-remote-session-freerdp" [Undecided,In progress]
[13:40] <tedg> mterry, Thanks, just getting to mail :-)
[13:40] <tedg> mterry, I will respond
[14:09] <chrisccoulson> sigh @ bug 1043831
[14:09] <ubot2`> Launchpad bug 1043831 in firefox "quantal 3.5.0-13-generic firefox 15.0 crash" [Undecided,New] https://launchpad.net/bugs/1043831
[14:09] <chrisccoulson> why do people think that these types of reports are useful :/
[14:10] <chrisccoulson> he even declined submitting the crash report
[14:56] <veric> can anyone help me with vid issue : at the moument vids play only on youtube
[14:56] <ogra_> veric, support is in #ubuntu
[14:58] <veric> yea i know they sugested someone here in desktop might have more experance for desktop 12.04
[15:01] <seb128> veric, sorry but if we started doing user support, others would come as well to get their problem looked at we would soon be doing that full time and not get any of the things we need to get worked done
[15:03] <ogra_> you could just make double shifts a default :)
[15:03] <ogra_> (or since you all already work double shifts, make it double double shifts ;) )
[15:57] <pitti> bonsoir mes amis
[16:20] <xnox> micahg: well if you get the timezones right there is about 51 hours available in a given calendar day. One needs multiple slaves in different timezones & efficient hand-overs.
[16:22] <micahg> xnox: the problem is each unit is limited to a 24 hour day
[16:23] <xnox> micahg: true and as a collection they suffer from split brain syndrome
[16:42] <cyphermox> Laney: can you accept FFEs?
[17:29] <mterry> cyphermox, I'm tracking the progress of the various remote-login stuff.  Do you think you'll be able to get to the NM_APPLET_HIDE_POLICY_ITEMS merge today?  https://code.launchpad.net/~bikini-atoll-squad/network-manager-applet/unity-greeter/+merge/121899
[17:30] <cyphermox> yes, it will land today
[17:30] <cyphermox> in a few minutes actually, just finishing up indicator-sync first
[17:30] <mterry> sweet, thanks!
[17:30] <mterry> yeah, i've been wanting to play with the sync indicator
[17:39] <seb128> jbicha, hey
[17:43] <jbicha> seb128: hi
[17:43] <seb128> jbicha, can you join #gnome-hackers?
[17:46] <jbicha> we're not bothering with making a nautilus-3.6 package for quantal, are we?
[17:54] <seb128> jbicha, I would recommend people to just use the ppa for that
[18:20] <mhr3> seb128, btw here's the ffe https://bugs.launchpad.net/unity/+bug/1043915, do i need to subscribe the release team or someone?
[18:20] <ubot2`> Ubuntu bug 1043915 in unity "FFe: Home lens ordering" [Undecided,New]
[18:26] <mterry> mhr3, yeah, subscribe ubuntu-release
[18:26] <mhr3> mterry, k, thx
[18:27] <mterry> mhr3, also, I'd add an ubuntu task there
[18:28] <mhr3> great
[18:40] <kenvandine> davidcalle, hey, i have a question about the photos lens update
[18:43] <seb128> mhr3, what mterry said, it would be good maybe to add a bit more details on the logic change, what will be on top and why
[19:00] <mterry> jbicha, you got featured in slashdot  :)
[19:01] <cyphermox> mterry: nm-applet is in; I'm going for a very very late lunch now :)
[19:01] <cyphermox> bbl
[19:01]  * mterry hugs cyphermox
[19:03] <mterry> kenvandine, looks like photo-lens is headed for more paperwork to approve the python3 port of a module
[19:03] <kenvandine> which module?
[19:03] <mterry> kenvandine, or heck, at this point a FFe too I suppose
[19:03] <mterry> kenvandine, the MIR comments indicate that security isn't happy with the embedded oauth2 module
[19:04] <kenvandine> oh that
[19:04] <kenvandine> grr
[19:04] <mterry> kenvandine, you know...
[19:04] <kenvandine> davidcalle, ^^
[19:04] <mterry> kenvandine, the python3 issues were a release goal and thus MIR team helped out by keeping python2 from entering.  But maybe we can poke barry about that now that we know we woon't make it
[19:05] <mterry> kenvandine, my point being maybe we could revert to python2...?
[19:05] <mterry> kenvandine, but better long term to just port oauth2
[19:06] <kenvandine> it won't make it
[19:06] <kenvandine> mterry, i just talked to barry about that yesterday
[19:06] <mterry> kenvandine, you mean python3 only?  yeah, defs not
[19:07] <mterry> kenvandine, but it's a separate question of whether we're OK with making things worse for us next time
[19:07] <mterry> kenvandine, here it'd be a matter of two FFes (one for python3 oauth, one for lens) vs one (just a python2 lens)
[19:07] <kenvandine> i see
[19:07] <kenvandine> either way it has to happen in time for 13.04
[19:08] <kenvandine> and the port to py3 is done for the lens
[19:08] <mterry> kenvandine, you're talking about python3 now?
[19:09] <mterry> kenvandine, an un-embedded oauth2 (regardless of python2 or 3) will also require another MIR
[19:09] <mterry> kenvandine, how bad do you want the photo lens?  :)
[19:10] <davidcalle> mterry, there will still be Py2 packages on the CD at release time?
[19:10] <kenvandine> davidcalle, yes
[19:10] <kenvandine> we didn't quite make that goal
[19:11] <kenvandine> mterry, it isn't me that wants it :)
[19:11] <kenvandine> :-D
[19:13] <seb128> kenvandine, is there anything that block landing a python3 version of that package?
[19:14] <kenvandine> the embedded oauth2
[19:15] <seb128> kenvandine, yeah, that's my question, is there anything blocking doing a python3-oauth2 from python-oauth?
[19:15] <seb128> kenvandine, like, why do we need a copy?
[19:16] <seb128> kenvandine, rather than solving the issue at the right place
[19:17] <kenvandine> someone needs to do it
[19:18] <seb128> kenvandine, look around you, who can you see? :-p
[19:19] <kenvandine> i can't see myself :)
[19:20] <mterry> seb128, kenvandine: well, python-oauth2 is also in universe.  Needs a MIR too then
[19:20] <seb128> kenvandine, ahah
[19:20] <mterry> seb128, I've asked jdstrand whether he prefers oauthlib or oauth2.  Curious on that answer before I go the MIR route
[19:21] <mterry> (since oauthlib is in main already)
[19:21] <seb128> mterry, ok
[19:46] <jdstrand> mterry: fyi, I responded
[19:47] <mterry> jdstrand, I don't know what oauthlib's support for oauth2 is really
[19:47] <mterry> jdstrand, it's latest release (unpackaged) claims to support it
[19:48] <mterry> But that was pretty recent
[19:48] <jdstrand> mterry: it may need to be ported too...
[19:49] <mterry> jdstrand, yeah it needs a python3 port
[19:49] <mterry> jdstrand, so oauth2 is much easier for me.  But I didn't know how much you'd hate a second oauth implementation
[19:49] <mterry> I'm not thrilled, but it would be easier anyway
[19:50] <jdstrand> well 'best' would be one package in main that everything uses, in this case, that sounds like extra work (porting, packaging and updating unity-lens-photos) as opposed to just packaging work for python-oauth2
[19:51] <jdstrand> no, it isn't thrilling, but I think it is ok. maybe we could look at using oauthlib after it gets py3 support
[19:53] <mterry> jdstrand, is python-oauth2 OK for you in main from a security point?  (like, if I file a MIR, do you want another pass at it?)
[19:53] <mterry> jdstrand, aside from issues of having 2 of them.  Like, is the code itself OK
[19:54] <jdstrand> mterry: no, I don't need to look at it again. I'm comfortable with it so long as the testsuite is worked out for both py2 and py3. I don't know that it will be possible to make it run on the buildd as it seemed to need the network
[19:54] <mterry> :-/
[19:54] <jdstrand> but having the testsuite work is important
[19:54] <jdstrand> mterry: I didn't poke super hard it it
[20:00] <mterry> cyphermox, you sure that nm-applet branch got pushed?
[20:00] <cyphermox> ah, yes?
[20:01] <cyphermox> mterry: https://launchpad.net/ubuntu/+source/network-manager-applet/0.9.6.2-0ubuntu2
[20:02] <mterry> cyphermox, ah, I'm an idiot.  I was checking the non -applet package.  And the merge request didn't show merged status, so I figured something went wrong
[20:05] <cyphermox> oh, yeah, I guess I should push this
[20:53] <mterry> sebdebug, ?
[20:53] <mterry> sebdebug, I got a package coming through NEW soon if you could
[20:54] <mterry> sebdebug, new wallpapers
[21:01] <seb128> mterry, sure can, sorry I was debugging xchat-indicator yesterday on that machine and I forgot to reset my nickname :p
[21:01] <mterry> seb128, ubuntu-wallpapers-quantal to be precise.  (haha)
[21:01] <mterry> never gets old
[21:01] <seb128> ;-)
[21:02] <seb128> mterry, wait, I need to stop laughing first :p
[21:02] <mterry> "Ubuntu 12.10 delayed, developers too busy guffawing"
[21:02] <thumper> hi seb128
[21:02] <thumper> seb128: fun times?
[21:04] <bryce> heya thumper, any new discoveries with your misbehaving mouse?
[21:04] <thumper> bryce: not at this stage
[21:04] <thumper> bryce: been somewhat chaotic
[21:05] <seb128> thumper, hey, yeah, freeze weeks are always fun :p
[21:05] <thumper> bryce: wondering if the pulsing red light means low battery :)
[21:05] <bryce> thumper, :-)
[21:05] <seb128> mterry, you got lucky that we dropped the CD, that binary is 1MB over the precise one
[21:06] <mterry> seb128, yeah.  They loved more wallpapers than they promised (12 instead of 10) and went for higher quality versions than precise
[21:10] <seb128> mterry, NEWed, nice selection ;-p
[21:10] <seb128> ;-)
[21:10] <mterry> seb128, awesome, thanks
[21:10] <mterry> I picked well, I agree  :)
[21:10] <mterry> Phew, that's it for me for UIFreeze
[21:15] <seb128> mterry, maybe you could try to make the lock screen nicer, we could ask a UIF for it :p
[21:15]  * mterry shakes his fist at seb128
[21:15]  * seb128 can't believe we are at UIF again and the damn lock screen is still that grey rectangle
[21:15] <mterry> seb128, you have to learn to love it
[21:15] <seb128> seems so :-(
[21:15] <mterry> robert_ancell will make it real pretty in 13.04
[21:16] <seb128> or claim I stop carring about security
[21:16] <robert_ancell> real pretty hur hur
[21:16] <seb128> that's decided, I'm never locking my screen again
[21:16] <mterry> That's another solution, yeah  :)
[21:16]  * mterry waves at robert_ancell
[21:17] <seb128> I will blame one of you if somebody hack my laptop
[21:17] <seb128> ;-)
[21:17] <seb128> robert_ancell, good morning
[21:17] <robert_ancell> mterry, hey, just checking email now, so we've got lightdm with remote sessions disabled and u-g waiting for ffe?
[21:17] <mterry> robert_ancell, I pushed out lightdm and unity-greeter releases, the NM applet is enabled, remote login is disabled
[21:18] <mterry> robert_ancell, blocked on security review for new packages needed there
[21:18] <robert_ancell> ok
[21:18] <mterry> robert_ancell, but to enable it, a simple matter of dropping patches
[21:19] <robert_ancell> seb128, did you have a look at the gexiv2 package?
[21:22] <seb128> robert_ancell, just looking
[21:22] <seb128> had a look from the web ui earlier but I don't understand why they are pyhon-* binaries
[21:27] <robert_ancell> seb128, yeah, I'm not sure about those. They have a .py file to provide a more pythonic interface to the GIR I think (though I don't know why that's needed). I guess they shouldn't go into the -dev or gir1.2- packages because you may not be using python
[21:29] <seb128> robert_ancell, they should be in the gir
[21:29] <robert_ancell> seb128, ok
[21:29] <robert_ancell> seb128, how do you know?
[21:30] <seb128> robert_ancell,
[21:30] <seb128> $ dpkg -S /usr/lib/python2.7/dist-packages/gi/overrides
[21:30] <seb128> gedit, gir1.2-unity-5.0, gir1.2-dee-1.0, gir1.2-dee-0.5, python-gi: /usr/lib/python2.7/dist-packages/gi/overrides
[21:30] <robert_ancell> ok
[21:30] <seb128> robert_ancell, plenty of examples doing that :p
[21:30] <seb128> robert_ancell, I think ken and pitti discussed that before, I trust dee to be an example done right
[21:31] <seb128> robert_ancell, so yeah, drop the 2 python binaries and put those in the gir...we need a FFe, do you want me to  update the bug for that?
[21:32] <robert_ancell> seb128, sure
[21:33] <seb128> robert_ancell, you need to dh --with gir to get gir:Depends to work
[21:34] <robert_ancell> seb128, oh dee doesn't do that. It has dh_girepository in override_dh_gencontrol. Is that the old method
[21:35] <seb128> robert_ancell, both work, but yeah, that pre-date the gir dh integration I guess
[21:35] <seb128> gobject-introspection: /usr/share/perl5/Debian/Debhelper/Sequence/gir.pm
[21:36] <robert_ancell> ech perl. I'm not reading that
[21:36] <seb128> ;-)
[21:38] <seb128> robert_ancell, you probably lack a build-depends on python-gi
[21:38] <seb128> robert_ancell, their Makefile does
[21:39] <seb128> PYTHON="import gi; print(gi._overridesdir)"
[21:39] <seb128> that will require it
[21:39] <robert_ancell> seb128, right
[21:39] <robert_ancell> annoying custom makefiles
[21:39] <seb128> indeed...
[21:40] <seb128> I checked it because ken got bitten by that recently, he had an override failing to install because of a missing bd on python-gi
[21:41] <seb128> robert_ancell, oh, gobject-introspection in build-depends as well
[21:41] <seb128> robert_ancell, otherwise looks fine
[21:41] <robert_ancell> seb128, yeah, I got that one
[21:41] <robert_ancell> seb128, dh complains, even though libgirepository-dev depends on it
[21:42] <robert_ancell> it really annoys me how we have both in the build depends
[21:42] <seb128> hum, it's a good point
[21:42] <seb128> I guess dh wants direct depends on stuff it uses
[21:43] <seb128> it's usually good practice to not rely on others to bring what you need...
[21:54] <robru> seb128, robert_ancell : When I added python support to gexiv2 library, I had to add that exact same kind of thing to the Makefile... do you know of any way around that?
[21:55] <robert_ancell> robru, the 'import gi' checks?
[21:55] <robert_ancell> and no, don't know another way
[21:55] <robru> yeah, exactly.
[21:55] <robru> robert_ancell, you said you were annoyed, so I was hoping you'd offer a better way around that. some standard way of querying for the overrides dir without bringing in a build-dep on python.
[21:56] <robru> in fact the yorba guys were really bothered by that, too.
[21:56] <robert_ancell> robru, nah, I suspect it's just the usual no-one's really thought about a clean way of doing it yet
[21:56] <robru> fair enough.