[01:48] <AfC> Does gnome-shell not work with lightdm? I've been running gdm, so hadn't noticed. What's the interface that it's looking for?
[02:01] <robru> AfC, well, I am currently running g-s with lightdm on ubuntu no problems, but the newest g-s (3.5.5 I think?) landed a tremendous amount of changes where they start using gdm to handle their screen lock. Presumably this is to allow people to switch users when the screen is locked, without having to duplicate a huge amount of user-switching code from gdm in the screen locker. it's just unfortunate that GNOME are insisting on gdm
[02:01] <robru> instead of choosing something more universally interoperable like lightdm. IMHO GNOME and KDE and everything else should just adopt lightdm as standard.
[02:16] <AfC> robru:  "x should just adopt y" when y is years newer than x and x is a part of the X project doesn't really fly as a compelling argument for the X people.
[02:17] <AfC> robru: I do know the GNOME people are trying really hard to get the login screen and lock screen integrated; from a user experience perspective they are the same thing, but technically they are at opposite ends of the stack. Makes it tough
[02:18] <AfC> robru: I'm glad to see them being innovative, though; this one has been begging for a change for a long time
[02:18] <robru> AfC, hey man, GNOME and KDE managed to unify on DBus (dropping corba and dcop in the process), so one can hope that there might be other cases of unification going on on the desktop ;-)
[02:18] <AfC> robru: right: that was both sides consciously making a decision to work together in co-operation. That's different that an upstart coming along saying "I'm better, use me instead"
[02:19] <robru> AfC, so how do we convince them to consciously decide to work together?
[02:19] <robru> ;-)
[02:19] <AfC> robru: it may well be better, but that's besides the point.
[02:19] <robru> AfC, I'm not actually bothered which is better, I just like lightdm because it's not tied to any one system.
[02:20] <AfC> The Canonical engineers decided they wanted to do something that the GDM codebase couldn't support; the GDM developers have been doing what they do for a long time and have a reasonably good idea of how to set up the pre-conditions for the window manager to take over.
[02:20] <jbicha> AfC: as far as I know, all DMs used to work for any desktop environment so this is a change
[02:21] <jbicha> you could use kdm to log into gnome or any other combination
[02:21] <AfC> jbicha: I always thought that was silly; In Gentoo if I was running KDE I'd use kdm; if GNOME gdm. There are significant environment assumptions, and it was obvious the idea of supporting foreign desktops was unrealistic because the subsequent code would rely on those assumptions
[02:21] <AfC> [without realizing it]
[02:22] <jbicha> it's ridiculous to have to change your login manager just because you want to try a different desktop
[02:22] <AfC> {shrug} I have to reinstall the entire system if I want to try fedora. So not "rediculous" at all
[02:22] <micahg> AfC: that's what kvm/virtualbox are for...
[02:23] <AfC> jbicha: [not saying you're wrong or that it wouldn't be nice to have, just that in practice I've never observed zero coupling between dm and wm
[02:24]  * micahg has used xdm, lightdm, kdm, and gdm with various desktops in the past without issue
[02:24] <jbicha> AfC: the problem is that I have Unity installed and want to install gnome-shell; there's no easy way to make gnome-shell depend on a user actually using gdm as default
[02:25] <jbicha> we could hack lightdm to blacklist gnome-shell but that's still going to confuse people when it worked just fine in 12.04
[02:26] <jbicha> I think robert_ancell is right that ideally, gnome-shell should fallback if gdm (or a gdm-like dm) isn't being used
[02:56] <robru> HOW IS IT 10 PM? I have been working for 15 hours.
[03:00] <robru> g'night ;-)
[04:52] <thumper> does anyone else have a problem with skype on quantal?
[04:52] <thumper> I get a complete laptop lockup when using skype video
[04:52] <thumper> can't switch to a VT
[04:52] <thumper> nothing
[04:52] <thumper> hard reset needed
[05:04] <RAOF> thumper: Works for me. What video card?
[05:05] <thumper> Mobile Intel® GM45 Express Chipset
[05:07] <pitti> bonjour
[05:07] <pitti> smspillaz: I added some more concrete information to bug 1042041; seems I can reproduce this fairly reliably now with every startup
[05:07] <ubot2`> Launchpad bug 1042041 in compiz "1:0.9.8+bzr3319-0ubuntu1 regression: keeps setting gsettings keys to wrong values" [High,Confirmed] https://launchpad.net/bugs/1042041
[05:08] <RAOF> thumper: Huh. Works with my sandybridge. Fun. I don't suppose it generates an apport log?
[05:09] <thumper> RAOF: nope
[05:09] <RAOF> Of course not. :(
[06:35] <sil2100> Hello
[07:08] <chrisccoulson> good morning everyone
[07:29] <Mirv> ogra_: there would be one ARM build of compiz to try out: http://people.canonical.com/~tjyrinki/compiz/compiz-0.9.8.0-armhf.tar
[07:35] <chrisccoulson> yay, rain!
[08:00] <seb128> hey desktopers
[08:02] <smspillaz> pitti: thanks, I'll get on ot it soon
[08:09] <seb128> hey smspillaz, pitti
[08:12] <chrisccoulson> hi seb128, how are you?
[08:14] <seb128> chrisccoulson, hey, still no rain? ;-)
[08:14] <seb128> chrisccoulson, I'm good thanks, how are you?
[08:14] <chrisccoulson> seb128, yeah, it's raining today. but my 3G is working too ;)
[08:14] <seb128> hehe
[08:14] <seb128> does the phone quality goes down with the rain as well?
[08:15] <chrisccoulson> seb128, it's difficult to tell. we've got a cordless handset which does noise reduction
[08:15] <seb128> chrisccoulson, nice to see firefox 15 already in precise-securityr!
[08:15] <chrisccoulson> but there is a bit of noise when it rains
[08:15] <seb128> k
[08:15] <chrisccoulson> i need to go out and get myself a cheap corded handset at some point
[08:15] <chrisccoulson> i'm not even sure you can buy them anymore, can you? ;)
[08:28] <pitti> seems it started with the last update, debian/patches/git_scale_click.patch
[08:29] <seb128> weird, that's a trivial patch in the slider callback
[08:29]  * larsu is afraid this channel will be French-only soon
[08:29] <seb128> larsu, that's the plan, duolingo your french back! ;-)
[08:29] <thumper> he folks, who is our intel graphics driver person?
[08:29] <pitti> larsu: tu vas apprendre le français :)
[08:29] <seb128> thumper, not an assigned person, RAOF is probably eod at this point, try tjaalton
[08:29] <larsu> pitti, are you sure that's the problem? I get "invalid cast from `GtkImage' to `U1MusicStore'" right before the rhythmbox segv
[08:29] <seb128> thumper, or #ubuntu-x
[08:29] <pitti> larsu: no, I'm not
[08:29] <pitti> larsu: currently fixing the apport hook, then I can report it
[08:30] <seb128> larsu, pitti: I'm pretty sure it's the u1-rb-store update from yesterday
[08:30] <larsu> pitti, cool, me too :)
[08:30] <seb128> pitti, try uninstalling the store?
[08:30] <pitti> seb128: sounds likely, yes
[08:30] <larsu> pitti, I'm not learning french on duolingo yet. Will be next, after I master Spanish. *cough*
[08:30]  * pitti purges unity-scope-musicstores along
[08:30] <seb128> larsu, you need to sort out your priorities!
[08:30] <pitti> seb128: c'est ça!
[08:31] <seb128> pitti, merci larsu
[08:32] <pitti> rb apport hook fix committed to bzr, FYI
[08:32] <seb128> pitti, what was the issue?
[08:32] <pitti> -            report.add_package_info("rhythmbox-ubuntuone-music-store")
[08:32] <pitti> +            report.add_package_info("rhythmbox-ubuntuone")
[08:32] <pitti> :)
[08:32] <larsu> haha
[08:51] <xnox> resurrected bug 691736
[08:51] <ubot2`> Launchpad bug 691736 in libindicate "Can not take screenshot while indicators are open" [Undecided,Confirmed] https://launchpad.net/bugs/691736
[08:51] <xnox> reproducible in precise & quantal
[08:52] <thumper> I hate it when people reopen fixed bugs
[08:52] <thumper> new ones are better :)
[08:52] <thumper> but that may just be me
[08:52] <seb128> xnox, it's a duplicate of an ancient ancient ancient bug
[08:53] <ritz> seb128, ping
[08:53] <thumper> seb128: not sub 100k?
[08:53] <seb128> ritz, hi
[08:53] <seb128> thumper, sub 11k :p
[08:53] <ritz> seb128 hi, wrt https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/734428 . Is it possible to push this for oneiric and precise ?
[08:53] <ubot2`> Ubuntu bug 734428 in df-libreoffice "[Upstream] Wrong automatic text color "dark grey" with black background (dup-of: 628105)" [Medium,Confirmed]
[08:53] <thumper> wow
[08:53] <ubot2`> Ubuntu bug 628105 in df-libreoffice "[Upstream] Text not black in LibreOffice" [Medium,Confirmed]
[08:53] <seb128> thumper, xnox: bug #10905
[08:53] <ubot2`> Launchpad bug 10905 in unity "Keyboard shortcuts, window management - Can't use any global keyboard shortcuts or hotkeys when applet/menu is open" [Undecided,Confirmed] https://launchpad.net/bugs/10905
[08:54] <xnox> seb128: omg =)
[08:54] <seb128> thumper, xnox: it's a xorg limitation
[08:54] <seb128> menus need to do grabs to work
[08:54] <thumper> that's stupid
[08:54] <seb128> which block keybindings
[08:55] <seb128> ritz, I doubt we will do any other oneiric libreoffice upload ... can you ask to Sweetshark for precise,quantal?
[08:55] <ritz> seb128, thanks, will do
[08:55] <ritz> Sweetshark, ^^^
[08:56] <seb128> ritz, he's our lo maintainer and the one who commited that patch upstream
[08:56] <ritz> hmmm,
[08:57] <ritz> sweet
[08:57] <seb128> ogra_, hey
[08:59] <seb128> ogra_, can you get https://launchpad.net/~unity-team/+archive/release/+files/compiz_0.9.8.0-0ubuntu1%7Etest2.dsc copied to your arm ppa? hopefully it restores armel gles builds
[09:04] <seb128> pitti, chrisccoulson, larsu, others: did you also get whoopsie errors about the photo lens today when using the dash?
[09:04] <seb128> do you have the photo lens installed? (I just realized we didn't seed it yet)
[09:04] <larsu> seb128, /me doesn't have a photo lens
[09:04] <pitti> no whoopsie report in /var/crash
[09:04] <seb128> ignore that question :p
[09:05] <seb128> nobody has it installed, that's probably why we didn't see lot of reports
[09:05] <seb128> thanks
[09:05] <pitti> seb128: je ne ai pas un lens de photos
[09:05] <pitti> seb128: should I install it?
[09:05] <Sweetshark> ritz: might get backported to quantal, but I am currently stuffed with work. as for precise: once it it in quantal and somebody (ricotz usually) does a backport.
[09:06] <pitti> seb128: "je n'ai pas ..", almost :)
[09:06] <ritz> hmmm
[09:06] <seb128> pitti, ;-)
[09:06] <pitti> seb128: can it search through tags?
[09:06] <seb128> pitti, no need to, it will be seeded soon, it's waiting on security review for the MIR
[09:09] <ricotz> Sweetshark, hi, i will try to get to it at some point, having 12.04.1 out makes it not that important to do lucid/natty/oneiric though
[09:09] <seb128> pitti, not at this point, davidcalle says he didn't find a python3 exif parser he can use
[09:09] <pitti> err, no exif?
[09:09] <pitti> that doesn't sound very useful
[09:10] <pitti> seb128: do lenses need to be written in python?
[09:10] <seb128> pitti, the lens does collect,browse your g+,picasa,facebook,etc photos
[09:10] <davidcalle> pitti, but tags and events. Exif is here for Flickr and Picasa.
[09:10] <seb128> pitti, no they don't, the files,app,etc are written in vala
[09:10] <seb128> pitti, it's up to the lens writer to pick the language
[09:11] <pitti> ah, so maybe vala and libgexiv2-dev might work?
[09:11] <pitti> merci
[09:11] <seb128> pitti, well, the photo lens is already written in python...
[09:12] <seb128> davidcalle, you should call to robru
[09:14] <seb128> davidcalle, he's into photos and works on a python geotagging app, he added introspection to gexiv2 (the lib used by shotwell for exiv) that landed upstream
[09:14] <pitti> nice!
[09:14] <seb128> davidcalle, I think you should be able to just use those bindings, we should have a look to make that land in quantal
[09:14] <davidcalle> seb128, ooh, that would be nice!
[09:14] <pitti> I was just searching for "gir exiv" and didn't find anything
[09:14] <seb128> pitti, https://github.com/robru/gexiv2
[09:16] <seb128> pitti, davidcalle: http://git.yorba.org/cgit.cgi/gexiv2/commit/?id=b8da1516e83f3e9200157277785c655b6815edf9
[09:16] <seb128> in fact
[09:16] <seb128> davidcalle, I will get you that in quantal so you can use it
[09:17] <davidcalle> seb128, that would be great, ty!
[09:17] <seb128> yw!
[09:55] <chrisccoulson> hmmm, going to attempt to switch back to my home connection again, now it's not raining ;)
[09:59] <xnox> did llvmpipe / compiz landed? The daily quantal image works really, really well in the VM!
[09:59] <xnox> or did KVM somehow gain 3D acceleration (very much doubt that)
[10:00] <pitti> xnox: compiz was fixed to avoid teh screen corruption under llvmpipe
[10:01] <xnox> ah awesome =)
[10:01] <pitti> xnox: well, "really well", it's rather slow
[10:01] <pitti> but at least it's usable
[10:01] <xnox> I always give my VMs 2048MB of RAM and it's faster than unity-2d for some things I do
[10:02] <xnox> e.g. dash responsiveness
[11:12] <ogra_> seb128, i copied it, but it still wants to only build for x86 machines ...
[11:12]  * ogra_ pulls the source to take a look
[11:13] <seb128> ogra_, do you know why? I'm sure I'm overlooking something stupid :-(
[11:13] <ogra_> no, but i'm pullinbg the package right now, let me take a look
[11:13] <seb128> ogra_, there is a bug in the .install Mirv was supposed to fix like 3 hours ago, not sure what's happening there
[11:14] <seb128> Mirv, still on that .install fix?
[11:14] <seb128> 3 -> 1
[11:14] <ogra_> seb128, well, looks more like the PPA doesnt understand the control file or so
[11:14] <ogra_> it doesnt even list any arm in the build attempts of the PPA UI
[11:15] <seb128> ogra_, is that a PaS stuff? or whatever is called the override that define archs for a source?
[11:15] <ogra_> shouldnt
[11:15] <ogra_> but who knows what went wrong during the DC move :)
[11:15] <seb128> do you have other sources building on arm?
[11:16] <seb128> or did you just get arm turned off for that ppa?
[11:17] <Mirv> seb128: wasn't that <1h ago ;) running a build to check that it builds with those plugins disabled, but how'd you handle the fact that they would still build on x86?
[11:17] <ogra_> hmm, quite a lot of Arch: all binaries in there :)
[11:17] <Mirv> ah 3->1
[11:18] <ogra_> compiz itself is arch:all ?
[11:18] <Mirv> ogra_: compiz is just a meta-package
[11:18] <ogra_> ah, k
[11:18] <ogra_> well, the "any" ones should be picked up ...
[11:19] <Mirv> so these would be the plugins not to try to install on arm: http://pastebin.ubuntu.com/1173645/
[11:20] <Mirv> and I'm running one such build atm
[11:23] <ogra_> seb128, so i see that there were arm builds for quantal in that PPA, but not actually after the DC move ... i'll bug IS
[11:39] <ogra_> seb128, yeah, was a PPA issue ... starting over now
[11:44] <seb128> ogra_, great
[11:44] <seb128> Mirv, yeah, sorry I though we figured out that issue earlier in the day :p
[11:44] <ogra_> hmm, but it seem to not be able to re-copy it
[11:44] <ogra_> sigh
[11:45] <seb128> ogra_, well, the .install is buggy anyway...
[11:45] <ogra_> if i had built it locally i would have been done now :/
[11:45] <seb128> ogra_, do you know how to do arch specific .installs?
[11:47] <ogra_> seb128, i think i didnt that in precise in compiz-plugins-main ... let me look
[11:47] <seb128> ogra_, thanks
[11:47] <ogra_> debian/compiz-plugins-main.install.armhf ... debian/compiz-plugins-main.install.armel
[11:48] <seb128> Mirv, ^
[11:48] <ogra_> just add an arch suffix
[11:48] <ogra_> dh_install should cope
[11:48] <seb128> ogra_, I guess that's used instead of the .install on those arches?
[11:48] <seb128> but the .install is still used otherwise?
[11:48]  * ogra_ checks the manpage ... its a while ago :)
[11:50] <ogra_> hmm
[11:50] <xnox> you could bump compat to 9, and make install file an executable which produces required output when run
[11:50] <xnox> then you have environment variables and you can do stuff like
[11:51] <xnox> find & grep -v out what you don't want on armel/armhf, but keep the rest
[11:51] <xnox> on all other arches
[11:51] <ogra_> well, the arch suffix works but i cant seem to find docs about it
[11:51] <xnox> well for me, it's the first time I hear about it.
[11:51] <xnox> somewhere in the "Black Magic" section of debhelper manpage?
[11:52] <seb128> xnox, the "easy" way is to list the common files in the .install and add a cp for the extra ones in the rules for !arm*
[11:52] <seb128> but that breaks things like dh_install --list-missing
[11:53] <xnox> yeah =/, or instead rm after dh_install
[11:53] <ogra_> seb128, well, given it will just cost us an extra upload to check and given that its unlikely to break x86, lets just do it and check
[11:54] <ogra_> looking at https://launchpadlibrarian.net/100425594/compiz-plugins-main_1%3A0.9.7.0~bzr19-0ubuntu8_1%3A0.9.7.0~bzr19-0ubuntu9.diff.gz the install.$arch files dont have any extra hacks in the build system
[11:55] <ogra_> so we'll see if .install is still used on arm arches
[11:55] <xnox> ogra_: yeah it does do that, see pkgfile function in /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm
[11:55] <ogra_> awesome
[11:55] <ogra_> seb128, so it shouldnt cause any probs
[11:56] <Laney> looks like that works for all debhelper files
[11:56] <xnox> no idea about compat levels though.... probably since beginning of time?
[11:56] <Laney> that is interesting to know!
[11:56] <Mirv> ogra_: that's totally new to me, nice if that works. I now put such a thing in one PPA, sources at http://people.canonical.com/~tjyrinki/compiz/compiz-arm-test4.tar
[11:56] <Laney> no compat checks there
[11:56] <xnox> yeah. Definately should be documented.
[11:56] <ogra_> Laney, but bad that its not documented, i dotn even know how i got to use it anymore :)
[11:56] <Laney> heh
[11:56] <Laney> file a joeyh bug
[11:57]  * xnox ponders if git blame says ogra_ committed that to debhelper
[11:57] <Laney> oh no, it is documented
[11:57] <xnox> where?!
[11:57] <Laney>        In some rare cases, you may want to have different versions of these files for different architectures or OSes. If files named
[11:57] <ogra_> "Launchpad encountered an internal error during the following operation: copying a package.  It was logged with id OOPS-fb7f4c65721e6b180a344c8e4be802ae.  Sorry for the inconvenience."
[11:57] <Laney> debhelper(7)
[11:57] <ubot2`> https://lp-oops.canonical.com/oops.py/?oopsid=fb7f4c65721e6b180a344c8e4be802ae
[11:57] <ogra_> lovely
[11:57] <Laney>        debian/package.foo.ARCH or debian/package.foo.OS exist, where ARCH and OS are the same as the output of "dpkg-architecture
[11:57] <Laney>        -qDEB_HOST_ARCH" / "dpkg-architecture -qDEB_HOST_ARCH_OS", then they will be used in preference to other, more general files.
[11:57] <ogra_> ah, but finally it builds
[11:57] <Mirv> seb128 / ogra_: or lp:~timo-jyrinki/compiz/gles_arm_install_fix
[11:58] <Mirv> let's see if it finishes
[11:58]  * xnox FTRTFM - Fail To Read The Fine Manual
[12:02] <Mirv> nice that the feature is generic, ie any file can be appended with .ARCH
[12:04] <ogra_> that same diff above also has code to add this support to quilt patches btw
[12:04] <ogra_> thats actually something non-std i hacked in
[12:21] <ogra_> Mirv, ping me once you uploaded it and i'll copy it over to the arm builder
[12:21] <ogra_> (looks good btw)
[12:32] <Mirv> ogra_: in ppa:unity-team/release again
[12:32] <Mirv> building on arm as well already
[12:34] <ogra_> uh, how ?
[12:34] <Mirv> I managed to do one build run with cut down .install that naturally failed on amd64/i386, but I got the following on ARM: dh_install: usr/share/cmake-2.8/Modules/FindOpenGLES2.cmake exists in debian/tmp but is not installed to anywhere
[12:34] <ogra_> oh, you mean locally ?
[12:34] <Mirv> ogra_: I've access to one PPA that has it
[12:34] <Mirv> but that should be covered by compiz-dev.install, so I'm puzzled
[12:34] <ogra_> oh, ok, could you just copy the resulting binaries into the unity ppa then ?
[12:34] <Mirv> ogra_: see above, still not there although got past the plugins
[12:35] <ogra_> i have a working qunatal GLES setup with the PPA in the souces and can just quickly test once its ready
[12:35] <ogra_> *quantal too
[12:36] <Mirv> I'm now running a build on a local arm machine as well, it's annoying one can't login to nearly-build sources at the PPA:s...
[12:36] <Mirv> (obvious, but annoying;)
[12:36] <seb128> Mirv, maybe the fact that there is a .armel you need one for each .install
[12:37] <seb128> Mirv, like trying to copy compiz-dev.install to compiz-dev.install.armel etc?
[12:37] <Mirv> seb128: ouch.. messy, but maybe has to be done then. would explain the issue.
[12:38] <seb128> that's a bit weird though, I would expect it just use the normal one if it doesn't find a specific for the arch
[12:38] <seb128> Laney, xnox: ^ what is your understanding?
[12:39] <Laney> yeah I think that is what happens
[12:39] <Laney> it's not surprising that fail-missing fails if you aren't installing all of the files
[12:39] <seb128> Laney, well I would assume that compiz-dev.install is used if there is no compiz-dev.install.armel
[12:39] <seb128> it's a bit stupid to have to dup all the .installs
[12:39] <Laney> yes
[12:39] <Laney> that's what I'm saying happens
[12:40] <seb128> hum?
[12:40] <Laney> but it doesn't install that file any more?
[12:40] <seb128> seems not from the issue Mirv described
[12:40] <Laney> usr/share/cmake-2.8/Modules/FindOpenGLES2.cmake this one
[12:40] <seb128> right
[12:40] <seb128> it's listed in compiz-dev.install
[12:40] <Laney> wouldn't it have been removed from compiz-dev.install to the arch specific one?
[12:40] <seb128> so why is dh_install --fail-missing stopping on it?
[12:41] <seb128> Laney, that's the diff: http://bazaar.launchpad.net/~timo-jyrinki/compiz/gles_arm_install_fix/revision/3283
[12:46] <Laney> one sec, X just restarted
[12:46] <Mirv> hmm, actually that build log I copy-pasted from was the one where I just cut away stuff from the compiz-gnome.install
[12:47] <Mirv> either way, I don't understand why that'd happen, but let's see if the test4 build has the same failure
[12:51] <seb128> Mirv, on what archs did test3 failed?
[12:55] <ogra_> it finished on the x86 arches at least
[12:59] <fginther> seb128, Hello, I have merge proposal ready for review for nux and unity in precise, a rename of libutouch-geis to libgeis. However, the renamed libgeis is still in the precise upload queue. Is there anything I can do proactively to get the MPs reviewed, or am I just blocked until the uploads make it into the archive?
[13:00] <seb128> fginther, hey, we should get the lib first in the archive I think ... do you have a bug open to track those changes with the ubuntu-release team subscribed? that will probably need to go through them
[13:01] <Mirv> seb128: the test3 I had failed on all, but on amd64/i386 obviously because I removed the plugins that those archs still had (I just wanted to test arm build first before this .ARCH proposal came)
[13:02] <seb128> Mirv, ok, where are testing now?
[13:03] <sabdfl> hiya
[13:03] <sabdfl> did you see the news on vmware rewriting bosh in go and redesigning it to be just like juju?
[13:03] <sabdfl> heh, ww
[13:04] <fginther> seb128, Yes, LP: #1037621 with the SRU team subscribed
[13:05] <seb128> sabdfl, hey, how are you?  I didn't read that yet, juju ftw! ;-)
[13:05] <seb128> fginther, looking
[13:06] <seb128> fginther, precise was frozen for some time due to 12.04.1 so it's not surprising that didn't get traction recently
[13:06] <seb128> fginther, try maybe mentioning it on #ubuntu-release?
[13:06] <fginther> seb128, thank you!
[13:06] <Mirv> seb128: so test4 i386/amd64 finished already, arm build on-going in a separate ppa
[13:07] <sabdfl> hey seb128, yeah, pretty funny
[13:07] <sabdfl> and juju's looking better and better
[13:08] <seb128> great ;-)
[13:10] <ogra_> Mirv, yep, test2 just failed in the canonical-arm-dev PPA on armhf too :)
[13:10] <ogra_> funny that you cant delete packages from a PPA if tehy are still building ...
[13:11] <Mirv> ogra/seb: ok just in that the test4 failed on arm for the same FindOpenGLES2.cmake complaint as on test3, while the amd64/i386 finished succesfully. there is yet another build ongoing with all .install files having the .armel/.armhf variant..
[13:11] <Mirv> but there is something fishy, since the test3 didn't have any variants, just one that was suited for arm specifically
[13:11] <seb128> ogra_, is there any way you could do a local build and look at that?
[13:11] <Mirv> and compiz-gnome shouldn't affect compiz-dev..
[13:12] <ogra_> seb128, well, i can try at least :)
[13:12] <Laney> got a link to this PPA build?
[13:12] <Laney> test4/arm
[13:12] <Mirv> ogra_: yes, please, you most probably have better ARM hardware that I'm now (barely) running the build on :) https://launchpad.net/~unity-team/+archive/release/+files/compiz_0.9.8.0-0ubuntu1%7Etest4.dsc
[13:12] <Mirv> Laney: ^
[13:13] <ogra_> Mirv, yep, my mx6 will build in half the time than a panda
[13:13] <seb128> Mirv, the bug log he meant I guess
[13:13] <Laney> well, I want to see the diff and the build log where it fails
[13:13] <ogra_> but it doesnt have a build env atm so it might take just as long with setting it up :)
[13:14] <seb128> I would have a look, but setting my pandaboard to build compiz and starting I would be done tomorrow
[13:14] <Mirv> Laney: I can't link to it directly but here's the end part of the log: http://pastebin.ubuntu.com/1173775/
[13:15] <Laney> Mirv: and which package is it supposed to be installed into?
[13:15] <ogra_> seb128, well, slangasek wants me to do a hangout session for setting up your panda :)
[13:15] <ogra_> you should attend ;)
[13:15] <seb128> yeah, for sure
[13:15] <Laney> heh
[13:15] <Laney> does unity work again yet? :P
[13:15] <seb128> Laney, compiz-dev
[13:16] <ogra_> Laney, on panda ?
[13:16] <Laney> yeah
[13:16] <seb128> Laney, on arm? that's what we are trying to solve here with that compiz build :p
[13:16] <ogra_> no, thats why we are trying to build compiz right now :)
[13:16] <Laney> hence my skin in the game here ;-)
[13:16] <ogra_> i'm just done with the driver, GLES should work OOTB with our next panda image
[13:17] <Laney> erm,
[13:17] <ogra_> now just the desktop is missing ;)
[13:17] <Laney> so the .install has this:
[13:17] <Laney> debian/tmp/usr/share/cmake*/FindOpenGLES2.cmake
[13:17] <Laney> dh_install: usr/share/cmake-2.8/Modules/FindOpenGLES2.cmake exists in debian/tmp but is not installed to anywhere
[13:17] <Laney> from the build log
[13:17] <highvoltage> hi! where's the right place to ask about the Ubuntu wallpaper? I would like to update the LDM (ltsp login manager) login theme for this cycle and ui freeze is upon us :)
[13:18] <seb128> Laney, ogra_, Mirv: oh, it's the rules
[13:18] <seb128> ifeq ($(DEB_HOST_ARCH),$(findstring $(DEB_HOST_ARCH), $(gles2_architectures)))
[13:18] <seb128> ...
[13:19] <seb128> ... cp cmake/FindOpenGLES2.cmake ...
[13:19] <seb128> else
[13:19] <seb128> no that
[13:19] <seb128> fi
[13:19] <seb128> "cp cmake/FindOpenGLES2.cmake debian/tmp"
[13:19] <seb128> is only done in the non gles case in the rules
[13:19] <ogra_> so move that line to .install.armhf
[13:19] <ogra_> debian/tmp/usr/share/cmake*/FindOpenGLES2.cmake
[13:20] <ogra_> i mean
[13:20] <ogra_> (and .armel indeed)
[13:20] <seb128> ogra_, no, the .install are fine, I think the rules is the issue, though I'm unsure why it special case gles for that cp
[13:21] <ogra_> well. let me drop these lines ad do a test build
[13:22] <ogra_> seb128, hmm, do we actually build GLES on x86 too ?
[13:23] <ogra_> (i think its needed for poulsbo support)
[13:23] <ogra_> s/do we/should we/
[13:23] <seb128> ogra_, no, duflu said we should only enable it on arches that don't support GL
[13:24]  * ogra_ has no idea if poulsbo can do GL though :)
[13:24] <Mirv> seb128: ...
[13:24] <ogra_> but yeah, understood
[13:25] <Laney> I don't see it
[13:26] <Laney> it looks like it is only done in the gles case (the first branch)
[13:26] <Laney> line 56?
[13:26] <seb128> Laney, right, I'm trying to understand why
[13:26] <Mirv> but how is it that the file is already included in compiz-dev?
[13:27] <Laney> so it seems to me like the .install is wrong as I pointed
[13:27] <Laney> indeed it probably isn't harmful to just install the .cmake file all of the time?
[13:27] <Mirv> ah.. compiz-dev has without the /Modules/ and on GLES architecture it copies it also to under there?
[13:27] <Laney> right
[13:28] <Laney> but you can't have it in compiz-dev.install as it wont be there on non-GLES architectures
[13:28] <Laney> why not just have the cp put it in place right away?
[13:28] <ogra_> ++
[13:28] <ogra_> thats what i just did
[13:28] <seb128> yeah, I don't know the history behind that hack
[13:28] <ogra_> (in my local copy)
[13:28] <seb128> but that seems fine to me
[13:28] <ogra_> still installing build-deps here though
[13:28] <Mirv> well it already _is_ there on non-GLES architectures, the copy of the same file just isn't under /Modules/, and I have no idea why eg. the FindCompiz.cmake is already duplicated
[13:29] <seb128> Mirv, just drop the && cp cmake/FindOpenGLES2.cmake  ...?
[13:29] <seb128> like keep the second case for all arches?
[13:29]  * ogra_ just added an if test -e ....;then cp ... fi ... to rules
[13:30] <Mirv> seb128: in other words remove the whole if clause?
[13:30] <seb128> ogra_, Laney: ^ what do you think?
[13:30] <Laney> does cmake expect it in /Modules/?
[13:30] <seb128> dunno
[13:31] <seb128> I've no clue about cmake
[13:31] <Laney> I would either copy it straight there in the first branch
[13:31] <Laney> or get rid of the if and make all arches have it in /Modules/
[13:31] <Laney> straight there → debian/compiz-dev/.../Modules/
[13:31] <seb128> well, the make install seems to installs it already?
[13:31] <seb128> the file is there on i386,amd64
[13:32] <seb128> since the .install works
[13:32] <seb128> just drop the gles2_architectures case of that if and always do what was done on non gles arches?
[13:33] <Mirv> it doesn't explain why it's clearly aimed for that there is both cmake*/FindOpenGLES2.cmake and cmake*/Modules/FindOpenGLES2.cmake, and why there already is cmake*/FindCompiz.cmake and cmake*/Modules/FindCompiz.cmake (copy of the same file) in compiz-dev
[13:33] <Mirv> since I don't understand, I'd create compiz-dev.install.arm{hf,el} adding the extra copy...
[13:33] <Laney> doing that just for one file seems to be overkill
[13:33] <seb128> Mirv, yes, please do that and let sort it out with duflu,sam after those release landed
[13:34] <Laney> wait for ogra_ to verify his fix since it sounds right
[13:34] <seb128> ok
[13:34] <seb128> ogra_, can you pastebin the diff of your fix?
[13:34] <ogra_> sure
[13:36] <ogra_> seb128, http://paste.ubuntu.com/1173816/ somethin like that
[13:37] <Mirv> ogra_: it doesn't solve the actual install phase problem where the .install doesn't (yet) have double FindOpenGLES2.cmake files?
[13:37] <seb128> ogra_, you duplicate the "cp cmake/FindCompiz.cmake ..." there?
[13:37] <Laney> mine looks like this http://paste.ubuntu.com/1173819/
[13:38] <ogra_> oh, right
[13:38] <Laney> untested
[13:38] <ogra_> didnt clean up the old stuff properly
[13:38] <Mirv> well I'll do a test build on the change I proposed now
[13:38] <ogra_> Laney, will yours not break if run on a non-GLES arch ?
[13:38] <seb128> Laney, is the destination dir created at this point?
[13:39] <Laney> ogra_: no, it's still in the conditional
[13:39] <Laney> seb128: true, possibly not
[13:39] <ogra_> ah, yeah
[13:39] <seb128> Laney, I don't think it is, it's before the dh_install run
[13:39] <Laney> so mkdir -p or install -d it before
[13:39] <ogra_> let me try yours then for my testbuild, build-dep install just finished
[13:40] <seb128> why do we need that file at all?
[13:40] <robru> pitti, seb128, davidcalle, yes, gexiv2 was quite a nice library IMO, and it was so nicely architected that it was nearly-trivial for me to add python3 support. Unlike pyexiv2 library which was a huge beast and could not be ported due to many problems with boost incompatibility.
[13:40] <seb128> robru, hey
[13:40] <ogra_> seb128, now thats a question for alf or upstream :)
[13:40] <Mirv> test6 build commencing..
[13:40] <robru> good morning
[13:40] <seb128> robru, what do you think about landing this gir work in quantal? do you have it in a ppa already?
[13:41] <robru> seb128, no ppa, it's just merged upstream and waiting for yorba guys to make a release. if you want to land it you'll need to package their git master, shouldn't be hard. just remember to ./configure --enable-intropsection
[13:42] <seb128> robru, ok, I'm emailing them about geary, I will ask about gexiv2 releases, they just did a shotwell 0.12.90 so they could do a gexiv2 0.4.90 ;-)
[13:42] <robru> seb128, actually I would very much like if you landed that in quantal because that means I can finally land my python3 port of GottenGeography ;-)
[13:43] <robru> seb128, :-D
[13:43] <ogra_> build running with this change http://paste.ubuntu.com/1173830/
[13:44] <seb128> Mirv, ^ that change seems fine to me
[13:44] <seb128> ogra_, thanks
[13:44] <Mirv> ogra_: ah, ok, I can see that working
[13:45] <seb128> Mirv, let's do that, can you include it in your branch and I will merge the previous revision for the .installs and that?
[13:45] <Mirv> seb128: I think that's just the same thing in debian/rules as adding compiz-dev.install.armhf/armel with one more line. but you'd prefer that approach?
[13:45] <seb128> hopefully that should give us a build gles on arm
[13:45] <seb128> Mirv, yes, it's easier to maintain one set of .install
[13:45] <Mirv> ok, I'll revert that .install.arm* addition and put that in instead
[13:45] <Mirv> ogra_: thanks
[13:45] <ogra_> esepcially for only one file :)
[13:46] <Laney> it's a pain to keep them in sync
[13:46] <seb128> Mirv, well, revert it only for compiz-dev, they are still needed for the plugins
[13:46] <Mirv> it is
[13:46] <Mirv> seb128: yes, that's what I meant
[13:46] <seb128> Mirv, good
[13:46] <seb128> Mirv, let's do that, let me know when you have it pushed and I will merge
[13:48] <ogra_> just a sidenote, it would be awesome if the compiz package coudl grow multithreaded building some point
[13:49] <ogra_> i'm building on a quad core here but only one compiler thread is running
[13:49] <ogra_> hmm, it actually calls dh build --parallel ...
[13:49] <ogra_> i wonder why it doesnt use all cores then
[13:51] <Mirv> seb128: lp:~timo-jyrinki/compiz/gles_arm_install_fix now updated. there should be only the new compiz-plugins.install.arm* files, the debian/rules change and changelog change
[13:52] <Mirv> test7 building :)
[13:52] <Mirv> while my obsolete local build is at 34%
[13:54] <ogra_> mine should be done soon ... i started over with -j8
[13:54] <ogra_> and its actually using all four cores now
[14:01]  * ogra_ twiddles thumbs ... 43%
[14:04] <xnox> ogra_: you should take up knitting
[14:04] <xnox> with all this compiling for arm =)
[14:05] <tedg> mterry, So I've now got a PPA where "everything works" -- what makes sense at this point?  Do releases or just wait as most things are frozen?
[14:05]  * tedg is not sure exactly where we are in the cycles
[14:06] <mterry> tedg, we're post FF, but just barely pre-UIF
[14:06] <ogra_> xnox, LOL, thanks, my GF already does that all the time, i dont want to steal her hobby
[14:06] <mterry> tedg, but your changes aren't features, just bug fixes
[14:06] <mterry> tedg, I assume
[14:06] <mterry> tedg, I'd say make releases, so that the FFe can proceed with final code
[14:06] <tedg> mterry, Yup, and string changes, etc.  Stuff that you find when you integrate :-)
[14:07] <jbicha> seb128: what did you think of bug 954352?
[14:07] <ubot2`> Launchpad bug 954352 in gtk+3.0 "Enable wayland backend" [Wishlist,Confirmed] https://launchpad.net/bugs/954352
[14:07] <tedg> mterry, Not user strings ofcourse.
[14:07] <mterry> tedg, well, you could still change those, but yeah, nothing user facing I guess
[14:07] <tedg> mterry, Okay, I'll do that.
[14:07] <tedg> mterry, Are you going to do a release of the greeter?
[14:07] <xnox> ogra_: I can knit quite well =)
[14:07] <mterry> tedg, depends on FFe
[14:08] <ogra_> xnox, do you want to take over arm ?
[14:08] <mterry> tedg, I can't do a release with everything enabled until FFe gets granted
[14:08] <ogra_> :)
[14:08] <seb128> jbicha, I'm unsure of the implications and I saw that e.g fedora doesn't enable that backend so I guess there is a reason
[14:08] <mterry> tedg, I might do a cut-down release to get some of the UI changes in
[14:08] <tedg> mterry, Do I need to ping Kate then?
[14:08] <xnox> ogra_: i have enough of let's take 30 source packages and build them into this massive deb and call it ubiquity
[14:08] <mterry> tedg, I was going to make some noise later today, but be my guest
[14:08] <ogra_> xnox, haha
[14:09] <tedg> mterry, Okay
[14:09] <jbicha> seb128: ok, maybe we can try enabling it at the beginning of the 13.04 cycle then?
[14:10] <seb128> jbicha, I guess we could, I would like to check with mclasen first what he thinks
[14:10] <seb128> jbicha, there were some issues with that I think, and to be honest wayland is not a desktop priority at the moment, or at least not for me
[14:12] <jbicha> ok, thanks, I'll note that on the bug
[14:12] <ogra_> 62% *twiddle*
[14:13] <ogra_> i need faster arm HW
[14:13] <ogra_> time that these calxeda boxes get usable
[14:13] <davmor2> ogra_: or a slower brain,  I can help you with that one I have a big hammer ;)
[14:14] <ogra_> davmor2, thanks i prefer the alcohol variant to slow my brain though :)
[14:14] <davmor2> ogra_: I guess you want to go with the vodka alternative though
[14:15] <davmor2> beat me to it
[14:30] <mterry> tedg, regarding FFe, the more interesting one is the one allowing NM in the greeter.  That isn't blocked by any MIRs and is functionality that will be always on, vs the FFe for the rest of the remote-login stuff (i separated those FFes into separate bugs)
[14:31] <tedg> mterry, I can haz both?  :-)
[14:31] <mterry> tedg, ideally yes, we can get both FFes approved.  But the urgency on the remote-login is less (and is blocked by MIRs right now anyway)
[14:32] <tedg> mterry, Yes, I understand.
[14:32] <tedg> mterry, Though did you see the RLS one is done.
[14:32] <mterry> yeah, that's nice
[14:32] <tedg> And I actually found some security bugs in pam-freerdp :-)
[14:32] <mterry> oh good?
[14:32] <mterry> :)
[14:32] <tedg> Curious if I should tell the security team before they do the review, just to check up on them ;-)
[14:33] <tedg> Possible buffer over run if the path of the guest user's home directory is over 490 characters long.
[14:33] <tedg> :-)
[14:44] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 2 starting in ~15 minutes in #ubuntu-classroom
[14:46]  * kenvandine wonders why it is almost 11am and i haven't gotten a second cup of coffee
[14:46]  * kenvandine rectifies that
[14:57] <Mirv> ogra_: unfortunately it still failed: http://pastebin.ubuntu.com/1173938/
[14:58] <Mirv> ogra_: missing && ?
[14:59] <seb128> Mirv, yes, miss && on the second mkdir line before \
[15:00] <seb128> how many tries does it take to fix a trivial rules issue :p
[15:00] <Mirv> pushed...
[15:05] <Mirv> now it can't go wrong anymore... knock knock
[15:06] <ogra_> lol
[15:24] <ogra_> yup, adding the && makes it work fine here
[15:25] <ogra_> (i refrained from rebuilding and just called fakeroot debian/rules install for testing
[15:25] <ogra_> )
[15:34]  * ogra_ installs the resulting PACKAGES ON HIS PANDA
[15:34] <ogra_> eek
[15:34] <ogra_> sorry
[15:40]  * Laney gets excited
[15:40] <Laney> well, not that I'm in the same location as my panda until Saturday
[15:41] <Mirv> ogra_: yes, that's the benefit of having the local build, being able to run single steps :)
[15:41] <ogra_> eah
[15:41] <ogra_> though the dpkg -i *.deb i didnt now wasnt clever ...
[15:41] <Laney> -iO ftw
[15:41] <ogra_> missing that i had a bunch of linux-headers packages around
[15:41] <Laney> oh, wouldn't save that
[15:42] <Laney> probably
[15:45] <ogra_> sigh, still unpacking linux-headers packages ...
[15:51] <ogra_> argh, i should have used an up to date image i guess ... 84MB of deps to upgrade first
[15:52] <seb128> ogra_, did you try unity on low ram configs recently by any chance?
[15:52]  * seb128 got asked to figure out the RAM requirements to run an unity desktop
[15:53] <ogra_> seb128, nope, i only run unity on my desktop atm and that has 16G :)
[15:53] <ogra_> i'll be able tzo tell you soon if it runs in 1G on the panda i hope :)
[15:54] <ogra_> xnox just reported that it works fine with llvmpipe  in a VM if you assign it 2G
[15:54] <ogra_> but i guess thats not what youre after
[15:55] <chrisccoulson> i don't think i'd want to run a unity session on anything less than 2GB ;)
[15:55] <seb128> ogra_, no, skaet asking if 384MB was still current
[15:57] <ogra_> unlikely
[15:57] <ogra_> i know cjwatson uses 768 or some such for his testing, just upped from 512M
[16:03] <chrisccoulson> seb128, i just added up all of the components that are related to unity, and got around 260MB
[16:03] <chrisccoulson> and that doesn't include all the other components that make up a typical session (eg, gvfs, dbus-daemon, update-notifier, gnome-settings-daemon, gnome-session, nautilus etc)
[16:04] <ogra_> chrisccoulson, you miss the squashfs :)
[16:04] <chrisccoulson> hah
[16:04] <seb128> I guess we should bump at least the 512M :p
[16:04] <ogra_> the installer images are way more ram hungry
[16:04] <seb128> or maybe 768
[16:04] <chrisccoulson> compiz, zeitgeist-fts and signon-ui are the most memory hungry parts
[16:04] <ogra_> i dont think 512M will work
[16:04] <ogra_> yeah
[16:04] <chrisccoulson> oh, and unity-panel-service
[16:04] <ogra_> 768 or 1G
[16:05] <chrisccoulson> oh, i forgot the window decorator
[16:05] <chrisccoulson> that's another 30MB ;)
[16:06] <ogra_> the prob with the livefs is that the writable bits all live in a ramdisk too
[16:07] <ogra_> so the only serious test is with an actual booted live image
[16:08] <ogra_> (and indeed then you needd to test with ubiquity and the live session running at the same time)
[16:13] <seb128> chrisccoulson, ogra_: thanks, I will put 768M
[16:26]  * micahg uses 1GB in VMs from oneiric on
[16:28] <desrt> seb128: pong
[16:28] <seb128> desrt, hey, had a good trip?
[16:28] <seb128> desrt, I don't remember the ping, I guess it was for the lo menu stuff, read log just before my ping?
[16:28] <desrt> good enough
[16:28] <desrt> no
[16:29] <desrt> okay.  now i did.
[16:29] <desrt> that's bad.
[16:36] <ogra_> seb128, \o/
[16:36] <seb128> ogra_, works?
[16:36] <ogra_> seb128, apart from some flickering issues runnin unity --replace just got me a wroking 3D desktop
[16:37] <seb128> ogra_, \o/ finally a good news!
[16:37] <ogra_> i somehow still have the runnable check in my session
[16:37] <ogra_> (its an alpha3 install i didnt upgrade much yet to not lose my desktop)
[16:37] <ogra_> so that seems good for an upload :)
[16:38] <seb128> ogra_, thanks for testing
[16:38] <ogra_> thanks for preparing :)
[16:45] <Quintasan> Hi guys, I have a virtual on-screen keyboard to package and upstream wants it to register and deregister gconf schemas on postinst and postrm accrodingly, can I handle that somehow using dh_gconf or I need a postinst and postrm script after all?
[16:46] <xnox> gconf?! you mean dconf right...?
[16:47] <highvoltage> xnox: some things still use gconf
[16:47] <xnox> highvoltage: the nick is back \0/
[16:47] <highvoltage> yeah. nick change failed again.
[16:47] <highvoltage> I'm stuck with highvoltage for life.
[16:48] <xnox> add it as your middle name!
[16:48] <xnox> name(s)
[16:48]  * ogra_ gets his power clamps back out of the drawer
[16:48] <highvoltage> or just make it my full name. I'll be like Madonna with just one name.
[16:48] <seb128> Quintasan, the packaging tools should handle that for you without having to do anything
[16:48] <ogra_> you could also prefix it with the_
[16:48] <seb128> Quintasan, gconf has a trigger, when schemas get installed dpkg register them at the end of the install
[16:48] <ogra_> i,e, the_jocarter
[16:48] <ogra_> or the_real_
[16:48] <ogra_> :)
[16:49] <Quintasan> seb128: So I can just put it into .install file and it should be dealt with automagically?
[16:49]  * highvoltage isn't cool enought to have an underscore at the end of the nick :)
[16:50] <seb128> Quintasan, yes
[16:51] <Quintasan> seb128: All sorts of awesome!
[16:51] <seb128> indeed
[17:01] <seb128> dobey, hey
[17:09] <tedg> mterry, So tsdgeos had suggested that we make the uccsconfigure a requires and the freerdp a recommends.  Because otherwise the "help" button would be kinda funky.  Thoughts?
[17:09] <mterry> tedg, hm
[17:09] <mterry> tedg, well, we only need it if we have remote-login-service, which is a recommends
[17:10] <mterry> tedg, but we can't express that in Depends notation
[17:10] <tedg> mterry, Hmm, okay, so should we make it a require of remote-login-service?
[17:11] <tedg> mterry, Then they'd come together
[17:11] <mterry> tedg, that seems unnecessary.  remote-login-service doesn't know anything about actually logging in, right?
[17:11] <tedg> mterry, No, but uccsconfigure doesn't really either.  It's mostly informational.
[17:11] <tedg> mterry, I mean, you can use the web to setup the account.
[17:12] <tedg> mterry, But it's not about logging in.
[17:12] <mterry> tedg, eh, fine.  Doesn't bother me.  I guess make it a Depends in remote-login-service
[17:14] <tedg> mterry, Okay, will do.
[17:30] <dobey> seb128: hi
[17:35] <seb128> dobey, hey, how are you? unping, that was about rb segfaulting due to the musicstore but I saw you already fixed that yesterday
[17:38] <dobey> seb128: ah, ok. i'm good. how are you? :)
[17:39] <seb128> dobey, I'm good thanks
[17:39] <seb128> will be glad once we are in beta freeze :p
[17:39] <dobey> heh
[19:04] <josepht> can anyone confirm bug 1040691?
[19:04] <ubot2`> Launchpad bug 1040691 in compiz "lowered window retains focus" [Undecided,New] https://launchpad.net/bugs/1040691
[19:12] <xnox> josepht: yes
[19:14] <dobey> oh; bugger
[19:14] <dobey> does girepository not support multiarch?
[19:17] <dobey> seb128: if you're actually here; do you kow if libgirepository supports multiarch for loading the typelib files?
[19:19] <dobey> hrmm, gobject-introspection 0.10.4-1ubuntu1 supposedly introduced some multiarch support
[19:20] <dobey> but i don't have a /usr/lib/i386-linux-gnu/girepository-1.0 directory…
[19:20] <seb128> dobey, it doesn't
[19:20] <seb128> well not that I know, try asking slangasek
[19:20] <dobey> ok
[19:43] <seb128> hate hate hate hate hate webkit
[19:43] <seb128> ar: .libs/libWebCore.a: File truncated
[19:44] <seb128> seems like binutils not liking >4GB files
[20:16] <lamalex> chrisccoulson, any movement on that FF distro patch?
[21:02] <seb128> robru, hey
[21:10] <tedg> robert_ancell, Morning.  Guess, what!  It works!
[21:10] <tedg> robert_ancell, :-)
[21:10] <robert_ancell> tedg, awesome!
[21:11] <tedg> robert_ancell, I've got a PPA with everything if you want to play with it.  But otherwise we're good for a release.
[21:11] <robert_ancell> tedg, ok, I'll merge that into lightdm and do a release
[21:11] <tedg> robert_ancell, Sweet, thanks!
[21:16] <robert_ancell> mterry,
[21:16] <robert_ancell> mterry, hey
[21:19] <mterry> robert_ancell, hi
[21:19] <robert_ancell> mterry, hey, can you approve https://code.launchpad.net/~robert-ancell/lightdm/remote-sessions/+merge/121948 if you've already pre-checked it?
[21:20] <mterry> robert_ancell, sure
[21:20] <robert_ancell> mterry, ta
[21:20] <mterry> robert_ancell, I just did a code read, didn't really play with it
[21:21] <mterry> robert_ancell, but I hear good reports
[21:21] <robert_ancell> mterry, that's probably safe, just needs a second set of eyes to look for obviously wrong or confusing stuff
[21:21] <mterry> robert_ancell, the greeter lib reading lightdm.conf did catch my eye, but you had a FIXME statement
[21:21] <robru> seb128, hey what's up?
[21:22] <robert_ancell> mterry, yeah, that's already there for the normal sessions and needs to be fixed at some point
[21:22] <seb128> robru, hey, the yorba guys said they will roll out a gexiv update this week
[21:22] <seb128> robru, just fyi
[21:22] <mterry> tedg, you saw the comments in the lightdm-remote-session-freerdp MIR, right?
[21:23] <robru> seb128, awesome! I saw jim merged an outstanding patch of mine from a while back ;-)
[21:23] <tedg> mterry, Looking now.
[21:23] <mterry> tedg, just a couple suggested fixups
[21:24] <tedg> mterry, Yup, will you handle the "compile with PIE" in the packaging?
[21:24] <tedg> Or is that something that should be in the build system?
[21:24]  * tedg thinks it should be default?
[21:25] <mterry> tedg, yeah I thought dh9 did that for us
[21:25] <mterry> tedg, I'll have to look
[21:31] <mterry> tedg, https://wiki.ubuntu.com/Security/Features says it's a performance tradeoff on x86
[21:31] <mterry> tedg, so it is selectively enabled, often by upstreams
[21:31] <tedg> mterry, Huh, okay.
[21:31] <mterry> tedg, looks like -fPIE for CFLAGS and -pie for LDFLAGS
[21:48] <chrisccoulson> hurrah @ https://bugs.launchpad.net/globalmenu-extension/+bug/1025011/comments/70
[21:48] <ubot2`> Ubuntu bug 1025011 in firefox "Firebug extension causes firefox to crash (can be triggered by opening HUD)" [Critical,Confirmed]
[21:49] <chrisccoulson> shame nobody came along weeks ago to verify the packages in proposed though....
[21:57] <seb128> chrisccoulson, yeah, it's annoying...
[22:00] <robert_ancell> RAOF, is the lightdm -core option something that should go upstream?
[22:18] <robert_ancell> mterry, was there a bug about the simultaneous pam prompts?
[22:19] <mterry> robert_ancell, sequential or multi?
[22:19] <robert_ancell> mterry, the recent change in lightdm "Support multiple simultaneous PAM prompts" (making a release now)
[22:19] <mterry> robert_ancell, ah, I called that multi.  I think so, digging
[22:20] <robert_ancell> mterry, also I assigned the u-g component of bug 1040221 and marked in progress which I think is correct, right?
[22:20] <ubot2`> Launchpad bug 1040221 in unity-greeter "FFe request: Provide remote login options" [Undecided,New] https://launchpad.net/bugs/1040221
[22:22] <mterry> robert_ancell, I'm not sure what status means on an FFe before there are any requested changes
[22:23] <robert_ancell> mterry, oh, right, it might be up to the person checking the ffe to set them
[22:26] <mterry> robert_ancell, bug 838555
[22:26] <ubot2`> Launchpad bug 838555 in unity-greeter "Support complex authentication requests" [High,Triaged] https://launchpad.net/bugs/838555
[22:27] <robert_ancell> mterry, ta
[22:27] <mterry> robert_ancell, kind of an all-encompassing bug
[22:27] <mterry> robert_ancell, this fix was just part of that bug
[22:27] <robert_ancell> mterry, yeah, I'll open a sub-bug for it
[23:18] <RAOF> robert_ancell: -core probably doesn't want to go upstream.
[23:19] <RAOF> robert_ancell: Although I suspect that quite a few distros would want it; it's there for apport integration, so that X crashes result in a core dump. If you don't have a running core-catcher system, it's not very interesting.
[23:20] <robert_ancell> RAOF, but is it worth it as a standard config option then we don't need the patch?
[23:20] <RAOF> Possibly?
[23:20] <robert_ancell> note we could do it via configuration by settings x-server-command=X -core
[23:21] <RAOF> Ah. When I was looking at it I think that seemed like it might result in glib trying to find a binary called ?X -core?, which would be why I didn't do it that way.
[23:24] <RAOF> It might be worth a config option; it's something that end users might sometimes want to do.
[23:24] <robert_ancell> right
[23:25] <thumper> bryce: ping
[23:28] <bryce> thumper, ...
[23:28] <thumper> bryce: hey, I have something that I may need to file a bug for and jasoncwarner_ suggested I ping you first
[23:28] <thumper> I use a wireless logitech mouse
[23:28] <thumper> and on login it quantal has stopped recognising the mouse
[23:29] <thumper> I have to take out the usb dongle and reinsert
[23:29] <thumper> then it works
[23:29] <bryce> thumper, alright, what diagnostics have you done so far?
[23:29] <thumper> bryce: not a log
[23:30] <thumper> s/log/lot/
[23:31] <bryce> thumper, this page is for touchpads but the same tools and processes can be used to isolate where it's failing - https://wiki.ubuntu.com/DebuggingTouchpadDetection
[23:33] <thumper> bryce: thanks
[23:34] <bryce> thumper, often that style of bug is a USB issue, so https://wiki.ubuntu.com/Kernel/Debugging/USB may also be a useful reference
[23:35] <bryce> thumper, oh... and doublecheck the battery has charge.  :-)
[23:36] <bryce> I've been bitten more than a few times troubleshooting a "buggy" wireless mouse that merely needed a new battery